Re: Ariane5 FAQ

["Robert I. Eachus" <rieachus@attbi.com>]

Berend de Boer wrote:

> True. Didn't they have a system in place where people have to sign
> certain things? I.e. a software engineer can sign that use of this
> software is ok.
> 
> Ultimately someone decided to include a piece of Ariadne 4
> software. And that someone didn't check the requirements. Either
> because a software engineer recommended it (in which case he should
> have checked it), or he was the software engineer.
> 
> And if people didn't know about the importance of requirements, it's a
> telling sign at what state software engineering in general really
> is. It just reminds me at the education in software engineering I got.

Sigh.  There was initially a requirements allocation for the Ariane 5. 
That allocation assigned validation of the SRI under Ariane 5 conditions 
  to a "full-up" flight systems test using a three-axis gimbelled table.

But Arianespace did not have a process for managing and tracking 
requirements, this was assigned to the individual contractors.  The 
result was that some requirements testing "fell through the cracks" due 
to design changes, or in the case of the BH bug, changes in the scope of 
a contract.

In other words when the flight test simulation contract was changed, 
there was nothing in place to map the requirements tested by the new 
version of the contract back to the original system requirements.

At MITRE we are very familiar with the issue, because it keeps coming 
up.  You need to map the original system requirements into detailed 
requirements against lower level subsystems.  That is part of the 
engineering process.  But you must maintain the original system 
requirements, track changes to the SYSTEM reqirements whether caused by 
external events or by the process of developing the subsystems, and see 
to it that the final system "as delivered" meets the final version of 
the requirements document.

That isn't quite the first rule of systems engineering but it is close. 
  Hmmm. I guess the first rule is actually, "The requirements will 
change, plan for it."  And the need for and ongoing requirements 
tracking process is one derived requirement. ;-)

And all of the Ariane 5 failures so far have involved failures in this 
process.  In the recent engine failure it was "only" a contributing 
factor, but in the other four it was the primary cause of failure.  Is 
this an indication that reuse is difficult?  Not really, but it does 
indicate something that the software engineering community has by now 
had beaten into them:  Software and hardware may be reusable, 
documentation may be reusable, even unit testing data can be reused 
sometimes.  But you CANNOT reuse system tests, and you CANNOT skimp on 
the requirements process.

-- 
"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh