Risk Assignment and Evaluation at Each Stage of DFTS

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.

Table 13.4. Quality Tools Applied at Various Levels of DFTS (See Figure 2.6)

Level	Quality Tool(s)
Phase 1: Requirements	QFD and Voice of the Customer Pugh Concept Development TRIZ Inventive Problem Solving Concept FMEA: Analyze concept for risks
Phase 2: Robust Design	QFD on the functional and technical design features Design FMEA: Analyze design for risks SFTA detailed software tree analysis
Phase 3: Coding/Implementation	Component FMEA: Component risk analysis
Phase 4: Verify, Validate, Test, and Evaluate	Subsystem FMEA: Subsystem risk analysis
Phase 5: Integration	System FMEA: System integration risk analysis
Phase 6: Maintenance	Service FMEA: In-service risk analysis

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.