Contents

2.1 SDLC Models

2.1.1 Build and Fix Model
2.1.2 The Waterfall Model
2.1.3 Prototyping Model
2.1.4 Iterative Enhancement Model
2.1.5 Evolutionary Development Model
2.1.6 Spiral Model
2.1.7 The Rapid Application Development (RAD) Model
2.2 Selection of a Life Cycle Model
2.2.1 Characteristics of Requirements
2.2.2 Status of Development Team
2.2.3 Involvement of Users
2.2.4 Type of Project and Associated Risk
The goal of software engineering is to provide models and processes that lead to the production
of well-documented maintainable software in a manner that is predictable. For a mature process,
it should be possible to determine in advance how much time and effort will be required to
produce the final product. This can only be done using data from past experience, which requires
that we must measure the software process.
Software development organizations follow some process when developing a software
product. In immature organizations, the process is usually not written down. In mature
organizations, the process is in writing and is actively managed. A key component of any
software development process is the life cycle model on which the process is based. The particular
life cycle model can significantly affect overall life cycle costs associated with a software product
[RAKI97]. Life cycle of the software starts from concept exploration and ends at the retirement
of the software.
In the IEEE standard Glossary of software Engineering Terminology, the software life
cycle is:
“The period of time that starts when a software product is conceived and ends when the
product is no longer available for use. The software life cycle typically includes a requirement
phase, design phase, implementation phase, test phase, installation and check out phase, op-
eration and maintenance phase, and sometimes retirement phase”.
A software life cycle model is a particular abstraction that represents a software life
cycle. A software life cycle model is often called a software development life cycle (SDLC).

2.1 SDLC MODELS

A variety of life cycle models have been proposed and are based on tasks involved in develop-
ing and maintaining software. Few well known life cycles models are discussed in this chapter.

2.1.1 Build and Fix Model

Sometimes a product is constructed without specifications or any attempt at design. Instead,
the developer simply builds a product that is reworked as many times as necessary to satisfy
the client [SCHA96].
This is an adhoc approach and not well defined. Basically, it is a simple two-phase model.
The first phase is to write code and the next phase is to fix it as shown in Fig. 2.1. Fixing in this
context may be error correction or addition of further functionality [TAKA96].

20
 Software Life Cycle Models
21

Build
Code

Fig. 2.1: Build and fix model.

Although this approach may work well on small programming exercises 100 or 200 lines
long, this model is totally unsatisfactory for software of any reasonable size. Code soon be-
comes unfixable and unenhanceable. There is no room for design or any aspect of development
process to be carried out in a structured or detailed way. The cost of the development using
this approach is actually very high as compared to the cost of a properly specified and carefully
designed product. In addition, maintenance of the product can be extremely difficult without
specification or design documents.

2.1.2 The Waterfall Model

The most familiar model is the waterfall model, which is given in Fig. 2.2. This model has five
phases: Requirements analysis and specification, design, implementation and unit testing,
integration and system testing, and operation and maintenance. The phases always occur in
this order and do not overlap. The developer must complete each phase before the next phase
begins. This model is named “Waterfall Model”, because its diagrammatic representation
resembles a cascade of waterfalls.
1. Requirement analysis and specification phase. The goal of this phase is to
understand the exact requirements of the customer and to document them properly. This activity
is usually executed together with the customer, as the goal is to document all functions,
performance and interfacing requirements for the software. The requirements describe the
“what” of a system, not the “how”. This phase produces a large document, written in a natural
language, contains a description of what the system will do without describing how it will be
done. The resultant document is known as software requirement specification (SRS) document.
The SRS document may act as contract between the developer and customer. If developer
fails to implement full set of requirements, it may amount to failure to implement the contracted
system.
 22 Software Engineering

Requirement Analysis
& Specification

Implementation &
Unit Testing

Integration & System

Testing

Operation &
Maintenance

Fig. 2.2: Waterfall model

