3

Software Life Cycle Models and Processes

A software life cycle is a phased approach to developing software, with specic deliverables and milestones within each phase. A software life cycle model is an abstraction of the software development process, which is convenient to use for planning purposes. This chapter takes a software life cycle perspective on software development. Different software life cycle models (also referred to as software process models), including the spiral model and the Unied Software Development Process, are briey described and compared. The roles of design verication and validation and of software testing are discussed.

3.1 SOFTWARE LIFE CYCLE MODELS

The waterfall model was the earliest software life cycle model to be widely used. This section starts with an overview of the waterfall model. It then outlines alternative software life cycle models that have since been developed to overcome some of the limitations of the waterfall model. These are the throwaway prototyping life cycle model, the incremental development life cycle model (also referred to as evolutionary prototyping), the spiral model, and the Unied Software Development Process.

3.1.1 Waterfall Life Cycle Model

Since the 1960s, the cost of developing software has grown steadily and the cost of developing and purchasing hardware has rapidly decreased. Furthermore, software now typically costs eighty percent of a total projects budget, whereas in the early days of software development, the hardware was by far the largest project cost (Boehm 2006). The problems involved in developing software were not clearly understood in the 1960s. In the late sixties, it was realized that a software crisis existed. The term software engineering was coined to refer to the management and technical methods, procedures, and tools required to effectively develop a large-scale software system. With the application of software engineering concepts, many large-scale software

29

30

Overview

systems have been developed using a software life cycle. The rst widely used software life cycle model, often referred to as the waterfall model, is shown in Figure 3.1. It is generally considered the conventional or classical software life cycle. The waterfall model is an idealized process model in which each phase is completed before the next phase is started, and a project moves from one phase to the next without iteration or overlap.

3.1.2 Limitations of the Waterfall Model

The waterfall model is a major improvement over the undisciplined approach used on early software projects and has been used successfully on many projects. In practice, however, some overlap is often necessary between successive phases of the life cycle, as well as some iteration between phases when errors are detected (Figure 3.2). Moreover, for some software development projects, the waterfall model presents the following signicant problems:

Software requirements, a key factor in any software development project, are not properly tested until a working system is available to demonstrate to the end-users. In fact, several studies have shown that errors in the requirements specication are usually the last to be detected (often not until system or acceptance testing) and the most costly to correct. A working system becomes available only late in the life cycle. Thus, a major design or performance problem might go undetected until the system is almost operational, at which time it is usually too late to take effective action.

For software development projects with a signicant risk factor for example, due to requirements that are not clearly understood or are expected to change variations or alternatives to the waterfall model have been proposed. Two different software prototyping approaches have been used to overcome some of the limitations of the waterfall model: throwaway prototypes and evolutionary prototypes. Throwaway prototypes can help resolve the rst problem of the waterfall model, which was described in the preceding list, and evolutionary prototypes can help resolve the second problem.

3.1.3 Throwaway Prototyping

Throwaway prototypes can be used to help clarify user requirements. This approach is particularly useful for getting feedback on the user interface and can be used for systems that have a complex user interface. A throwaway prototype may be developed after a preliminary requirements specication (Figure 3.3). By giving users the capability of exercising the prototype, much valuable feedback can be obtained that is otherwise frequently difcult to get. Based on this feedback, a revised requirements specication can be prepared. Subsequent development proceeds, following the conventional software life cycle. Throwaway prototyping, particularly of the user interface, has been shown to be an effective solution to the problem of specifying requirements for interactive information systems. Gomaa (1990) described how a throwaway prototype was used to help clarify the requirements of a highly interactive manufacturing application.

System & Acceptance Testing

Integration Testing

Unit Testing

Coding

DetailedDesign

Architectural Design

Figure 3.1. Waterfall model

Requirements Analysis & Specification

31

System & Acceptance Testing

Integration Testing

Unit Testing

Coding

DetailedDesign

Figure 3.2. Waterfall model with iteration between phases

Architectural Design

Requirements Analysis & Specification

32

System & Acceptance Testing

Integration Testing

Unit Testing

Coding

DetailedDesign

Architectural Design

Figure 3.3. Throwawa y prototypin g of software requireme nts

Requirements Analysis & Specification

ThrowawayProto typing

33

34

Overview

The biggest problem it helped overcome was the communications barrier that existed between the users and the developers. Throwaway prototypes can also be used for experimental prototyping of the design (Figure 3.4). This can be used to determine if certain algorithms are logically correct or to determine if they meet their performance goals.

