Information Technology Reference
In-Depth Information
and discussed within the profession. There exist copious amounts of
readily available literature analyzing failures in other industries such as
transportation, construction, and medicine. This lack of availability of
information about actual failures prevents the introduction of improve-
ments as engineers continue to learn the hard way by churning out fail-
prone software. Before arguing that a software system is more complex
than most mechanical or structural systems that we build, and that some
leeway should be given, there is a need to look at the various aspects of
failure in software.
A Formal Definition of Failure
Although the etymology of “failure” is not entirely clear, it likely derives
from the Latin
, meaning “to deceive.” Webster's dictionary defines
failure as “omission of occurrence or performance; or a state of inability
to perform a normal function.” It is important to note that it is not necessary
that the entire system be non-operational for it to be considered a failure.
Conversely, a single “critical” component failing to perform may result in
the failure of the entire system. For example, one would not consider a
car headlamp malfunction a failure of the car; however, one would
consider a non-working fuel injection system as a failure. Why the dis-
tinction? Because the primary job of a car is conveyance. If it cannot do
that, it has failed in its job. The distinction is not always so clear. In some
cases, for example, while driving at night, a broken headlamp might be
considered a failure. So how do we define software failures? Is a bug a
failure? When does a bug become a failure? In software, failure is used
to imply that:
fallere
The software has become inoperable.
This can happen because of
a
bug that causes the application to terminate abnormally.
This type of failure should never happen in an end-customer
scenario. Most organizations have mandatory guidelines about QA
(quality assurance) — that no software should ship to a customer
until all
critical
bugs have been fixed (see Chapter 12
on quality). All things being equal, such a failure usually signifies
that there is a problem outside the software boundary — the
hardware, external software interacting with your software, or some
viruses.
critical
and
serious
The software is operable but is not delivering to its desired specifi-
cations.
This may be due to a genuine oversight on the part of
the development team, or a misunderstanding in the user require-
ments. Sometimes these requirements may be undocumented, such