2. Design phase. The SRS document is produced in the previous phase, which contains
the exact requirements of the customer. The goal of this phase is to transform the require-
ments specification into a structure that is suitable for implementation in some programming
language. Here, overall software architecture is defined, and the high level and detailed de-
sign work is performed. This work is documented and known as software design description
(SDD) document. The information contained in the SDD should be sufficient to begin the cod-
ing phase.
3. Implementation and unit testing phase. During this phase, design is implemented.
If the SDD is complete, the implementation or coding phase proceeds smoothly, because all the
information needed by the software developers is contained in the SDD.
During testing, the major activities are centered around the examination and modifica-
tion of the code. Initially, small modules are tested in isolation from the rest of the software
product. There are problems associated with testing a module in isolation. How do we run a
module without anything to call it, to be called by it or, possibly, to output intermediate values
obtained during execution? Such problems are solved in this phase and modules are tested
after writing some overhead code.
4. Integration and system testing phase. This is a very important phase. Effective
testing will contribute to the delivery of higher quality software products, more satisfied us-
ers, lower maintenance costs, and more accurate and reliable results. It is a very expensive
activity and consumes one-third to one half of the cost of a typical development project.
As we know, the purpose of unit testing is to determine that each independent module is
correctly implemented. This gives little chance to determine that the interface between mod-
ules is also correct, and for this reason integration testing is performed. System testing in-
volves the testing of the entire system, whereas software is a part of the system. This is essen-
tial to build confidence in the developers before software is delivered to the customer or re-
deased in the market.
5. Operation and maintenance phase. Software maintenance is a task that every
development group has to face, when the software is delivered to the customer’s site, installed
and is operational. Therefore, release of software inaugurates the operation and maintenance
phase of the life cycle. The time spent and effort required to keep the software operational
|Software Life Cycle Models
23|

after release is very significant. Despite the fact that it is a very important and challenging
task; it is routinely the poorly managed headache that nobody wants to face.
Software maintenance is a very broad activity that includes error correction, enhance-
ment of capabilities, deletion of obsolete capabilities, and optimization. The purpose of this
phase is to preserve the value of the software over time. This phase may span for 5 to 50 years
whereas development may be 1 to 3 years.
This model is easy to understand and reinforces the notion of “define before design” and
“design before code”. This model expects complete and accurate requirements early in the
process, which is unrealistic. Working software is not available until relatively late in the
process, thus delaying the discovery of serious errors. It also does not incorporate any kind of
risk assessment.

Problems of waterfall model

(v) It is difficult to define all requirements at the beginning of a project.

(it) This model is not suitable for accomodating any change.
(zit) A working version of the system is not seen until late in the project’s life.
(tv) It does not scale up well to large projects.
(v) Real projects are rarely sequential.
Due to these weaknesses, the application of waterfall model should be limited to situa-
tions where the requirements and their implementation are well understood. For example, if
an organisation has experience in developing accounting systems then building a new accounting
system based on existing designs could be easily managed with the waterfall model.

2.1.3 Prototyping Model

A disadvantage of waterfall model as discussed in the last section is that the working software
is not available until late in the process, thus delaying the discovery of serious errors. An
alternative to this is to first develop a working prototype of the software instead of developing
the actual software. The working prototype is developed as per current available requirements.
Basically, it has limited functional capabilities, low reliability, and untested performance (usu-
ally low).
The developers use this prototype to refine the requirements and prepare the final speci-
fication document. Because the working prototype has been evaluated by the customer, it is
reasonable to expect that the resulting specification document will be correct. When the proto-
type is created, it is reviewed by the customer. Typically this review gives feedback to the
developers that helps to remove uncertainties in the requirements of the software, and starts
an iteration of refinement in order to further clarify requirements as shown in Fig. 2.3.
The prototype may be a usable program, but is not suitable as the final software prod-
uct. The reason may be poor performance, maintainability or overall quality. The code for the
prototype is thrown away; however the experience gathered from developing the prototype
helps in developing the actual system. Therefore, the development of a prototype might in-
volve extra cost, but overall cost might turnout to be lower than that of an equivalent system
developed using the waterfall model.
 24 Software Engineering

Quick Design

Refinement of
Requirements as
per suggestions
Implement

Customer Evaluation
Not accepted by customer