3.1.4 Evolutionary Prototyping by Incremental Development

The evolutionary prototyping approach is a form of incremental development in which the prototype evolves through several intermediate operational systems (Figure 3.5) into the delivered system. This approach can help in determining whether the system meets its performance goals and in testing critical components of the design. It also reduces development risk by spreading the implementation over a longer time frame. Use cases and scenario-based communication diagrams can be used to assist in selecting system subsets for each increment. One objective of the evolutionary prototyping approach is to have a subset of the system working early, which is then gradually built on. It is advantageous if the rst incremental version of the system tests a complete path through the system from external input to external output. An example of evolutionary prototyping by means of incremental development is described in Gomaa (1990). Using this approach on a real-time robot controller system (Gomaa 1986) resulted in availability of an early operational version of the system, providing a big morale boost for both the development team and management. It also had the important benets of verifying the system design, establishing whether certain key algorithms met their performance goals, and spreading system integration over time.

3.1.5 Combining Throwaway Prototyping and Incremental Development

With the incremental development life cycle model approach, a working system in the form of an evolutionary prototype is available signicantly earlier than with the conventional waterfall life cycle. Nevertheless, much greater care needs to be taken in developing this kind of prototype than with a throwaway prototype because it forms the basis of the nished product; thus, software quality has to be built into the system from the start and cannot be added as an afterthought. In particular, the software architecture needs to be carefully designed and all interfaces specied. The conventional waterfall life cycle is impacted signicantly by the introduction of throwaway prototyping or incremental development. It is also possible to combine the two approaches, as shown in Figure 3.6. A throwaway prototyping exercise is carried out to clarify the requirements. After the requirements are understood and a specication is developed, an incremental development life cycle is pursued. After subsequent increments, further changes in requirements might be necessary owing to changes in the user environment.

3.1.6 Spiral Model

The spiral model is a risk-driven process model originally developed by Boehm (1988) to address known problems with earlier process models of the software life

System & Acceptance Testing

Incremental System Integration

IncrementalCompo nentConstruction

Architectural Design

ThrowawayProto typing

Figure 3.4. Throwawa y prototypin g of architectur al design

Requirements Analysis & Specification

35

System & Acceptance Testing

Incremental System Integration

IncrementalCompo nentConstruction

EvolutionaryProt otyping

Architectural Design

Figure 3.5. Increment al developme nt software life cycle

Requirements Analysis & Specification

36

System & Acceptance Testing

Incremental System Integration

Figure 3.6. Combined throwaway prototypin g with increment al developme nt software life cycle model
EvolutionaryProt otyping

IncrementalCompo nentConstruction

Architectural Design

Requirements Analysis & Specification

ThrowawayProto typing

37

38

Overview

1. Define objectives, alternatives, and constraints

2. Analyze risks

4. Plan next cycle

3. Develop product

Figure 3.7. Spiral process model

cycle in particular, the waterfall model. The spiral model is intended to encompass other life cycle models, such as the waterfall model, the incremental development model, and the throwaway prototyping model. In the spiral model, the radial coordinate represents cost, and the angular coordinate represents progress in completion of a cycle of the model. The spiral model consists of the following four quadrants, as shown in Figure 3.7: 1. Dene objectives, alternatives, and constraints. Detailed planning for this cycle: identify goals and alternative approaches to achieving them. 2. Analyze risks. Detailed assessment of current project risks; plan activities to be performed to alleviate these risks. 3. Develop product. Work on developing product, such as requirements analysis, design, or coding. 4. Plan next cycle. Assess progress made on this cycle and start planning for next cycle.

Each cycle of the spiral model iterates through these four quadrants, although the number of cycles is project-specic. The descriptions of the activities in each quadrant are intended to be general enough that they can be included in any cycle. The goal of the spiral model is to be risk-driven, so the risks in a given cycle are determined in the analyze risks quadrant. To manage these risks, certain additional project-specic activities may be planned to address the risks, such as requirements prototyping if the risk analysis indicates that the software requirements are not clearly understood. These project-specic risks are termed process drivers. For any process driver, one or more project-specic activities need to be performed to manage the risk (Boehm and Belz 1990). An example of identifying a project-specic risk is to determine that the initial software requirements are not well understood. A project-specic activity performed to manage the risk is to develop a throwaway prototype, with the goal of getting feedback from the users in order to help clarify the requirements.

Software Life Cycle Models and Processes

39

Phases Core Workflows

Inception Elaboration Construction Transition

Requirements

