DozyWanabbe,
Thank you for that worthful report. I have to agree that it does not comply to an ivory tower.
But accept that such work quality, such teams have been in work in AS & others (the same companies) building the fabulous Ariane501 launch and crash for 8 billions FF : only one bit was wrong (the famous carry) coming from only one unuseful variable BH imported from the former ArianeIV on the ground. That story showed that reliability must get much better in softwares. Jacques-Louis LIONS had been the head of the CNES (maîtred'oeuvre) but could not see the hidden bug from his office, and discivered it only when he was the President of the enquiry Board.
I know my position is harsh, strong, strict, etc. I will not change a comma.
The fact that I am an (retired) airline pilot too is an obligation to save lifes of my colleagues, not probability of live.
Thank you to allow that open discussion.
HAPPY NEW YEAR,
No reliability number is assigned to software, nor to any other design aspect.)
It was interesting to note, however, that nobody to whom I spoke believed that ``reliability = 1'' for any part of any system, although they are not aware of any method of demonstrating such high reliability figures for software. In fact, I was given a copy of a paper [6] which argued the impossibility of so doing, using arguments similar to those employed by Littlewood and Strigini[7], with which paper everyone was also familiar.
One interesting aside was that the 10^-9 figure is justified within the JAA by an argument that I do not believe is used by the FAA. It depends on actual statistics, which indicate that the probability of an aircraft crash is about 10^-7 per flying hour. Given that there may be around 100 critical systems on any aircraft (on the A320 there are 68) the additional factor of 10^-2 is applied to allow for the fact that *any one* of them may fail catastrophically. This justification is contained in one of the JAR interpretive documents.