Accepted by customer

Implementation and Unit Testing

Integration & System Testing

Operation & Maintenance

Fig. 2.3: Prototyping model

The developers should develop prototype as early as possible to speed up the software
development process. After all, the sole use of this is to determine the customer’s real needs.
Once this has been determined, the prototype is discarded. For this reason, the internal struc-
ture of the prototype is not very important [SCHA96].
After the finalization of software requirement and specification (SRS) document, the
prototype is discarded and actual system is then developed using the waterfall approach. Thus,
it is used as an input to waterfall model and produces maintainable and good quality software.
This model requires extensive participation and involvement of the customer, which is not
always possible.

2.1.4 Iterative Enhancement Model

This model has the same phases as the waterfall model, but with fewer restrictions. Generally
the phases occur in the same order as in the waterfall model, but these may be conducted in
several cycles. A useable product is released at the end of the each cycle, with each*release
providing additional functionality [BASI75].
During the first requirements analysis phase, customers and developers specify as many
requirements as possible and prepare a SRS document. Developers and customers then prioritize
|Software Life Cycle Models 2 |

these requirements. Developers implement the specified requirements in one or more cycles of
design, implementation and test based on the defined priorities. The model is given in Fig. 2.4.
The aim of the waterfall and prototyping models is the delivery of a complete, opera-
tional and good quality product. In contrast, this model does deliver an operational quality
product at each release, but one that satisfies only a subset of the customer’s requirements.
The complete product is divided into releases, and the developer delivers the product release
by release. A typical product will usually have many releases as shown in Fig. 2.4. At each
release, customer has an operational quality product that does a portion of what is required.
The customer is able to do some useful work after first release. With this model, first release
may be available within few weeks or months, whereas the customer generally waits months
or years to receive a product using the waterfall and prototyping model.

Implementation &|. lie oli Operation

Requirements De i : System P
Unit Testing : (Install)
: Testing

Release |

Implementation & Integration & Operation

Testing Unit So (Install)
Testing

Release II

Implementation & Integration &

a Testing Unit System pee
Testing (Install)

Release III

Fig. 2.4: Iterative enhancement model.

2.1.5 Evolutionary Development Model

Evolutionary development model resembles iterative enhancement model. The same phases
as defined for the waterfall model occur here in a cyclical fashion. This model differs from
iterative enhancement model in the sense that this does not require a useable product at the
end of each cycle. In evolutionary development, requirements are implemented by category
rather than by priority.
For example, in a simple database application, one cycle might implement the graphical
user interface (GUI); another file manipulation; another queries; and another updates. All
four cycles must complete before there is working product available. GUI allows the users to
interact with the system; file manipulation allows data to be saved and retrieved; queries
allow users to get data out of the system; and updates allow users to put data into the system.
With any one of those parts missing, the system would be unusable.
In contrast, an iterative enhancement model would start by developing a very simplis-
tic, but usable database. On the completion of each cycle, the system would become more
sophisticated. It, would, however, provide all the critical functionality by the end of the first
 26 Software Engineering

cycle. Evolutionary development and iterative enhancement are somewhat interchangeable.

Evolutionary development should be used when it is not necessary to provide a minimal ver-
sion of the system quickly.
This model is useful for projects using new technology that is not well understood. This
is also used for complex projects where all functionality must be delivered at one time, but the
requirements are unstable or not well understood at the beginning.

2.1.6 Spiral Model

The problem with traditional software process models is that they do not deal sufficiently with
the uncertainty, which is inherent to software projects. Important software projects have failed
because project risks were neglected and nobody was prepared when something unforeseen
happened. Barry Boehm recognized this and tried to incorporate the “project risk” factor into
a life cycle model. The result is the spiral model, which was presented in 1986 [BOEH86] and
is shown in Fig. 2.5.

Cumulative Cost

Progress i
through
steps

Evaluate alternatives;
identify, resolve risks
Determine
objectives, Risk analysis (RA)
alternatives,
constraints
Risk analysis
a

Risk analysis = -\___----7

Concept of Models
operation
Software
product
design
Requirements == £=f f---------
validation

