Page 243 -

214 PART TWO MANAGING SOFTWARE PROJECTS

• does not engage when switch is activated
• slowly loses or gains speed
Once these system-level hazards are identified, analysis techniques are used to assign
4
severity and probability of occurrence. To be effective, software must be analyzed
WebRef
in the context of the entire system. For example, a subtle user input error (people are
Worthwhile papers on
software safety (and a system components) may be magnified by a software fault to produce control data
detailed glossary) can be that improperly positions a mechanical device. If a set of external environmental con-
found at ditions are met (and only if they are met), the improper position of the mechanical
www.rstcorp.com/
hotlist/topics- device will cause a disastrous failure. Analysis techniques such as fault tree analysis
safety.html [VES81], real-time logic [JAN86], or petri net models [LEV87] can be used to predict
the chain of events that can cause hazards and the probability that each of the events
will occur to create the chain.
Once hazards are identified and analyzed, safety-related requirements can be spec-
ified for the software. That is, the specification can contain a list of undesirable events
and the desired system responses to these events. The role of software in managing
undesirable events is then indicated.
Although software reliability and software safety are closely related to one another,
? What is the it is important to understand the subtle difference between them. Software reliabil-
difference
between software ity uses statistical analysis to determine the likelihood that a software failure will
occur. However, the occurrence of a failure does not necessarily result in a hazard
reliability and
software safety? or mishap. Software safety examines the ways in which failures result in conditions
that can lead to a mishap. That is, failures are not considered in a vacuum, but are
evaluated in the context of an entire computer-based system.
A comprehensive discussion of software safety is beyond the scope of this book.
Those readers with further interest should refer to Leveson’s [LEV95] book on the
subject.

8.9 MISTAKE-PROOFING FOR SOFTWARE

If William Shakespeare had commented on the modern software engineer’s condi-
tion, he might have written: “To err is human, to find the error quickly and correct it
is divine.” In the 1960s, a Japanese industrial engineer, Shigeo Shingo [SHI86], work-
ing at Toyota, developed a quality assurance technique that led to the prevention
and/or early correction of errors in the manufacturing process. Called poka-yoke
(mistake-proofing), Shingo’s concept makes use of poka-yoke devices—mechanisms
that lead to (1) the prevention of a potential quality problem before it occurs or (2)
the rapid detection of quality problems if they are introduced. We encounter poka-
yoke devices in our everyday lives (even if we are unaware of the concept). For exam-

4 This approach is analogous to the risk analysis approach described for software project manage-
ment in Chapter 6. The primary difference is the emphasis on technology issues as opposed to
project-related topics.