PPRuNe Forums - View Single Post - AF 447 Search to resume (part2)
View Single Post
Old 23rd May 2011, 16:43
  #2184 (permalink)  
syseng68k
 
Join Date: Jun 2009
Location: Oxford, England
Posts: 297
Received 0 Likes on 0 Posts
John, #2155


Ref this post my limited knowledge of cutting code suggested that the sentiments were a bit optimistic. A specialist colleague provided the following commentary as an observation and invited me to post it for information.
You can thank your colleague for an excellent set of links. Having
re-read my own post though, I stand by what I said. I'm far from
complacent, but all engineers know that engineering is and always
has been a devil's compromise between speed/functionality, reliability
and cost. Pick any two. Engineered products are designed to meet the
requirements for the particular application and there is rarely any
incentive to gold plate a product, especially if it shows
no improvement in performance, or results in a lower price or cost of
ownership. While big improvements can be made by a more rigorous
specification and process, the law of diminishing returns applies
in terms of cost / benefit. Engineers therefore accept that nothing
in the real world is ever perfect. You can get close and a product
made fit for purpose with a high degree of confidence, by carefull
risk assessment, design, implementation and validation.

What I was trying to illustrate earlier was that avionics software
development has some of, if not the most, rigorous processes applied to
it to tilt the balance in favour of reliability, rather than cost.
Sure, it may never be perfect, but in comparison to consumer or even
industrial application software, the expected reliability should be
orders of magnitude better due to the processes used.

Experience over many projects suggests that code is not usually the main
problem, as coding errors are readily found using code review,
software tools and other techniques. If not, then the development process
is seriously at fault and should be revised. More likely culprits are
inadeqate requirements capture, lack of awareness of possible
problem scenarios and incomplete visualisation of the big picture as it
applies to the problem at hand.

Which leads us to:

> Summary: Five errors is as good as it gets in software with many tens of
> thousands of LOC. This is the order of the first civil aircraft flight
> control systems a quarter-century ago (Airbus A320, 1988, about 60,000
> LOC).

Sorry, but nitpicking, generalisations are dangerous :-). Are we talking
about typo's, or the failure to trap bad args to functions, algorithmic
errors, non compliance with original spec or what ?. That is, some
"errors" have serious effect and some are benign, with no effect at all...
syseng68k is offline