Design validation
and verification
; Integration
1 ‘and test
Plan 1
Acceptance ;
next phases Implemen- i]

tation ;tes 1

H
1

Develop, verify
next-level product *

Fig. 2.5: Spiral model

The radial dimension of the model represents the cumulative costs. Each
path around
the spiral is indicative of increased costs. The afgular dimension represents
the progress made
_| Software Life Cycle Models 27

in completing each cycle. Each loop of the spiral from X-axis clockwise through 360° repre-
sents one phase. One phase is split roughly into four sectors of major activities:
Planning: Determination of objectives, alternatives and constraints
Risk Analysis: Analyze alternatives and attempts to identify and resolve the risks
involved
Development: Product development and testing product
e Assessment: Customer evaluation

During the first phase, planning is performed, risks are analyzed, prototypes are built,
and customers evaluate the prototype. During the second phase, a more refined prototype is
built, requirements are documented and validated, and customers are involved in assessing
the new prototype. By the time third phase begins, risks are known, and a somewhat more
traditional development approach is taken [RAKI97].
The focus is the identification of problems and the classification of these into different
levels of risks, the aim being to eliminate high-risk problems before they threaten the software
operation or cost.
An important feature of the spiral model is that each phase is completed with a review
by the people concerned with the project (designers and programmers). This review consists of
a review of all the products developed up to that point and includes the plans for the next cycle.
These plans may include a partition of the product in smaller portions for development or
components that are implemented by individual groups or persons. If the plan for the develop-
ment fails, then the spiral is terminated. Otherwise, it terminates with the initiation of new or
modified software.
The advantage of this model is the wide range of options to accommodate the good
features of other life cycle models. It becomes equivalent to another life cycle model in appro-
priate situations. It also incorporates software quality objectives into software development.
The risk analysis and validation steps eliminate errors in the early phases of development.
The spiral model has some difficulties that need to be resolved before it can be a univer-
sally applied life cycle model. These difficulties include lack of explicit process guidance in
determining objectives, constraints, alternatives; relying on risk assessment expertise; and
providing more flexibility than required for many applications.

2.1.7 The Rapid Application Development (RAD) Model

This model was proposed by IBM in the 1980s through the book of James Martin entitled
“Rapid Application Development”. Here, user involvement is essential from requirement phase
to delivery of the product. The continuous user participation ensures the involvement of user’s
expectations and perspective in requirements elicitation, analysis and design of the system.
The process is started with building a rapid prototype and is given to user for evalua-
tion. The user feedback is obtained and prototype is refined. The process continues, till the
requirements are finalised. We may use any grouping technique (like FAST, QFD, Brainstorm-
ing Sessions; for details refer chapter 3) for requirements elicitation. Software requirement
and specification (SRS) and design documents are prepared with the association of users.
 28 Software Engineering

There are four phases in this model and these are shown in Fig. 2.6.

With active participation of users

ee
Ee ES
peau Descton
Fig. 2.6: RAD Model
(i) Requirements planning phase. Requirements are captured using any group
elicitation technique. Some techniques are discussed in chapter 3. Only issue is the active
involvement of users for understanding the project.
(ii) User Description. Joint teams of developers and users are constituted to prepare,
understand and review the requirements. The team may use automated tools to capture
information from the other users.
(iii) Construction phase. This phase combines the detailed design, coding and testing
phase of waterfall model. Here, we release the product to customer. It is expected to use code
generators, screen generators and other types of productivity tools.
(iv) Cut over phase. This phase incorporates acceptance testing by the users, installation
of the system, and user training.
In this model, quick initial views about the product are possible due to delivery of rapid
prototype. The development time of the product may be reduced due to use of powerful devel-
opment tools. It may use CASE tools and frameworks to increase productivity. Involvement of
user may increase the acceptability of the product.
If user cannot be involved throughout the life cycle, this may not be an appropriate
model. Development time may not be reduced very significantly, if reusable components are
not available. Highly specialized and skilled developers are expected and such developers may
not be available very easily. It may not be effective, if system can not be properly modularised.

2.2 SELECTION OF A LIFE CYCLE MODEL

