SOFTWARE DESIGN FOR X - Software Design for Six-Sigma: A Roadmap for Excellence - page 362

Software reliability as a discipline of software assurance has many attributes:
1) it defines the requirements for software-controlled system fault/failure detection,
isolation, and recovery; 2) it reviews the software development processes and products
for software error prevention and/or reduced functionality states; and, 3) it defines
the process for measuring and analyzing defects and defines/derives the reliability
and maintainability factors.
The modeling technique for software reliability is reaching its prosperity, but
before using the technique, we must carefully select the appropriate model that can
best suit our case. Measurement in software is still in its infancy. No good quantitative
methods have been developed to represent software reliability without excessive
limitations. Various approaches can be used to improve the reliability of software;
however, it is hard to balance development time and budget with software reliability.
This section will provide software DFSS belts with a basic overview of soft-
ware reliability, tools, and resources on software reliability as a prerequisite for
covering DFR.

14.2.1 Basic Software Reliability Concepts

Software reliability is a measure of the software nonconformances that are visible to
a customer and prevent a system from delivering essential functionality. Nonconfor-
mances can be categorized as:

Defects : A flaw in software requirements, design, or source code that produces
unintended or incomplete run-time behavior. This includes defects of commis-
sion and defects of omission. Defects of commission are one of the following:
Incorrect requirements are specified, requirements are incorrectly translated into
a design model, the design is incorrectly translated into source code, and the
source code logic is flawed. Defects of omission are one of the following: Not
all requirements were used in creating a design model, the source code did not
implement all the design, or the source code has missing or incomplete logic.
Defects are static and can be detected and removed without executing the source
code. Defects that cannot trigger software failures are not tracked or measured
for reliability purposes. These are quality defects that affect other aspects of
software quality such as soft maintenance defects and defects in test cases or
documentation.
Faults : A fault is the result of triggering a software defect by executing the
associated source code. Faults are NOT customer-visible. An example is a
memory leak or a packet corruption that requires retransmission by the higher
layer stack. A fault may be the transitional state that results in a failure. Trivial,
simple defects (e.g., display spelling errors) do not have intermediate fault states.
Failures : A failure is a customer (or operational system) observation or detection
that is perceived as an unacceptable departure of operation from the designed
software behavior. Failures are the visible, run-time symptoms of faults. Failures
MUST be observable by the customer or another operational system. Not all