Analysis

Design

Implementation

Test

iteration iteration #2 #1

---

---

---

---

---

iteration iteration #n-1 #n

Iterations

Figure 3.8. Unied Software Development Process (Jacobson et al, THE UNIFIED SOFTWARE DEVELOPMENT PROCESS, Figure 1.5 Unied Software Development Process p. 11, c 1999 Pearson Education, Inc. Reproduced by permission of Pearson Education, Inc.)

3.1.7 Unied Software Development Process

The Unied Software Development Process (USDP), as described in Jacobson et al. (1999), is a use casedriven software process that uses the UML notation. The USDP is also known as the Rational Unied Process (RUP) (Kroll and Kruchten 2003; Kruchten 2003). USDP/RUP is a popular process for UML-based software development. This section describes how the PLUS method can be used with the USDP/RUP process. The USDP consists of ve core workows and four phases and is iterative, as shown in Figure 3.8. An artifact is dened as a piece of information that is produced, modied, or used by a process (Kruchten 2003). A workow is dened as a sequence of activities that produces a result of observable value (Kruchten 2003). A phase is dened as the time between two major milestones during which a well-dened set of objectives is met, artifacts are completed, and decisions about whether to move on to the next phase are made (Kruchten 2003). There is usually more than one iteration in a phase; thus, a phase iteration in USDP corresponds to a cycle in the spiral model. Each cycle goes through all four phases and addresses the development of a core workow. The workows and products of each workow are as follows:

1. Requirements. The product of the requirements workow is the use case model. 2. Analysis. The product of the analysis workow is the analysis model. 3. Design. The products of the design workow are the design model and the deployment model.

40

Overview

4. Implementation. The product of the implementation workow is the implementation model. 5. Test. The product of the test workow is the test model.

Like the spiral model, the USDP is a risk-driven process. The life cycle phases of the USDP are as follows (Jacobson, Booch, and Rumbaugh 1999; Kruchten 2003):

1. Inception. During the inception phase, the seed idea is developed to a sufcient level to justify entering the elaboration phase. 2. Elaboration. During the elaboration phase, the software architecture is dened. 3. Construction. During the construction phase, the software is built to the point at which it is ready for release to the user community. 4. Transition. During the transition phase, the software is turned over to the user community.

3.2 DESIGN VERIFICATION AND VALIDATION

Boehm (1981) differentiates between software validation and software verication. The goal of software validation is to ensure that the software development team builds the right system, that is, to ensure that the system conforms to the users needs. The goal of software verication is to ensure that the software development team builds the system right, that is, to ensure that each phase of the software system is built according to the specication dened in the previous phase. Topics discussed briey in this section are software quality assurance and performance analysis of software designs. Another important activity is testing the fully integrated system against the software requirements, which is carried out during system testing, as described in Section 3.3 on software testing.

3.2.1 Software Quality Assurance

Software quality assurance is a name given to a set of activities whose goal is to ensure the quality of the software product. Software verication and validation are important goals of software quality assurance. Throwaway prototyping can be used for validation of the system (before it is developed) against the user requirements, to help ensure that the team builds the right system, that is, a system that actually conforms to the users requirements. Throwaway prototypes can also be used for experimental prototyping of the design. Software technical reviews can help considerably with software verication and validation. In software verication, it is important to ensure that the design conforms to the software requirements specication. Requirements tracing and technical reviews of the software design help with this activity.

Software Life Cycle Models and Processes

41

3.2.2 Performance Analysis of Software Designs

Analyzing the performance of a software design before implementation is necessary to estimate whether the design will meet its performance goals. If potential performance problems can be detected early in the life cycle, steps can be taken to overcome them. Approaches for evaluating software designs use queuing models (Menasce, Almeida, and Dowdy 2004; Menasce, Gomaa, and Kerschberg 1995; Menasce and Gomaa 2000) and simulation models (Smith 1990). For concurrent systems, Petri nets (David 1994; Jensen 1997; Pettit and Gomaa 2006; Stansifer 1994) can be used for modeling and analyzing concurrent designs. An approach described in (Gomaa 2000) is to analyze the performance of real-time designs by using real-time scheduling theory.

3.3 SOFTWARE LIFE CYCLE ACTIVITIES

Whichever software life cycle is adopted, the software engineering activities briey described in the following sections will need to be carried out.

3.3.1 Requirements Analysis and Specication