The selection of a suitable model is based on the following characteristics/categories:
(1) Requirements
(it) Development team
(iit) Users
(iv) Project type and associated risk.

2.2.1 Characteristics of Requirements

Requirements are very important for the selection of an appropriate model. There are number
of situations and problems during requirements capturing and analysis. The details are given
in Table 2.1.
 Software Life Cycle Models 29

Table 2.1: Selection of a model based on characteristics of requirements

Requirements Waterfall | Prototype Iterative Evolutionary | Spiral |RAD

enhancement| development

Are requirements easily Yes No No No No Yes

understandable and defined?

Do we change requirements No Yes No No Yes No

quite often?
Can we define requirements
early in the cycle?
=

Requirements are indicating

a complex system to be built

2.2.2 Status of Development Team

The status of development team in terms of availability, effectiveness, knowledge, intelligence,
team work etc., is very important for the success of the project. If we know above mentioned
parameters and characteristics of the team, then we may choose an appropriate life cycle
model for the project. Some of the details are given in Table 2.2.

Table 2.2: Selection based on status of development team

Development Waterfall | Prototype Iterative Evolutionary | Spiral |RAD

team enhancement} development

Less experience on similar No N

projects

=t
Less domain knowledge No es Ye
(new to the technology)

cad
Less experience on tools to es N
be used

Availability of training, No e
if required

2.2.3 Involvement of Users

Involvement of users increases the understandability of the project. Hence user participation,
if available, plays a very significant role in the selection of an appropriate life cycle model.
Some issues are discussed in Table 2.3.
 30 Software Engineering

Table 2.3: Selection based on user’s participation

Involvement Waterfall |Prototype Iterative Evolutionary | Spiral

of Users enhancement| development

User involvement in all Yes No No Yes

phases

es s

User have no previous Yes Yes Ye Yes No

experience of participation
in similar projects

Users are experts of Yes Ss

problem domain
aie eee

2.3.4 Type of Project and Associated Risk

Very few models incorporate risk assessment. Project type is also important for the selection of
a model. Some issues are discussed in Table 2.4.
Table 2.4: Selection based on type of project with associated risk

Project type Waterfall |Prototype Iterative Evolutionary | Spiral |RAD

and risk enhancement| development

Project is the enhancement No No Yes Ye s

of the existing system

Funding is stable for Yes Yes No No

the project
High reliability No No Yes Ye S
requirements
Tight project schedule
ame
Use of reusable components Ce)
Are resources (time, money )
people etc.) scarce?

An appropriate model may be selected based on options given in four Tables (i.e., Table
2.1 to 2.4). Firstly, we have to answer the questions presented for each category by circling a
yes or no in each table. Rank the importance of each category, or question within the category,
in terms of the project for which we want to select a model. The total number of circled re-
sponses for each column in the tables decide an appropriate model. We may also use the cat-
egory ranking to resolve the conflicts between models if the total in either case is close or the
same.
 Software Life Cycle Models 31

REFERENCES
[BASI75] Basili V.R., “Iterative Enhancement: A Practical Technique for Software Development”,
IEEE Trans on Software Engineering, SE—1, No. 4, 390-396, December 1975.
[BOEH86] Boehm B., “A Spiral Model for Software Development and Enhancement”, ACM Software
Engineering Notes, 14-24, August, 1986.
[RAKI97] Rakitin S.R., “Software Verification and Validation”, Artech House Inc., Norwood, MA,
1997.
[SCHA96] Schach S., “Classical and Object Oriented Software Engineering”, IRWIN, USA, 1996.
[TAKA96] Takang A.A. and P.A. Grubb, “Software Maintenance—Concepts and Practice”, Int.
Thomson Computer Press, Cambridge, U.K., 1996.

Note: Choose most appropriate answer of the following questions.

