The software development life cycle (SDLC) model
7.1.1 The software development life cycle (SDLC) model
The classic Software Development Life Cycle (SDLC) model is a linear sequential model that begins with requirements definition and ends with reg- ular system operation and maintenance. The most common illustration of the SDLC model is the waterfall model, shown in Figure 7.1.
The model shown in Figure 7.1 presents a seven-phase process, as follows:
Requirements definition. For the functionality of the software system to
be developed, the customers must define their requirements. In many cases the software system is part of a larger system. Information about the other parts of the expanded system helps establish cooperation between the teams and develop component interfaces.
Analysis. The main effort here is to analyze the requirements’ implica- tions to form the initial software system model.
REQUIREMENTS
7 DEFINITION
Integr ating quality ANALYSIS
DESIGN
activ ities
CODING
in the project
SYSTEM TESTS
life cycl
INSTALLATION AND CONVERSION
OPERATION AND MAINTENANCE
Figure 7.1: The waterfall model Source: After Boehm (1981) and Royce (1970) (© 1970 IEEE)
Design. This stage involves the detailed definition of the outputs, inputs and processing procedures, including data structures and databases, soft- ware structure, etc.
Coding. In this phase, the design is translated into a code. Coding involves quality assurance activities such as inspection, unit tests and integration tests.
System tests. System tests are performed once the coding phase is com- pleted. The main goal of testing is to uncover as many software errors as possible so as to achieve an acceptable level of software quality once cor- rections have been completed. System tests are carried out by the software developer before the software is supplied to the customer. In many cases the customer performs independent software tests (“accept- ance tests”) to assure him or herself that the developer has fulfilled all the commitments and that no unanticipated or faulty software reactions are System tests. System tests are performed once the coding phase is com- pleted. The main goal of testing is to uncover as many software errors as possible so as to achieve an acceptable level of software quality once cor- rections have been completed. System tests are carried out by the software developer before the software is supplied to the customer. In many cases the customer performs independent software tests (“accept- ance tests”) to assure him or herself that the developer has fulfilled all the commitments and that no unanticipated or faulty software reactions are
7.1 C
Installation and conversion. After the software system is approved, the system is installed to serve as firmware, that is, as part of the information system that represents a major component of the expanded system. If the
la
ss
new information system is to replace an existing system, a software con-
ic and other sof
version process has to be initiated to make sure that the organization’s
activities continue uninterrupted during the conversion phase.
Regular operation and maintenance. Regular software operation begins once installation and conversion have been completed. Throughout the regular operation period, which usually lasts for several years or until a new software generation appears on the scene, maintenance is needed. Maintenance incorporates three types of services: corrective – repairing
tw
software faults identified by the user during operation; adaptive – using
are development
the existing software features to fulfill new requirements; and perfective – adding new minor features to improve software performance.
The number of phases can vary according to the characteristics of the proj- ect. In complex, large-scale models, some phases are split, causing their number to grow to eight, nine or more. In smaller projects, some phases may
be merged, reducing the number of phases to six, five or even four phases.
methodologies
At the end of each phase, the outputs are examined and evaluated by the developer and, in many cases, by the customer as well. Possible outcomes of the review and evaluation include:
Approval of the phase outputs and progress on to the next phase, or
Demands to correct, redo or change parts of the last phase; in certain cases, a return to earlier phases is required.
The width of the lines connecting the rectangular boxes in the illustration reflects the relative probabilities of the different outcomes. Thus, the most commonly performed process is a linear sequence (no or only minor correc- tions). We should note, however, that the model emphasizes direct development activities and does not indicate customer stakes in the develop- ment process.
The classic waterfall model was suggested by Royce (1970) and later presented in its commonly known form by Boehm (1981). It provides the foundations for the majority of the major software quality assurance stan- dards employed, such as IEEE Std 1012 (IEEE, 1998) and IEEE Std 12207 (IEEE, 1996, 1997a, 1997b), to mention just two.