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

Any one of these projects can cost more than $1 billion. To take two current
examples, the computer modernization effort at the U.S. Department of Veterans
Affairs is projected to run $3.5 billion. Such megasoftware projects, once rare, are
now much more common, as smaller IT operations are joined in “systems of systems.”
Air traffic control is a prime example because it relies on connections among dozens
of networks that provide communications, weather, navigation, and other data. What
are the risks involved, and how they can be mitigated?
In general, software quality, reliability, safety, and effectiveness only can be con-
sidered in relative terms. Safety by definition is the freedom from unacceptable risk
where risk is the combination of likelihood of harm and severity of that harm. Subse-
quently, hazard is the potential for an adverse event, a source of harm. All designed
software, carry a certain degree of risk and could cause problems in a definite situa-
tion. Many software problems cannot be detected until extensive market experience is
gained. For example, on June 4, 1996 an unmanned Ariane 5 rocket launched by the
European Space Agency exploded just 40 seconds after lift off from Kourou, French
Guiana. The rocket was on its first voyage after a decade of development, whic cost
$7 billion. The destroyed rocket and its cargo were valued at $500 million. A board
of inquiry investigated the causes of the explosion and in two weeks issued a report.
It turned out that the cause of the failure was a software error in the inertial reference
system. Specifically a 64-bit floating point number relating to the horizontal velocity
of the rocket with respect to the platform was converted to a 16-bit signed integer.
The number was larger than 32,767, the largest integer storable in a 16-bit signed
integer, and thus, the conversion failed.
Attention starts shifting from improving the performance during the later phases
of the software life cycle to the front-end phases where development takes place
at a higher level of abstraction. It is the argument of “pay now” or “pay later” or
prevention versus problem solving. This shift also is motivated by the fact that the
software design decisions made during the early stages of the design life cycle have
the largest impact on the total cost and the quality of the system. For industrial
and manufactured products, it often is claimed that up to 80% of the total cost is
committed in the concept development phase (Fredrikson, 1994). For software, it
is the experience of the authors that at least 70%-80% of the design quality also is
committed in the early phases, as depicted in Figure 15.1 for generic systems. The
potential is defined as the difference between the commitment and the ease of change
for metrics such as performance, cost, technology, schedule, and so on. The potential is
positive but decreasing as development progresses, implying reduced design freedom
across time. As financial resources are committed (e.g., buying production machines
and facilities, hiring staff, etc.) the potential starts changing signs, going from positive
to negative. In the consumer hand, the potential is negative, and the cost overcomes
the impact tremendously. At this phase, design changes for corrective actions only
can be achieved at high cost including customer dissatisfaction, warranty, marketing
promotions, and in many cases, under the scrutiny of the government (e.g., recall
costs).
The software equivalent of Figure 15.1 is depicted Figure 15.2. The picture is as
blurry as for general systems. However, the research area of software development