2.1. Spiral Model was developed by
(a) Bev Littlewood (6) Berry Boehm
(c) Roger Pressman (d) Victor Basili.
2.2. Which model is most popular for student’s small projects?
(a) Waterfall model (b) Spiral model
(c) Quick and fix model (d) Prototyping model.
2.3. Which is not a software life cycle model?
(a) Waterfall model (6) Spiral model
(c) Prototyping model (d) Capability maturity model.
2.4. Project risk factor is considered in
(a) Waterfall model (b) Prototyping model
(c) Spiral model (d) Iterative enhancement model.
2.5. SDLC stands for
(a) Software design life cycle (b) Software development life cycle
(c) System development life cycle (d) System design life cycle.
2.6. Build and fix model has
(a) 3 phases (6) 1 phase
(c) 2 phases (d) 4 phases.
2.7. SRS Stands for
(a) Software requirements specification (6b) Software requirements solutions
(c) System requirements specification (d) none of the above.

2.8. Waterfall model is not suitable for

(a) small projects (6b) accomodating change
(c) complex projects (d) none of the above.
2.9. RAD stands for
(a) Rapid application development (6) Relative application development
(c) Ready application development (d) Repeated application development.
 32 Software Engineering

2.10. RAD model was proposed by

(a) Lucent Technologies (6b) Motorola
(c) IBM (d) Microsoft.
If requirements are easily understandable and defined, which model is best suited?
(a) Waterfall model (b) Prototyping model
(c) Spiral model (d) None of the above.
2.12. If requirements are frequently changing, which model is to be selected
(a) Waterfall (b) Prototyping model
(c) RAD model (d) Iterative enhancement model.
2.13. If user participation is available, which model is to be chosen?
(a) Waterfall model (b) Iterative enhancement model
(c) Spiral model (d) RAD model.
2.14. If limited user participation is available, which model is to be selected?
(a) Waterfall model (6) Spiral model
(c) Iterative enhancement model (d) any of the above.
2.15. If project is the enhancement of existing system, which model is best suited?
(a) waterfall model (b) Prototyping model
(c) Iterative enhancement model (d) spiral model.
2.16. Which one is the most important feature of spiral model?
(a) Quality management (6) Risk management
(c) Performance management (d) Efficiency management.
2.17. Most suitable model for new technology that is not well understood is:
(a) Waterfall model (6) RAD model
(c) Iterative enhancement model (d) Evolutionary development model.
2.18. Statistically, the maximum percentage of errors belong to the following phase of SDLC
(a) Coding (b) Design
(c) Specifications (d) Installation and maintenance.
2.19. Which phase is not available in software life cycle?
(a) Coding (6) Testing
(c) Maintenance (d) Abstraction.
2.20. The development is supposed to proceed linearly through the phases in
(a) Spiral model (b) Waterfall model
(c) Prototyping model (ad) None of the above.

2.1. What do you understand by the term Software Development Life Cycle (SDLC)? Why is it
important to adhere to a life cycle model while developing a large software product?
2.2. What is software life cycle? Discuss the generic waterfall model.
2.3. List the advantages of using waterfall model instead of adhoc build and fix model.
2.4, Discuss the prototype model. What is the effect of designing a prototype on the overall cost of the
software project?
 Software Life Cycle Models | 33

2.5. What are the advantages of developing the prototype of a system?

2.6. Describe the type of situations where iterative enhancement model might lead to difficulties.
2.7. Compare iterative enhancement model and evolutionary development model.
2.8. Sketch a neat diagram of spiral model of software life cycle.
2.9. Compare the waterfall model and the spiral model of software development.
2.10. As we move outward along with process flow path of the spiral model, what can we say about the
software that is being developed or maintained?
2.11. How does “project risk” factor affect the spiral model of software development?
2.12. List the advantages and disadvantages of involving a software engineer throughout the software
development planning process.
2.13. Explain the spiral model of software development. What are the limitations of such a model?
2.14. Describe the rapid application development (RAD) model. Discuss each phase in detail.
2.15. What are the characteristics to be considered for the selection of a life cycle model?
2.16. What is the role of user participation in the selection of a life cycle model?
2.17. Why do we feel that characteristics of requirements play a very significant role in the selection of
a life cycle model?
2.18. Write short note on “status of development team” for the selection of a life cycle model.
2.19. Discuss the selection process parameters for a life cycle model.