Information Technology Reference
In-Depth Information
FIGURE 16.2
Risk management elements.
not always be easy, but at least the DFSS can rely on data provided by the component
manufacturers, results of tests, and feedback of available operational experience. For
software, the situation is different. The failure modes of software are generally un-
known. The software modules do not fail ; they only display incorrect behavior. To
discover this incorrect behavior, the risk management process (Chapter 15) needs to
be applied to mitigate risks and to set up an appropriate SFMEA approach.
For each software functional requirement or object (see Chapter 13), the team
needs to ask “What can go wrong?” Possible design failure modes and sources of
potential nonconformities must be determined in all software codes under consid-
eration. The software DFSS team should modify software design to prevent errors
from happening and should develop strategies to deal with different situations using
risk management (Chapter 15) and mistake proofing (poka-yoke) of software and
associated processes.
The main phases of SFMEA are similar to the phases shown in Figure 16.2. The
SFMEA performer has to find the appropriate starting point for the analyses, set
up a list of relevant failure modes, and understand what makes those failure modes
possible and what their consequences are. The failure modes in SFMEA should be
seen in a wide perspective that reflects the failure modes of incorrect behavior of the
software as mentioned and not, for example, just as typos in the software code.
In this chapter, the failure mode and effects analysis is studied for use in the DFSS
road map (Chapter 11) of software-based systems. Efforts to anticipate failure modes
and sources of nonconformities are iterative. This action continues as the team strives
to improve their design further and its developmental processes making SFMEA a
living document.
We use SFMEA to analyze software in the concept and design stages
(Figure 13.1). The SFMEA helps the DFSS team to review targets for the FRs 3 ,
to select optimum architectures with minimum vulnerabilities, to identify prelimi-
nary testing requirements, and to determine whether risk mitigation is required for
3 See Chapter 13.
Search WWH ::




Custom Search