In this phase, the users requirements are identied and analyzed. The requirements of the system to be developed are specied in a Software Requirements Specication (SRS). The SRS is an external specication of the software. Its goal is to provide a complete description of what the systems external behavior is without describing how the system works internally. The issues of what constitutes a SRS are described lucidly in Davis (1993). With some systems, such as embedded systems, in which the software is part of a larger hardware/software system, it is likely that a systems requirements analysis and specication phase precedes the software requirements analysis and specication. With this approach, system functional requirements are allocated to software and hardware before software requirements analysis begins (Davis 1993).

3.3.2 Architectural Design

A software architecture (Bass, Clements, and Kazman 2003; Shaw and Garlan 1996) separates the overall structure of the system, in terms of components and their interconnections, from the internal details of the individual components. The emphasis on components and their interconnections is sometimes referred to as programming-in-the-large, and detailed design of individual components is referred to as programming-in-the-small. During this phase, the system is structured into its constituent components and the interfaces between these components are dened.

3.3.3 Detailed Design

During the detailed design phase, the algorithmic details of each system component are dened. This is often achieved using a Program Design Language (PDL)

42

Overview

notation, also referred to as Structured English or pseudocode. Internal data structures are also designed.

3.3.4 Coding
During the coding phase, each component is coded in the programming language selected for the project. Usually a set of coding and documentation standards have to be adhered to.

3.4 SOFTWARE TESTING

Because of the difculty of detecting errors and then locating and correcting the detected errors, software systems are usually tested in several stages (Ammann and Offutt 2008). Unit and integration testing are white box testing approaches, requiring knowledge of the internals of the software; system testing is a black box testing approach based on the software requirements specication, without knowledge of the software internals.

3.4.1 Unit Testing

In unit testing, an individual component is tested before it is combined with other components. Unit testing approaches use test-coverage criteria. Frequently used test-coverage criteria are statement coverage and branch coverage. Statement coverage requires that each statement should be executed at least once. Branch coverage requires that every possible outcome of each branch should be tested at least once.

3.4.2 Integration Testing

Integration testing involves combining tested components into progressively more complex groupings of components and then testing these groupings until the whole software system has been put together and the interfaces tested.

3.4.3 System Testing

System testing is the process of testing an integrated hardware and software system to verify that the system meets its specied requirements (IEEE 1990). The whole system or major subsystems are tested to determine conformance with the requirements specication. To achieve greater objectivity, it is preferable to have system testing performed by an independent test team. During system testing, several features of the software system need to be tested (Beizer 1995). These include the following:

Functional testing. To determine that the system performs the functions described in the requirements specication. Load (stress) testing. To determine whether the system can handle the large and varied workload it is expected to handle when operational.

Software Life Cycle Models and Processes

43

Performance testing. To test that the system meets its response time requirements.

3.4.4 Acceptance Testing

The user organization or its representative usually carries out acceptance testing, typically at the user installation, prior to acceptance of the system. Most of the issues relating to system testing also apply to acceptance testing.

3.5 SUMMARY
This chapter has taken a software life cycle perspective on software development. Various software life cycle models, also referred to as software process models (including the spiral model and the Unied Software Development Process) were briey described and compared. The roles of design verication and validation and of software testing were discussed. Chapter 5 describes the use casebased software life cycle for the COMET method.

EXERCISES
Multiple-choice questions: For each question, choose one of the answers. 1. What is a software life cycle? (a) The life of the software (b) A cyclic approach to developing software (c) A phased approach to developing software (d) The life of software developed in cycles 2. What is the waterfall life cycle model? (a) Software developed under a waterfall (b) A process model in which each phase is completed before the next phase is started (c) A process model in which phases are overlapped (d) A process model in which phases are cyclic 3. Which of the following is a limitation of the waterfall life cycle model? (a) Software is developed in phases. (b) Each phase is completed before the next phase is started. (c) Software development is cyclic. (d) Software requirements are not properly tested until a working system is available.

4. Which of the following approaches can overcome the limitation in the previous question? (a) Phased software development (b) Throwaway prototyping (c) Evolutionary prototyping (d) Incremental development 5. What is evolutionary prototyping? (a) Phased software development (b) Throwaway prototyping (c) Risk-driven development (d) Incremental development 6. What approach does the spiral model emphasize? (a) Phased software development (b) Throwaway prototyping (c) Risk-driven development (d) Incremental development 7. What is the goal of software validation? (a) Building the system (b) Building the right system (c) Building the system right (d) Testing the system 8. What is the goal of software verication? (a) Building the system (b) Building the right system (c) Building the system right (d) Testing the system