Re: Papers on the Ariane-5 crash and Design by Contract

[rkaiser@dimensional.com (Richard Kaiser)]

In article <332D113B.4A64@calfp.co.uk>, Nick Leaton <nickle@calfp.co.uk> 
wrote:

<snip>

>1) Documentation. You need less of this. Documentation which say 'This
>feature expects this and does that' is no longer need. Documentation
>that is needed is the 'intent' of the routine, and high level intent or
>overviews. There are tools that can produce what is called the short
>form, the code without the implementation built into most compilers.
>These will also produce HTML and other outputs.

This was the first point of failure in the design.  The time limit in the
original software release should have been documented in a Version
Description Document or software requirements document.  And these
documents should have been reviewed for the new rocket.

>2) Design. Writting assertions makes design easier. This is a personal
>observation and harder to justify. I find being clear about what
>something does helps clear up what I am doing. Having complex
>preconditions is not a good idea, again you probably don't have the
>right structure.

But design was not done.  An old box was placed into a new rocket.  Unless
the old software could detect it was in a new application it could not handle
the only way to detect the problem was by documentation of requirements and 
limitation or by ...

>3) Debugging / Testing. Running with assertions enabled detects bugs 
>earlier. This is the real saver in time and costs. 




>4) Reviews. If you review code, then having the assertions in place
>is very useful. A large part of reviewing C++ is working out what
>assertions have been assumed, and checking code against them. Having
>them written into the code makes this easier.
>
>There are other more complex parts to Eiffels assertion system, in
>relation to inheritance, and soon in relation to parallel processing.
>
>But in conclusion, my experience is that people write assertions in
>their code, because it is effective.
>
>