Contact for Software Engineering
Email |
We call our approach to software engineering, 'Correctness by
Construction'. The seven key principles of this approach are:
1 Expect requirements to change.
Indeed, we welcome change as they can give you, the customer,
a competitive advantage in a continually changing and hotly
contested marketplace. At Praxis High Integrity Systems, we deal with
changing requirements by adopting an incremental approach and
paying increased attention to design to accommodate change.
We apply more rigour, rather than less, to avoid costly and
unnecessary rework.
2 Know why you're testing.
We recognise that there are two distinct forms of testing, namely
to build correct software (debugging) and to show that the software
built is correct (verification). These two forms of testing
require two very different approaches.
3 Eliminate errors before testing.
Better yet, deploy techniques that make it difficult to introduce
errors in the first place. Testing is the second most expensive
way of finding errors. The most expensive is to let your customers
find them for you.
4 Write software that is easy
to verify. If you don't, verification and validation (including
testing) can take up to 60% of the total effort. Coding typically
takes only 10%. Even doubling the effort on coding will be worthwhile,
if it reduces the burden of verification by as little as 20%.
5 Develop incrementally.
Make very small changes, incrementally. After each change, verify
that the updated system behaves according to its updated specification.
Making small changes makes the software much easier to verify.
6 Some aspects of software development
are just plain hard. There is no silver bullet. Don't expect
any tool or method to make everything easy. The best tools and
methods take care of the easy problems, allowing you to focus
on the difficult problems.
7 Software is not useful by itself.
The executable software is only part of the picture. It is of
no use without user manuals, business processes, design documentation,
well-commented source code and test cases. These should be produced
as an intrinsic part of the development, not added at the end.
In particular, recognise that design documentation serves two
distinct purposes:
a To allow the developers
to get from a set of requirements to an implementation.
Much of this type of documentation has outlived its usefulness
once the implementation exists.
b To allow the maintainers to understand
how the implementation satisfies the requirements. A document
aimed at maintainers is much shorter, cheaper to produce and
more useful than a traditional design document. |
|
| |
© Website Content Praxis High Integrity Systems 2008
 Normal
text Large
text
|
|
|
|
- 
