Some thought on bits from above:
“The Chinook software risk is hypothetical, the TPs were happy with the aircraft.”
1. Risks aren’t hypothetical, they are real. You identify a consequence, and figure out its probability – there’s your risk. Just because a tp is happy, doesn’t make it safe.
“would not have happened under previous clearance standards (eg before the current Class 1 safety critical software assessment requirements WHEN WERE THESE INTRODUCED?), and would not be viewed as a problem by other operators”
2. So what happened to ‘current best practice’, UK law, etc etc? Just because someone else thinks its ok for them doesn’t have to mean it’s ok for us. If you are talking Def Stan 00-55 Iss 2, Aug 1997.
“(Boscombe merely identify the risks - the IPT then assess them and get the MAR signed”
3. Not quite right, Boscombe identify the risks, we assess the risks and advise the IPTL on how to mitigate the risks. The IPTL considers whether or not he is prepared to accept that level of risk.
“As to Risk Assessments - bit like statistics, you can prove anything”
4. You can prove anything with a nasty outcome has some probability. The skill is in showing that a credible hazard has an acceptable (or unacceptable) level of risk. Not quite the same.
“Moreover, it would be interesting to hear knowledgeable estimates of how many hours would need to be flown to provide credible evidence that all was OK - risk wise.”
Lots of hours, and for complex systems more time than has existed in the universe so far. If you have lots of inputs in lots of combinations it takes lots of time to work through them all. So, for software it is better to show that the way you have identified and mitigated the risks is sound AND that you have developed the software correctly. 2 quotes from learned people in the /sw business:
If you try and tell me that the probability of a software failure occurring in a system is one in a million, I’m very unlikely to believe you. If you tell me that there is no way that the software can fail, I’m much more likely to believe you because in the first case, you can’t have tested sufficiently to get that level of confidence, in the second you must have done something to be so sure that this is the case.
There are 2 ways of developing software. The first is to make it so simple, there are obviously no errors, the second is to make it so complicated that there are no obvious errors.
Unfortunately there is much more of the latter around than the former.
“There are a number of platforms with MARs carrying more real, more quantifiable risk.”
5. Firstly see 1 above. Secondly, if the risk is quantifiable, then a reasoned argument as to its acceptability can be made. The problem comes when you can’t quantify the risk. That’s when you are on thin ice.
sw
Last edited by Safeware; 13th Oct 2006 at 18:42.
Reason: spool chick