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

space (i.e., life testing) or as a component whose structure permits modeling of its
failure probability from its architecture. Unfortunately, the quantification of software
failure probability by life testing has been shown to be infeasible because of the
very large number of tests 5 required to establish a useful bound on the probability of
failure. The large number of tests derives from the number of combinations of input
values that can occur. Also unfortunate is the fact that no general models predict
software dependability from the software's design; the type of Markov models used
in hardware analysis do not apply in most software cases. The reason for this is that
the basic assumptions underlying Markov analysis of hardware systems do not apply
to software systems (e.g., the assumption that independent components in a system
fail independently does not apply) (Knight & Nakano, 1997).
It is possible to obtain the parameters needed for fault tree analysis by some
means other than testing or modeling. Many techniques exist, usually within the field
of formal methods (Diller, 1994) that can show that a particular software system
possesses useful properties without testing the software. If these properties could be
used to establish the parameters necessary for FTA, then the requirement of using
testing and Markov models would be avoided.
From a testing estimation perspective, a major part of the problem derives from
the size of modern software systems. Knight and Nakano (1997) suggested dealing
with testing estimation complexity using a combination of the following concepts:
Protection-Shell Architecture : A protection she can be used to limit severely the
amount of software on which a system depends for correct operation. As a result,
the amount of critical software that has to be tested can be reduced significantly.
The detailed description and analysis of this architecture is to restrict most
of the implementation of safety and, thereby, the dependability analysis of
a system to a conceptual shell that surrounds the application. Provided the
shell is not starved of processor resources (by the operating system defect, for
example), the shell ensures that safety policies are enforced no matter what
action is taken by the rest of the software. In other words, provided the shell
itself is dependable and can execute properly, safety will not be compromised
by defects in the remainder of the software including the operating system
and the application. With a protection shell in place, the testing of a system
can be focused on the shell. It is no longer necessary to undertake testing to
demonstrate ultradependability of the entire system. For many systems, this
alone might bring the number of test cases required down to a feasible value.
Specification limitation : This technique deliberately limits the range of values
that to a system input can take to the smallest possible set that is consistent
with safe operation. In many cases, the range of values that an input can take
is determined by an external physical device, such as a sensor, and the range
might be unnecessarily wide. It is the combination of the ranges of input values
5 It is literally the case that for most realistic systems, the number of tests required would take thousands
of years to complete, even under the most optimistic circumstances.