SOFTWARE DESIGN FOR SIX SIGMA (DFSS) RISK MANAGEMENT PROCESS - Software Design for Six-Sigma: A Roadmap for Excellence - page 401

of the controlled process. Even if it is difficult, the severity of a single low-level
component failure mode, in principle, can be concluded backward from the top level
in a straight forward manner.
The likelihood of occurrence is much harder to define for a software-based system.
The manifestation of an inherent software fault as a failure depends not only on the
software itself but also on the operational profile of the system (i.e., on the frequency
of the triggering that causes the fault to lead to failure). This frequency is usually not
known. Luke (1995) proposed that a proxy such as McCabe's complexity (Chapter
5) value or Halstead's complexity measure (Chapter 5) be substituted for occurrence.
Luke argued that there is really no way to know a software failure rate at any
given point in time because the defects have not yet been discovered. He stated that
design complexity is positively and linearly correlated to defect rate. Therefore, Luke
suggested using McCabe's complexity value or Halstead's complexity measure to
estimate the occurrence of software defects. Also, the probability of detection is hard
to define because only a part of software failures can be detected with self-diagnostic
methods.
Software risk evaluation starts once the components of risk for each hazard/harm
have been identified then uses risk acceptability criteria, defined by the risk manage-
ment plan, to rank order the risk to complete the risk evaluation. Given the different
risk analysis techniques discussed, the evaluation of risk is totally dependent on
the software company's culture and internal procedures, as regulations and standards
cannot dictate one's approach for risk evaluation because of the difference in software
applications within the software industry. Few of the most used standards for soft-
ware risk management are ISO 9000-3, ISO/IEC 19770-1, IEC 60812, SAE J-1739,
MIL-STD-1629A, and ISO 12207. In this chapter, we will discuss risk evaluation
criteria based on our own hybrid approach.
To quantify risk consistently, we need to estimate the severity for each hazard and
the likelihood of occurrence associated with their causes against a criteria set forth
by the risk management plan defined at the product level.
Severity rating is the rank associated with the possible consequences of a hazard
or harm. Table 15.2 lists a generic software severity ratings based on two commonly
used scales: 1 to 5 and 1 to 10. Risk management teams can develop a severity rating
that best suits their application.
Likelihood of occurrence rating is the rank associated with probability (or fre-
quency) that a specific cause will occur and cause the potential hazard during a pre-
determined time period (typically the software life cycle). Table 15.3 lists a generic
likelihood of occurrence ratings based on two commonly used scales: 1 to 5 and
1 to 10. Risk management teams can develop a likelihood of occurrence rating that
best suits their application.
Risk classification is a process of categorizing risk in different criteria as defined
by the risk management plan. Risk classification criteria define the foundation for
risk acceptance or highlight the need for risk reduction. Table 15.4 lists the different
risk classification criteria by event (intersection cell).
Risk acceptance is a relative term that the product is deemed acceptable if it is risk
free or if the risks are as low as reasonably practicable (ALARP), and the benefits