Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software

Figure 2.6 in Chapter 2 illustrates the overall DFTS process advocated by this book. Note that each feedback step in the process has one or more major quality tools in the feedback loop.

Starting at the top of the figure, they go down the chart as six levels. FMEA is applied at each level, as shown in Table 13.4, where the FMEA scope at each level is shown in Figure 13.2. FMEA is a hierarchical risk analysis tool and may be as well applied to a hierarchical software system as a hardware system or complex machine.

The failure modes and their likely sources are different at each level of feedback in a DFTS methodology. The appropriate level of FMEA or, in some cases, SFTA is applied at the indicated feedback level of the DFTS model shown in Figure 2.6 to discover remaining failure modes in the system and subsystems. It is usually an architectural/design team brainstorming process to come up with a list of potential failures or hazards at each level. The identifiable and justifiable hazards are mapped backward through a Grady Sources-to-hazards schema, as shown in Figure 13.3, as far back in the design process as possible. Then the hazards are eliminated by redesign. Failure modes in mechanical and electrical systems may offer a dazzling array of possibilities, but fortunately in programming, they are most often limited to five categories:

A really catastrophic failure in a new program is known as a fatal errorone that causes the program to halt with no indication of why it did so. Fortunately, failures of this nature are usually detected in testing and rarely occur on the customer's premises. But fatal errors can happen when an unexpected or unusual data error not caught by an input edit forces a program down a control path that has not been tested.