Software errors, faults and failures

2.2 Software errors, faults and failures

“We’ve used the Simplex HR software in our Human Resources Department for about three years and we have never had a software failure.”

“I started to use Simplex HR two months ago; we had so many failures that we are considering replacing the software package.”

“We have been using the same software package for almost four years. We were very satisfied throughout the period until the last few months, when we suddenly faced several severe failures. The Support Center of the software house from which we bought the package claims that they have never encountered failures of the type we experienced even though they serve about 700 customers who utilize Simplex HR.”

All these views, expressed by participants in a human resources management conference, refer to the same software package. Is it possible for such a vari- ation in users’ experience with failure to appear with the same software package? Can a software package that successfully served an organization for

a long period “suddenly” change its nature (quality) and become “bugged”? The answer to these questions is yes, and it is rooted in the characteris- tics of software. The origin of software failures lies in a software error made by a pro- grammer. An error can be a grammatical error in one or more of the code lines, or a logical error in carrying out one or more of the client’s requirements.

However, not all software errors become software faults. In other words, in some cases, the software error can cause improper functioning of the soft- ware in general or in a specific application. In many other cases, erroneous code lines will not affect the functionality of the software as a whole; in a part of these cases, the fault will be corrected or “neutralized” by subsequent code lines.

17 the software. This requires us to examine the relationship between software

We are interested mainly in the software failures that disrupt our use of

faults and software failures. Do all software faults end with software fail-

ures? Not necessarily: a software fault becomes a software failure only when

Softw

it is “activated” – when the software user tries to apply the specific, faulty application. In many situations, a software fault is never activated due to the user’s lack of interest in the specific application or to the fact that the com-

are errors,

bination of conditions necessary to activate the fault never occurs. Example 1: The “Pharm-Plus” software package

fa

“Pharm-Plus”, a software package developed for the operations required of

a pharmacy chain, included several software faults, such as the following:

ults

and f

(a) The chain introduced a software requirement to avoid the current sale

of goods to customers whose total debts will exceed $200 upon com- pletion of the current sale. Unfortunately, the programmer erroneously

a ilures

put the limit at $500, a clear software fault. However, a software failure never occurred as the chain’s pharmacies do not offer credit to their cus- tomers, that is, sales are cash sales or credit card sales.

(b) Another requirement introduced was the identification of “super cus- tomers”. These were defined as those customers of the pharmacy who made a purchase at least once a month, the average value of that pur- chase made in the last M months (e.g., 12 months) being more than N times (e.g., five times) the value of the average customer’s purchase at the pharmacy. It was required that once “super customers” reached the cashier, they would be automatically identified by the cash register. (The customers could then be treated accordingly, by receiving a special dis- count or gift, for example.) The software fault (caused by the system analyst) was that “super customers” could be identified solely by the value of their current purchase. In other words, customers whose regu- lar purchases consisted of only one or two low-cost items could mistakenly be identified as “super customers”.

At this particular chain, this software fault never turned into a software fail- ure because its pharmacies, which allow for cash sales or credit card sales only, were unconcerned about identifying their customers, and were thus uninterested in applying the “super customer” option. This was the case for several years until the management of a new pharmacy decided to promote sales by developing customer–pharmacy relationships, and chose to imple- ment the “super customer” option offered by “Pharm-Plus”. The pharmacy defined a “super customer” to be a person whose average purchase in the last three months (M = 3) was over 10 times (N = 10) the value of the aver- age purchase made in the pharmacy. In order to execute their marketing strategy, management began to distribute a pharmacy ID card to their cus- tomers, who were asked to show the card to the cashier. The cashiers were

18 instructed to give special treatment to customers who were identified by the cash register as “super customers”. It was soon observed that customers who

2 entered the pharmacy for the first time as well as those who were recognized W

h as frequent purchasers of only one or two items were identified as “super

a customers”. In this case, the severe software fault turned into a severe soft- t is

ware failure. Obviously, circumstances could have hidden this serious case of

softw

a severe software fault forever.

are quality?

Example 2: The “Meteoro-X” meteorological equipment firmware The software requirements for “Meteoro-X” meteorological equipment firmware (software embedded in the product) were meant to block the equipment’s operation when its internal temperature rose above 60°C. A programmer error resulted in a software fault when the temperature limit was coded as 160°. This fault could cause damage when the equipment was subjected to temperatures higher than 60°. Because the equipment was used only in those coastal areas where temperatures never exceeded 60°, the soft- ware fault never turned into a software failure.

These examples should adequately make the point that only a portion of the software faults, and in some cases only a small portion of them, will turn into software failures in either the early or later stages of the software’s appli- cation. Other software faults will remain hidden, invisible to the software users, yet capable of being activated when the situation changes.

Figure 2.1 illustrates the relationships between software errors, faults and failures. In this figure, the development process yields 17 software errors, only eight of which become software faults. Of these faults, only three turnout to be software failures.

Importantly, developers and users have different views of the software product regarding its internal defects. While developers are interested in soft- ware errors and faults, their elimination, and the ways to prevent their generation, software users are worried about software failures.

Software development process

software failure Figure 2.1: Software errors, sotware faults and software failures

software error

software fault

2.3 Classification of the causes of software errors

2.3 C

As software errors are the cause of poor software quality, it is important to investigate the causes of these errors in order to prevent them. A software error can be “code error”, a “procedure error”, a “documentation error”, or

la

ss ific

a “software data error”. It should be emphasized that the causes of all these

errors are human, made by systems analysts, programmers, software testers, documentation experts, managers and sometimes clients and their represen-

ation of

tatives. Even in rare cases where software errors may be caused by the development environment (interpreters, wizards, automatic software gener- ators, etc.), it is reasonable to claim that it is human error that caused the

the c

failure of the development environment tool. The causes of software errors can be further classified as follows according to the stages of the software

development process in which they occur.

u se s

(1) Faulty definition of requirements of

softw

The faulty definition of requirements, usually prepared by the client, is

one of the main causes of software errors. The most common errors of this type are:

ar

e err

Erroneous definition of requirements.

or

Absence of vital requirements.

Incomplete definition of requirements. For instance, one of the require- ments of a municipality’s local tax software system refers to discounts granted to various segments of the population: senior citizens, parents of large families, and so forth. Unfortunately, a discount granted to students was not included in the requirements document.

Inclusion of unnecessary requirements, functions that are not expected to

be needed in the near future. (2) Client–developer communication failures

Misunderstandings resulting from defective client–developer communication are additional causes for the errors that prevail in the early stages of the development process:

Misunderstanding of the client’s instructions as stated in the requirement document.

Misunderstanding of the client’s requirements changes presented to the developer in written form during the development period.

Misunderstanding of the client’s requirements changes presented orally to the developer during the development period.

Misunderstanding of the client’s responses to the design problems pre- sented by the developer.

20 ■ Lack of attention to client messages referring to requirements changes and to client responses to questions raised by the developer on the part of