sch76183_ch01_001-034.indd 4
sch76183_ch01_001-034.indd 4 04/06/10 12:30 PM04/06/10 12:30 PM
The fi nancial implications of the software crisis are horrendous. In a survey conducted by the Cutter Consortium [2002], the following was reported:
• An astounding 78 percent of information technology organizations have been involved in disputes that ended in litigation.
• In 67 percent of those cases, the functionality or performance of the software products as delivered did not measure up to the claims of the software developers.
• In 56 percent of those cases, the promised delivery date slipped several times.
• In 45 percent of those cases, the faults were so severe that the software product was unusable.
It is clear that far too little software is delivered on time, within budget, fault free, and meeting its client’s needs. To achieve these goals, a software engineer has to acquire a broad range of skills, both technical and managerial. These skills have to be applied not just to programming but to every step of software production, from requirements to postdelivery maintenance.
That the software crisis still is with us, some 40 years later, tells us two things. First, the software process , that is, the way we produce software, has its own unique properties and problems, even though it resembles traditional engineering in many respects. Second, the software crisis perhaps should be renamed the software depression , in view of its long duration and poor prognosis.
We now consider economic aspects of software engineering.
1.2 Economic Aspects
A software organization currently using coding technique CT old discovers that new coding technique CT new would result in code being produced in only nine-tenths of the time needed by CT old and, hence, at nine-tenths the cost. Common sense seems to dictate that CT new is the appropriate technique to use. In fact, although common sense certainly dictates that FIGURE 1.1
The outcomes of over 9,000 development projects completed in 2006
[Rubenstein, 2007].
Successful 35%
Completed late, over budget, and/or with features missing
46%
Canceled 19%
the faster technique is the technique of choice, the economics of software engineering may imply the opposite.
• One reason is the cost of introducing new technology into an organization. The fact that coding is 10 percent faster when technique CT new is used may be less important than the costs incurred in introducing CT new into the organization. It may be necessary to complete two or three projects before recouping the cost of training. Also, while attending courses on CT new , software personnel are unable to do productive work. Even when they return, a steep learning curve may be involved; it may take many months of practice with CT new before software professionals become as profi cient with CT new as they currently are with CT old . Therefore, initial projects using CT new may take far longer to complete than if the organization had continued to use CT old . All these costs need to be taken into account when deciding whether to change to CT new .
• A second reason why the economics of software engineering may dictate that CT old
be retained is the maintenance consequence. Coding technique CT new indeed may be 10 percent faster than CT old , and the resulting code may be of comparable quality from the viewpoint of satisfying the client’s current needs. But the use of technique CT new may result in code that is diffi cult to maintain, making the cost of CT new higher over the life of the product. Of course, if the software developer is not responsible for any postdelivery maintenance, then, from the viewpoint of just that developer, CT new is a more attractive proposition. After all, the use of CT new would cost 10 percent less. The client should insist that technique CT old be used and pay the higher initial costs with the expectation that the total lifetime cost of the software will be lower. Unfortunately, often the sole aim of both the client and the software provider is to produce code as quickly as possible. The long-term effects of using a particular technique generally are ignored in the interests of short-term gain. Applying economic principles to software engineering requires the client to choose techniques that reduce long-term costs.
This example deals with coding, which constitutes less than 10 percent of the software development effort. The economic principles, however, apply to all other aspects of soft-ware production as well.
We now consider the importance of maintenance.
1.3 Maintenance Aspects
In this section, we describe maintenance within the context of the software life cycle.
A life-cycle model is a description of the steps that should be performed when build-ing a software product. Many different life-cycle models have been proposed; several of them are described in Chapter 2 . Because it is almost always easier to perform a sequence of smaller tasks than one large task, the overall life-cycle model is broken into a series of smaller steps, called phases . The number of phases varies from model to model—from as few as four to as many as eight. In contrast to a life-cycle model, which is a theoretical description of what should be done, the actual series of steps performed on a specifi c soft-ware product, from concept exploration through fi nal retirement, is termed the life cycle of that product. In practice, the phases of the life cycle of a software product may not be car-ried out exactly as specifi ed in the life-cycle model, especially when time and cost overruns
6 Chapter 1 The Scope of Software Engineering
sch76183_ch01_001-034.indd 6
sch76183_ch01_001-034.indd 6 04/06/10 12:30 PM04/06/10 12:30 PM
are encountered. It has been claimed that more software projects have gone wrong for lack of time than for all other reasons combined [Brooks, 1975].
Until the end of the 1970s, most organizations were producing software using as their life-cycle model what now is termed the waterfall model . There are many variations of this model, but by and large, a product developed using this classical life-cycle model goes through the six phases shown in Figure 1.2 . These phases probably do not correspond exactly to the phases of any one particular organization, but they are suffi ciently close to most practices for the purposes of this book. Similarly, the precise name of each phase varies from organization to organization. The names used here for the various phases have been chosen to be as general as possible in the hope that the reader will feel comfortable with them.
1. Requirements phase . During the requirements phase , the concept is explored and refi ned, and the client’s requirements are elicited.
2. Analysis (specifi cation) phase. The client’s requirements are analyzed and presented in the form of the specifi cation document , “what the product is supposed to do.”
The analysis phase sometimes is called the specifi cation phase. At the end of this phase, a plan is drawn up, the software project management plan , describing the proposed software development in full detail.
3. Design phase . The specifi cations undergo two consecutive design procedures during the
design phase . First comes architectural design , in which the product as a whole is broken down into components, called modules . Then, each module is designed; this procedure is termed detailed design . The two resulting design documents describe
“how the product does it.”
4. Implementation phase . The various components undergo coding and testing ( unit testing ) separately. Then, the components of the product are combined and tested as a whole; this is termed integration . When the developers are satisfi ed that the product functions correctly, it is tested by the client ( acceptance testing ). The implementa-tion phase ends when the product is accepted by the client and installed on the client’s computer. (We see in Chapter 15 that coding and integration should be performed in parallel.)
5. Postdelivery maintenance. The product is used to perform the tasks for which it was developed. During this time, it is maintained. Postdelivery maintenance includes all changes to the product once the product has been delivered and installed on the client’s computer and passes its acceptance test. Postdelivery maintenance FIGURE 1.2
The six phases of the classical life-cycle model.
1. Requirements phase
2. Analysis (specification) phase 3. Design phase
4. Implementation phase 5. Postdelivery maintenance 6. Retirement
includes corrective maintenance (or software repair ), which consists of the removal of residual faults while leaving the specifications unchanged, as well as
enhancement (or software update), which consists of changes to the specifi-cations and the implementation of those changes. There are, in turn, two types of enhancement. The first is perfective maintenance , changes that the client thinks will improve the effectiveness of the product, such as additional functional-ity or decreased response time. The second is adaptive maintenance , changes made in response to changes in the environment in which the product operates, such as a new hardware/operating system or new government regulations. (For an insight into the three types of postdelivery maintenance, see Just in Case You Wanted to Know Box 1.3.)
6. Retirement . Retirement occurs when the product is removed from service. This occurs when the functionality provided by the product no longer is of any use to the client organization.
Now we examine the defi nition of maintenance in greater detail.