Page 242 -

CHAPTER 8 SOFTWARE QUALITY ASSURANCE 213

Many researchers argue that MTBF is a far more useful measure than defects/KLOC
? Why is MTBF or defects/FP. Stated simply, an end-user is concerned with failures, not with the total
a more useful
metric than error count. Because each error contained within a program does not have the same
defects/KLOC? failure rate, the total error count provides little indication of the reliability of a sys-
tem. For example, consider a program that has been in operation for 14 months. Many
errors in this program may remain undetected for decades before they are discov-
ered. The MTBF of such obscure errors might be 50 or even 100 years. Other errors,
as yet undiscovered, might have a failure rate of 18 or 24 months. Even if every one
of the first category of errors (those with long MTBF) is removed, the impact on soft-
ware reliability is negligible.
In addition to a reliability measure, we must develop a measure of availability.
Software availability is the probability that a program is operating according to require-
ments at a given point in time and is defined as
Availability = [MTTF/(MTTF + MTTR)] 100%

The MTBF reliability measure is equally sensitive to MTTF and MTTR. The availabil-
ity measure is somewhat more sensitive to MTTR, an indirect measure of the main-
tainability of software.

8.8.2 Software Safety
Leveson [LEV86] discusses the impact of software in safety critical systems when she
writes:
Before software was used in safety critical systems, they were often controlled by conven-
tional (nonprogrammable) mechanical and electronic devices. System safety techniques
are designed to cope with random failures in these [nonprogrammable] systems. Human
design errors are not considered since it is assumed that all faults caused by human errors
can be avoided completely or removed prior to delivery and operation.
When software is used as part of the control system, complexity can increase by an
order of magnitude or more. Subtle design faults induced by human error—some-
“I cannot imagine thing that can be uncovered and eliminated in hardware-based conventional con-
any condition which trol—become much more difficult to uncover when software is used.
would cause this
ship to founder. Software safety is a software quality assurance activity that focuses on the identi-
Modern shipbuilding fication and assessment of potential hazards that may affect software negatively and
has gone beyond cause an entire system to fail. If hazards can be identified early in the software engi-
that.”
neering process, software design features can be specified that will either eliminate
E.I. Smith, captain or control potential hazards.
of the Titanic
A modeling and analysis process is conducted as part of software safety. Initially,
hazards are identified and categorized by criticality and risk. For example, some of the
hazards associated with a computer-based cruise control for an automobile might be

• causes uncontrolled acceleration that cannot be stopped
• does not respond to depression of brake pedal (by turning off)