home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / mac / oop / macapp3 / 621 < prev    next >
Encoding:
Internet Message Format  |  1993-01-27  |  1.8 KB

  1. Path: sparky!uunet!pageworks.com!world!eff!sol.ctr.columbia.edu!howland.reston.ans.net!spool.mu.edu!agate!stanford.edu!apple!applelink.apple.com
  2. From: PILLAR.CORP@AppleLink.Apple.COM (Pillar, Foster City,PAS)
  3. Newsgroups: comp.sys.mac.oop.macapp3
  4. Subject: Re:software and jets
  5. Message-ID: <727992431.4058850@AppleLink.Apple.COM>
  6. Date: 25 Jan 93 18:25:00 GMT
  7. Sender: usenet@Apple.COM
  8. Organization: AppleLink Gateway
  9. Lines: 25
  10.  
  11. Regarding the analogy between reliability of complex software and jets:
  12.  
  13. > like to point out that Boeing and other aircraft developers spend
  14. >BILLIONS of dollars developgind (and performing SQA) on each new
  15. >jet--jets which they then sell for HUNDREDS of MILLIONS dollars.  A major
  16. >software package, on the other hand, costs less than 5 MILLION to develop
  17. >and sells for HUNDREDS of dollars.  Yet, I suggest that the number of
  18. >potential 'fatal' failure points in a major software package are probably
  19. >greater than the number of potential fatal failure points in a modern jet.
  20.  
  21. It's exceedingly unlikely that there are fewer failure points in the jet, when
  22. you consider the whole jet, particularly since the new ones have 10's to 100s
  23. of computer systems in them.  What we don't often thing about is that lots of
  24. the bits that go into it are standard/prefabricated/pre-tested/etc pieces that
  25. don't have to be rigorously tested every time a new model is rolled out: tires,
  26. brake assemblies, particular metallurgical formulations, control cables,
  27. hydraulic assemblies, etc.  Perhaps the better analogy for a large software
  28. system would be the space shuttle, which could only rely on a relatively _much_
  29. smaller set of existing components (Remember the Challenger?).
  30.  
  31. I don't remember where this thread started, but it _has_ brought us around to
  32. the need for _useable_ reusable software components.
  33.  
  34. Lee Harris
  35.  
  36.