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

three categories. Although the definitions imply reliability treatment, nevertheless,
they are risks, and from a severity and safety standpoint, and for some applications,
defects can be more hazardous than faults and failures. These are repeated below:
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.
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.
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.
Other definitions and terminology that may be useful in reading the rest of this
chapter are listed in Appendix 15.A.
15.2 PLANNING FOR RISK MANAGEMENT ACTIVITIES IN DESIGN
AND DEVELOPMENT
A business risk can be defined as a potential threat to achieving business objectives
for the software under development, these risks are related to but not limited to
technology maturity, software complexity, software reliability and availability, per-
formance and robustness, and finally, project timelines. Safety risk is defined as the
potential threat to software-produced health and environment failures for the product
under development; these risks are related to but not limited to failure, defect, fault
nonconformities, customer misuse and abuse, systems integration, and so on. When
considering safety risks, it is apparent that it can be classified as business risk result-
ing from the criteria mentioned. It is isolated in a category by itself for its profound
effect on the end user. The emphasis on decoupling safety risk from business risk is
to manage the complexity of the rigor applied to reduce and eliminate safety risks
as a result of the software regulatory expectations for risk management in indus-
tries such as aerospace. A structured approach for risk management, as described
throughout this chapter, is required by a software DFSS teams when safety risk and
regulatory compliance are impacted. Contrasting rigor is required when dealing with
only business risks.