Re: The stupidity of all the Ariane 5 analysts.

["Marin David Condic, 561.796.8997, M/S 731-96" <condicma@PWFL.COM>]

Joerg Rieling <joerg@HERA-B.DESY.DE> writes:
>but, a minimum requirement for any software is to test it under
>sufficiently realistic conditions, isn't it ?   if the responsible
>software engineers would have fed _simulated_ data containing some
>information about the trajectory into their programs, they could
>(would) have found the  bug, d'accord ?
>sometimes experimental programming is not the worst choice ...
>
    This is exactly the point that has so many people torqued off
    about the whole debate. (Especially those of us who actually build
    this sort of software for a living.) The claim seems to be on the
    table that a) Existing software development practices are
    insufficient for developing safe software and b) the only way to
    be sure that you don't blow up a rocket is to use Design By
    Contract as exemplified by Eiffel.

    The problem is - as those of us in the business know - existing
    practices, HAD THEY BEEN FOLLOWED, would have caught the problem.
    (Your example of testing the software across the expected flight
    envelope.) So would lots of other existing practices. The problem
    is that the human beings in charge of the process didn't follow
    the usual and customary procedures (probably under cost and
    schedule pressure). Hence, no technology would likely have helped
    keep them out of the Gulag they are now most likely consigned to.
    (It's sad too for those of us who have ever experienced the "Hurry
    up and get it done no matter what the risk..." pressure that can
    be brought onto a project.)

    DBC and Assertions, in my not so humble opinion, would have proven
    to make no significant difference in the situation. DBC is a kind
    of process and apparently the people in charge were into
    circumventing processes. So DBC could have as easily been
    circumvented for the same reasons as they circumvented existing,
    industry accepted and used processes. (which, IMNSHO, would
    probably have caught the problem had they been followed.) If you
    walk a tightrope without a net often enough, eventually you'll
    splat up against the pavement.

    Assertions are just another kind of runtime check which - although
    useful - would probably have made no difference either. The reason
    being that the existing checks were disabled (for good reason)
    and so assertions would also have been disabled. Disabled checks
    don't change anything. The notion that they would have served as
    documentation implies some kind of review/testing and go back to
    the above paragraph on DBC. They had already circumvented that
    part of the game, so forget that argument.

    The seriously flawed notion that the runtime checks be turned
    on during testing and then disabled for production only displays
    lack of knowledge of how flight qualified software is really
    built. Nobody is going to go through any sort of serious
    verification of a software package only to allow you to change
    some of the bits afterwards and claim "well, it's really the same
    thing so let's go fly with it..." That might be O.K. for testing
    something like Microsoft Word, but it will never pass muster for
    safety critical software. Hence, you run with them in or you run
    with them out. Running with them in might have done something to
    save the day - but then so would the existing range checks that
    were taken out.

    MDC