On software quality and engineering
mr_b at tpg.com.au
Sat Nov 2 04:25:06 EST 2002
On Saturday 02 Nov 2002 10:42 am, Simon Fowler wrote:
> On Sat, Nov 02, 2002 at 09:55:27AM +1100, Brad Hards wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > A concept that has been missed in all of this is that all things are
> > designed to meet acceptable risk. The Pinto example is where they
> > mis-defined what level of risk was acceptable.
> > Aircraft software is not designed to be bug free. It is designed to
> > contribute less than an acceptable conponent of aircraft crashes. Typical
> > sort of numbers are "1x10-9 per hour for safety critical items". You
> > can't test to that sort of number, so you go with "process" approach.
> > However most of the software on an aircraft isn't safety critical (RTCA
> > DO-178B level A). So you design to a lower level of reliability (eg. the
> > intercom is probably level C, and the in flight entertainment systems is
> > probably level E - so it doesn't have any software process requirements).
> > It is unrealistic to expect that complex systems will not fail. It only
> > realistic that a system fails at (or below) an acceptable level. Normally
> > the risks are defined in terms of probability of failure (or partial
> > performance) and the consequences of failure (or partial performance).
> I think the difference with software is that it's not like a
> physical system - it doesn't wear out over time, it doesn't have an
> inevitable failure at some point in the future, even if it's perfect
> now. Software is either correct or it's not correct.
> Of course, back in the real world software is /never/ correct, since
> it's impossible to get all the bugs out of any non-trivial piece of
> software. So although the class of failures you get in physical
> systems due to things wearing out don't happen, you can probably
> still apply much the same reasoning about failure rates . . .
Yes it's impossible to get all bugs out of any non-trivial piece of software.
That's why to do it properly you don't put the bugs in it in the first place.
> > This might make a decent topic for November CLUG. Not sure if I'll be
> > there at this stage, but I'm willing to present on this.
> It's certainly an interesting topic, and it's one I haven't seen
> mentioned in any of the courses I've done in my degree . . . I'd
> love to hear about it from a /real/ engineer ;-)
/real/ Engineer :-)
The goal of an engineer is to get through life without being blamed for a
More information about the linux