cmh-issc-lessons (Раздаточные материалы), страница 4

Instruments wereattached to a leak check port on a joint tomeasure the pressure between the two O-rings.The oil was pressurized to about 1.5 times theexpected pressure at ignition. The test showedthat the steel case was strong enough, but it alsoshowed something completely unexpected. Inthe first few milliseconds after ignition, the innerflanges of the tang and clevis moved away fromeach other, thus reducing, not increasing thecompression on the O-rings (ref.

21). Figure 3(ref. 23) illustrates this phenomenon, which wascalled joint rotation. Notice how the sides of thebooster bulge outward, and the jointsthemselves open up (the effects are exaggeratedin the figure so that they can be seen).lesson five (relying heavily on data, without anadequate explanatory theory, is unwise).Figure 3 - Joint Rotation (exaggerated)A 1978 static test firing of a full boosterconfirmed the existence of joint rotation.Engineers at both Thiokol and NASA wereconcerned. The two groups disagreed on theactual size of the gap caused by joint rotation.NASA engineers believed the gap waspotentially large enough to cause the secondaryO-ring to be unable to seal in the event of theprimary O-ring failing late in the ignition cycle.The history of the interaction between the twogroups is complicated, and not important for thispaper. What is important is that eventually bothgroups were satisfied by the data from varioustests and seven static motor firings that the Orings would seal the joints (ref.

22).The data convinced them, but no one had a goodunderstanding of exactly why the joints behaveddifferently than the design predicted they would.The engineers relied on the data without anadequate explanatory theory about why the datawas what it was. No such theory ever wasdeveloped before the accident (ref 22).

Just asrelying on theory without sufficient confirmingdata contributed to the Tacoma Narrowscollapse, so too did relying on data with anexplanatory theory contribute to the Challengeraccident.Applications to Building Software SystemsMany applications of the five lessons we havejust seen can be made to software systemdevelopment. Only three will be given here.Application 1: The verification and validation ofa software system should not be based on asingle method, or a single style of methods. Thisapplication is based on a combination of lessonone (relying heavily on theory, without adequateconfirming data, is unwise) and its converse,In the verification and validation of a particularsystem, this application suggests that neithertesting nor analytic techniques should be trustedalone. Testing by itself cannot guarantee thecorrectness or safety of a system; analytictechniques such as formal modeling are alsoneeded.

But, formal modeling should not beused by itself either. No matter how wellconstructed a formal model may be, rigoroustesting of the actual system is still important,especially for validating the accuracy of theassumptions made by the formal model.Too often, especially at conferences and in thepublished literature, supporters of testing expendmany words showing the limitations of formalmethods and supporters of formal methodsexpend many words showing the limitations oftesting. Every testing method has limitations;every formal method has limitations, too. Testersand formalists should be cooperating friends, notcompeting foes.Application 2: The tendency to embrace thelatest fad should be overcome.

Lesson three (instudying existing experience, more than just therecent past should be included) provides thefoundation for this application.Although few software engineers or managerswould explicitly claim to be embracing the latestfad, a study of the history of the softwarediscipline shows that it has been characterizedby fad-ism.Famous fads from the past include structuredprogramming, high-level programminglanguages, artificial intelligence (AI), programverification, and computer-aided softwareengineering (CASE) tools. Each of these was, atone time, touted by vocal supporters as thesolution to the “software crisis.” Each of thesehas contributed in some way to improvements insoftware.For some, such as structuredprogramming and high-level programminglanguages, the contributions have beensignificant, but none of these has come close todelivering the benefits claimed by zealousproponents.Although Fred Brooks warned over a decade agoagainst expecting any one particular approach tosolve the problems of software development (ref.24), fad-ism continues unabated.

Enthusiasm forobject-oriented design and process maturitymodels remains strong. When this enthusiasmwanes (as it certainly will), architectural designand soft computing seem poised to compete forfad status.Software can be used in safety-critical systems.But its use ought to be guided by successfulpast experiences, and not by ambitious futuredreams. Most children learn to crawl before theywalk, and to walk before they run. Softwaresystem designers and implementers should dothe same.If software practitioners and managers will studyhistory, and learn its lessons, they will stopembracing the latest fads.

Instead, they willchoose from the wide variety of availabletechniques those that are most applicable to theirparticular situation. The quality of softwaresystems will inevitably improve when thishappens.In 1990 Mary Shaw of the Software EngineeringInstitute wrote, “Software engineering is not yeta true engineering discipline, but it has thepotential to become one” (ref. 28). Her words areno less true today than they were when shewrote them almost a decade ago. Studyingestablished engineering disciplines, andapplying the lessons learned in their failures, isone of the ways that the potential of softwareengineering can be realized.

This paper hasmade a small contribution towards that end.Application 3: The introduction of softwarecontrol into safety-critical systems should bedone cautiously.This application followsstraightforwardly from lesson two (going wellbeyond existing experience is unwise), and isalso supported by lesson four (when safety isconcerned, misgivings on the part of competentengineers should be given strong consideration,even if the engineers can not fully substantiatethese misgivings).No one intentionally advocates being incautiousin using software, but just as the two accidentsstudied here show, even exceptionally brightpeople can be self-deceived (ref. 25) about theextent to which their proposals go beyondcurrent experience.Given the complexity ofmodern software systems, and the tendency ofcomplexity to lead to unexpected accidents (ref.26), prudence seems to dictate special caution forsoftware systems.Recommendations fromsoftware professionals (for one example, see ref.27), for such caution should be taken seriously,even when these recommendations cannot befully proven either analytically or empirically.This does not mean that software should not beused in any safety-critical systems.

It already isbeing used successfully. For example, afterstudying the design and testing of severalShuttle systems, one of the members of theRogers Commission expressed greaterconfidence in the integrity of the softwaresystem than in any other system he studied (ref.23).Concluding RemarksAlthough software engineering failures havecontributed to loss of life (ref. 29), and todestruction of property (ref. 30), a catastropheanalogous in its public impact to either theTacoma Narrows Bridge collapse or theChallenge accident has not happened yet.Understanding the fallibility of humans, andknowing a little bit about the history oftechnology, suggests that such catastrophes areinevitable.

Nevertheless, if software engineersand managers are diligent to learn the lessonstaught by the past—the past of softwareengineering, the past of established engineeringdisciplines, and the past of any other area withrelevant lessons—perhaps these catastrophescan be reduced in frequency and in severity.After all, the second bridge over the TacomaNarrows has been standing for almost 50 years,and the space shuttles have flown nearly 70 safemissions since flights resumed.References1.

W. Wayt Gibbs. “Software's Chronic Crisis.”Scientific American (September 1994): 86-95.2. Bev Littlewood and Lorenzo Strigini. “TheRisks of Software.” Scientific American(November 1992): 62-75.3. Peter G. Neumann. Computer Related Risks.New York: ACM Press, 1995.4. Ivars Peterson. Fatal Defect: Chasing KillerComputer Bugs. New York: Times Books, 1995.5. Evan I. Schwartz. “Trust Me, I'm YourSoftware.” Discover (May 1996).6. Lauren Ruth Wiener. Digital Woes. Reading,Massachusetts: Addison-Wesley PublishingCompany, 1992.7.