******Created by ebook converter - www.ebook-converter.

com******

model, we discuss a few derivatives of this model. Subsequently we discuss

the spiral model that generalises various life cycle models. Finally, we discuss
a few recently proposed life cycle models that are categorized under the
umbrella term agile model. Of late, agile models are finding increasing
acceptance among developers and researchers.

The genesis of the agile model can be traced to the radical changes to the types of
project that are being undertaken at present, rather than to any radical innovations to
the life cycle models themselves. The projects have changed from large multi-year
product development projects to small services projects now
.

2.1 A FEW BASIC CONCEPTS

In this section, we present a few basic concepts concerning the life cycle
models.

Software life cycle

It is well known that all living organisms undergo a life cycle. For
example when a seed is planted, it germinates, grows into a full tree,
and finally dies. Based on this concept of a biological life cycle, the term
software life cycle has been defined to imply the different stages (or
phases) over which a software evolves from an initial customer request
for it, to a fully developed software, and finally to a stage where it is no
longer useful to any user, and then it is discarded.
As we have already pointed out, the life cycle of every software starts with
a request for it by one or more customers. At this stage, the customers are
usually not clear about all the features that would be needed, neither can
they completely describe the identified features in concrete terms, and can
only vaguely describe what is needed. This stage where the customer feels a
need for the software and forms rough ideas about the required features is
known as the inception stage. Starting with the inception stage, a software
evolves through a series of identifiable stages (also called phases) on account
of the development activities carried out by the developers, until it is fully
developed and is released to the customers.
Once installed and made available for use, the users start to use the
software. This signals the start of the operation (also called maintenance )
phase. As the users use the software, not only do they request for fixing any
failures that they might encounter, but they also continually suggest several
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

improvements and modifications to the software. Thus, the maintenance

phase usually involves continually making changes to the software to
accommodate the bug-fix and change requests from the user. The operation
phase is usually the longest of all phases and constitutes the useful life of a
software. Finally the software is retired, when the users do not find it any
longer useful due to reasons such as changed business scenario, availability
of a new software having improved features and working, changed computing
platforms, etc. This forms the essence of the life cycle of every software.
Based on this description, we can define the software life cycle as follows:

The life cycle of a software represents the series of identifiable stages through which
it evolves during its life time.

With this knowledge of a software life cycle, we discuss the concept of a

software life cycle model and explore why it is necessary to follow a life cycle
model in professional software development environments.

Software development life cycle (SDLC) model

In any systematic software development scenario, certain well-defined
activities need to be performed by the development team and possibly
by the customers as well, for the software to evolve from one stage in
its life cycle to the next. For example, for a software to evolve from the
requirements specification stage to the design stage, the developers
n e e d to elicit requirements from the customers, analyse those
requirements, and formally document the requirements in the form of
an SRS document.
A software development life cycle (SDLC) model (also called software life cycle
model and software development process model ) describes the different activities
that need to be carried out for the software to evolve in its life cycle.
Throughout our discussion, we shall use the terms software development life
cycle (SDLC) and software development proce s s interchangeably. However,
some authors distinguish an SDLC from a software development process. In
their usage, a software development process describes the life cycle activities
more precisely and elaborately, as compared to an SDLC. Also, a
development process may not only describe various activities that are carried
out over the life cycle, but also prescribe a specific methodologies to carry out
the activities, and also recommends the the specific documents and other
artifacts that should be produced at the end of each phase. In this sense, the
term SDLC can be considered to be a more generic term, as compared to the
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

development process and several development processes may fit the same
SDLC.
An SDLC is represented graphically by drawing various stages of the life
cycle and showing the transitions among the phases. This graphical model is
usually accompanied by a textual description of various activities that need to
be carried o ut during a phase before that phase can be considered to be
complete. In simple words, we can define an SDLC as follows:

An SDLC graphically depicts the different phases through which a software evolves. It
is usually accompanied by a textual description of the different activities that need to
be carried out during each phase.

Process versus methodology

Though the terms process a n d methodology are at time used
interchangeably, there is a subtle di fference between the two. First, the
term process has a broader scope and addresses either all the activities
taking place during software development, or certain coarse grained
activities such as design (e.g. design process), testing (test process),
etc. Further, a software process not only identifies the specific activities
that need to be carried out, but may also prescribe certain methodology
for carrying out each activity. For example, a design process may
recommend that in the design stage, the high-level design activity be
carried out using Hatley and Pirbhai’s structured analysis and design
methodology. A methodology, on the other hand, prescribes a set of
steps for carrying out a specific life cycle activity. It may also include
the rationale and philosophical assumptions behind the set of steps
through which the activity is accomplished.
A software development process has a much broader scope as compared to a
software development methodology. A process usually describes all the activities
starting from the inception of a software to its maintenance and retirement stages, or
at least a chunk of activities in the life cycle. It also recommends specific
methodologies for carrying out each activity. A methodology, in contrast, describes
the steps to carry out only a single or at best a few individual activities.

Why use a development process?

The primary advantage of using a development process is that it encourages
development of software in a systematic and disciplined manner. Adhering to
a process is especially important to the development of professional software
needing team effort. When software is developed by a team rather than by
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

an individual programmer, use of a life cycle model becomes indispensable

for successful completion of the project.
Software development organisations have realised that adherence to a suitable life
cycle model helps to produce good quality software and that helps minimise the
chances of time and cost overruns.
Suppose a single programmer is developing a small program. For example,
a student may be developing code for a class room assignment. The student
might succeed even when he does not strictly follow a specific development
process and adopts a build and fix style of development. However, it is a
different ball game when a professional software is being developed by a
team of programmers. Let us now understand the difficulties that may arise if
a team does not use any development process, and the team members are
given complete freedom to develop their assigned part of the software as per
their own discretion. Several types of problems may arise. We illustrate one
of the problems using an example. Suppose, a software development
problem has been divided into several parts and these parts are assigned to
the team members. From then on, suppose the team members are allowed
the freedom to develop the parts assigned to them in whatever way they like.
It is possible that one member might start writing the code for his part while
making assumptions about the input results required from the other parts,
another might decide to prepare the test documents first, and some other
developer might start to carry out the design for the part assigned to him. In
this case, severe problems can arise in interfacing the different parts and in
managing the overall development. Therefore, ad hoc development turns out
to be is a sure way to have a failed project. Believe it or not, this is exactly
what has caused many project failures in the past!
When a software is developed by a team, it is necessary to have a precise
understanding among the team members as to—when to do what. In the
absence of such an understanding, if each member at any time would do
whatever activity he feels like doing. This would be an open invitation to
developmental chaos and project failure. The use of a suitable life cycle
model is crucial to the successful completion of a team-based development
project. But, do we need an SDLC model for developing a small program. In
this context, we need to distinguish between programming-in-the-small and
programming-in-the-large.

Programming-in-the-small refers to development of a toy program by a single

programmer. Whereas programming-in-the-large refers to development of a
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

professional software through team effort. While development of a software of the

former type could succeed even while an individual programmer uses a build and fix
style of development, use of a suitable SDLC is essential for a professional software
development project involving team effort to succeed.

Why document a development process?

It is not enough for an organisation to just have a well-defined
development process, but t h e development process needs to be
properly documented. To understand the reason for this, let us consider
that a development organisation does not document its development
process. In this case, its developers develop o n l y an informal
understanding of the development process. An informal understanding
of the development process among the team members can create
several problems during development. We have identified a few
important problems that may crop up when a development process is
not adequately documented. Those problems are as follows:

A documented process model ensures that every activity in the life

cycle is accurately defined. Also, wherever necessary the
methodologies for carrying out the respective activities are described.
Without documentation, the activities and their ordering tend to be
loosely defined, leading to confusion and misinterpretation by different
teams in the organisation. For example, code reviews may informally
and inadequately be carried out since there is no documented
methodology as to how the code review should be done. Another
difficulty is that for loosely defined activities, the developers tend to
use their subjective judgments. As an example, unless it is explicitly
prescribed, the team members would subjectively decide as to whether
the test cases should be designed just after the requirements phase,
after the design phase, or after the coding phase. Also, they would
debate whether the test cases should be documented at all and the
rigour with it should be documented.
An undocumented process gives a clear indication to the members of
the development teams about the lack of seriousness on the part of
the management of the organisation about following the process.
Therefore, an undocumented process serves as a hint to the
developers to loosely follow the process. The symptoms of an
undocumented process are easily visible—designs are shabbily done,
reviews are not carried out rigorously, etc.
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

A project team might often have to tailor a standard process model for
use in a specific project. It is easier to tailor a documented process
model, when it is required to modify certain activities or phases of the
life cycle. For example, consider a project situation that requires the
testing activities to be outsourced to another organisation. In this case,
A documented process model would help to identify where exactly the
required tailoring should occur.
A documented process model, as we discuss later, is a mandatory
requirement of the modern quality assurance standards such as ISO
9000 and SEI CMM. This means that unless a software organisation has
a documented process, it would not qualify for accreditation with any
of the quality standards. In the absence of a quality certification for the
organisation, the customers would be suspicious of its capability of
developing quality software and the organisation might find it difficult
to win tenders for software development.

A documented development process forms a common understanding of the activities

to be carried out among the software developers and helps them to develop software
in a systematic and disciplined manner. A documented development process model,
besides preventing the misinterpretations that might occur when the development
process is not adequately documented, also helps to identify inconsistencies,
redundancies, and omissions in the development process.

Nowadays, good software development organisations normally document

their development process in the form of a booklet. T h e y expect the
developers recruited fresh to their organisation to first master their software
development process during a short induction training that they are made to
undergo.

Phase entry and exit criteria

A good SDLC besides clearly identifying the different phases in the life
cycle, should unambiguously define the entry and exit criteria for each
phase. The phase entry (or exit) criteria is usually expressed as a set of
conditions that needs to be be satisfied for the phase to start (or to
complete). As an example, the phase exit criteria for the software
requirements specification phase, can be that the software requirements
specification (SRS) document is ready, has been reviewed internally, and
also has been reviewed and approved by the customer. Only after these
criteria are satisfied, the next phase can start.
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

If the entry and exit criteria for various phases are not well-defined, then
that would leave enough scope for ambiguity in starting and ending various
phases, and cause lot of confusion among the developers. Sometimes they
might prematurely stop the activities in a phase, and some other times they
might continue working on a phase much after when the phase should have
been over. The decision regarding whether a phase is complete or not
becomes subjective and i t becomes difficult for the project manager to
accurately tell how much has the development progressed. When the phase
entry and exit criteria are not well-defined, the developers might close the
activities of a phase much before they are actually complete, giving a false
impression of rapid progress. In this case, it becomes very difficult for the
project manager to determine the exact status of development and track the
progress of the project. This usually leads to a problem that is usually
identified as the 99 per cent complete syndrome. This syndrome appears when
there the software project manager has no definite way of assessing the
progress of a project, the optimistic team members feel that their work is 99
per cent complete even when their work is far from completion—making all
projections made by the project manager about the project completion time
to be highly inaccurate.

2.2 WATERFALL MODEL AND ITS EXTENSIONS

The waterfall model and its derivatives were extremely popular in the
1970s and still are heavily being used across many development
projects. The waterfall model is possibly the most obvious and intuitive
way in which software can be developed through team effort. We can
think of the waterfall model as a generic model that has been extended
in many ways for catering to certain specific software development
situations to realise all other software life cycle models. For this reason,
after discussing the classical and iterative waterfall models, we discuss
its various extensions.
2.2.1 Classical Waterfall Model
Classical waterfall model is intuitively the most obvious way to develop
software. It is simple but idealistic. In fact, it is hard to put this model
into use in any non-trivial software development project. One might
wonder if this model is hard to use in practical development projects,
then why study it at all? The reason is that all other life cycle models
can be thought of as being extensions of the classical waterfall model.
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

Therefore, it makes sense to first understand the classical waterfall

model, in order to be able to develop a proper understanding of other
life cycle models. Besides, we shall see later in this text that this model
though not used for software development; is implicitly used while
documenting software.
The classical waterfall model divides the life cycle into a set of phases as
shown in Figure 2.1. It can be easily observed from this figure that the
diagrammatic representation of the classical waterfall model resembles a
multi-level waterfall. This resemblance justifies the name of the model.

Figure 2.1: Classical waterfall model.

Phases of the classical waterfall model

The different phases of the classical waterfall model have been shown in
Figure 2.1. As shown in Figure 2.1, the different phases are—feasibility
study, requirements analysis and specification, design, coding and unit
testing, integration and system testing, and maintenance. The phases
starting from the feasibility study to the integration and system testing
phase are known as the development phases. A software is developed
during the development phases, and at the completion of the
development phases, the software is delivered to the customer. After
the delivery of software, customers start to use the software signalling
the commencement of the operation phase. As the customers start to
use the software, changes to it become necessary on account of bug
fixes and feature extensions, causing maintenance works to be
undertaken. Therefore, the last phase is also known as the maintenance
phase of the life cycle. It needs to be kept in mind that some of the text
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

books have different number and names of the phases.

An activity that spans all phases of software development is project
management. Since it spans the entire project duration, no specific phase is
named after it. Project management, nevertheless, is an important activity in
the life cycle and deals with managing t h e software development and
maintenance activities.
In the waterfall model, different life cycle phases typically require relatively
different amounts of efforts to be put in by the development team. The
relative amounts of effort spent on different phases for a typical software has
been shown in Figure 2.2. Observe from Figure 2.2 that among all the life
cycle phases, the maintenance phase normally requires the maximum effort.
On the average, about 60 per cent of the total effort put in by the
development team in the entire life cycle is spent on the maintenance
activities alone.

Figure 2.2: Relative effort distribution among different phases of a typical product.

However, among the development phases, the integration and system

testing phase requires the maximum effort in a typical development project.
In the following subsection, we briefly describe the activities that are carried
out in the different phases of the classical waterfall model.

Feasibility study
The main focus of the feasibility study stage is to determine whether it
would be financially and technically feasible to develop the software. The
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

feasibility study involves carrying out several activities such as

collection of basic information relating to the software such as the
different data items that would be input to the system, the processing
required to be carried out on these data, the output data required to be
produced by the system, as well as various constraints on the
development. These collected data are analysed to perform at the
following:
Development of an overall understanding of the problem: It is
necessary to first develop an overall understanding of what the customer
requires to be developed. For this, only the the important requirements of the
customer need to be understood and the details of various requirements such
as the screen layouts required in the graphical user interface (GUI), specific
formulas or algorithms required for producing the required results, and the
databases schema to be used are ignored.
Formulation of the various possible strategies for solving the
problem: In this activity, various possible high-level solution schemes to the
problem are determined. For example, solution in a client-server framework
and a standalone application framework may be explored.
Evaluation of the different solution strategies: The different identified
solution schemes are analysed to evaluate their benefits and shortcomings.
Such evaluation often requires making approximate estimates of the
resources required, cost of development, and development time required.
The different solutions are compared based on the estimations that have
been worked out. Once the best solution is identified, all activities in the later
phases are carried out as per this solution. At this stage, it may also be
determined that none of the solutions is feasible due to high cost, resource
constraints, or some technical reasons. This scenario would, of course,
require the project to be abandoned.
We can summarise the outcome of the feasibility study phase by noting
that other than deciding whether to take up a project or not, at this stage
very high-level decisions regarding the solution strategy is defined. Therefore,
feasibility study is a very crucial stage in software development. The
following is a case study of the feasibility study undertaken by an
organisation. It is intended to give a feel of the activities and issues involved
in the feasibility study phase of a typical software project.
Case study 2.1

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

A mining company named Galaxy Mining Company Ltd. (GMC Ltd.) has mines located
at various places in India. It has about fifty different mine sites spread across eight
states. The company employs a large number of miners at each mine site. Mining
being a risky profession, the company intends to operate a special provident fund,
which would exist in addition to the standard provident fund that the miners already
enjoy. The main objective of having the special provident fund (SPF) would be to
quickly distribute some compensation before the PF amount is paid.
According to this scheme, each mine site would deduct SPF installments from each
miner every month and deposit the same to the central special provident fund
commissioner (CSPFC). The CSPFC will maintain all details regarding the SPF
installments collected from the miners.
GMC Ltd. requested a reputed software vendor Adventure Software Inc. to undertake
the task of developing the software for automating the maintenance of SPF records
of all employees. GMC Ltd. has realised that besides saving manpower on book-
keeping work, the software would help in speedy settlement of claim cases. GMC Ltd.
indicated that the amount it can at best afford Rs. 1 million for this software to be
developed and installed.
Adventure Software Inc. deputed their project manager to carry out the feasibility
study. The project manager discussed with the top managers of GMC Ltd. to get an
overview of the project. He also discussed with the field PF officers at various mine
sites to determine the exact details of the project. The project manager identified two
broad approaches to solve the problem. One is to have a central database which
would be accessed and updated via a satellite connection to various mine sites. The
other approach is to have local databases at each mine site and to update the central
database periodically through a dial-up connection. This periodic updates can be done
on a daily or hourly basis depending on the delay acceptable to GMC Ltd. in invoking
various functions of the software. H e found that the second approach is very
affordable and more fault-tolerant as the local mine sites can operate even when the
communication link temporarily fails. In this approach, when a link fails, only the
update of the central database gets delayed. Whereas in the first approach, all SPF
work gets stalled at a mine site for the entire duration of link failure. The project
manager quickly analysed t h e overall database functionalities required, the user-
interface issues, and the software handling communication with the mine sites. From
this analysis, he estimated the approximate cost to develop the software. He found
that a solution involving maintaining local databases at the mine sites and periodically
updating a central database is financially and technically feasible. The project
manager discussed this solution with the president of GMC Ltd., who indicated that
the proposed solution would be acceptable to them.

Requirements analysis and specification

The aim of the requirements analysis and specification phase is to
understand the exact requirements of the customer and to document
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

them properly. This phase consists of two distinct activities, namely

requirements gathering and analysis, and requirements specification. In
the following subsections, we give an overview of these two activities:

Requirements gathering and analysis: The goal of the

requirements gathering activity is to collect all relevant information
regarding the software to be developed from the customer with a view
to clearly understand the requirements. For this, first requirements are
gathered from the customer and then the gathered requirements are
analysed. The goal of the requirements analysis activity is to weed out
the incompleteness and inconsistencies in these gathered
requirements. Note that a n inconsistent requirement is one in which
some part of the requirement contradicts with some other part. On the
other hand, a n incomplete requirement is one in which some parts of
the actual requirements have been omitted.
Requirements specification: After the requirement gathering and
analysis activities are complete, the identified requirements are
documented. This is called a software requirements specification (SRS)
document. The SRS document is written using end-user terminology.
This makes the SRS document understandable to the customer.
Therefore, understandability of the SRS document is an important
issue. The SRS document normally serves as a contract between the
development team and the customer. Any future dispute between the
customer and the developers can be settled by examining the SRS
document. The SRS document is therefore an important document
which must be thoroughly understood by the development team, and
reviewed jointly with the customer. The SRS document not only forms
the basis for carrying out all the development activities, but several
documents such as users’ manuals, system test plan, etc. are prepared
directly based on it. In Chapter 4, we examine the requirements
analysis activity and various issues involved in developing a good SRS
document in more detail.

Design
The goal of the design phase is to transform the requirements specified
in the SRS document into a structure that is suitable for implementation
in some programming language. In technical terms, during the design
phase the software architecture is derived from the SRS document. Two
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

distinctly different design approaches are popularly being used at

present—the procedural and object-oriented design approaches. In the
following, we briefly discuss the essence of these two approaches.
These two approaches are discussed in detail in Chapters 6, 7, and 8.

Procedural design approach: The traditional design approach is in

use in many software development projects at the present time. This
traditional design technique is based on the data flow-oriented design
approach. It consists of two important activities; first structured analysis
of the requirements specification is carried out where the detailed
structure of the problem is examined. This is followed by a structured
design step where the results of structured analysis are transformed
into the software design.

During structured analysis, the functional requirements specified in the

SRS document are decomposed into subfunctions and the data-flow among
these subfunctions is analysed and represented diagrammatically in the
form of DFDs. The DFD technique is discussed in Chapter 6. Structured
design is undertaken once the structured analysis activity is complete.
Structured design consists of two main activities—architectural design (also
called high-level design ) and detailed design (also called Low-level design ).
High-level design involves decomposing the system i n t o modules, and
representing the interfaces and the invocation relationships among the
modules. A high-level software design is some times referred to as the
software architecture. During the detailed design activity, internals of the
individual modules such as the data structures and algorithms of the
modules are designed and documented.

Object-oriented design approach: In this technique, various

objects that occur in the problem domain and the solution domain are
first identified and the different relationships that exist among these
objects are identified. The object structure is further refined to obtain
the detailed design. T he OOD approach is credited to have several
benefits such as lower development time and effort, and better
maintainability of the software. The object-oriented design technique is
discussed in Chapters 7 and 8.

Coding and unit testing

******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

The purpose of the coding and unit testing phase is to translate a

software design into source code and to ensure that individually each
function is working correctly. The coding phase is also sometimes called
t h e implementation phase, since the design is implemented into a
workable solution in this phase. Each component of the design is
implemented as a program module. The end-product of this phase is a
set of program modules that have been individually unit tested. The
main objective of unit testing is to determine the correct working of the
individual modules. The specific activities carried out during unit testing
include designing test cases, testing, debugging to fix problems, and
management of test cases. We shall discuss the coding and unit testing
techniques in Chapter 10.

Integration and system testing

Integration of different modules is undertaken soon after they have been
coded and unit tested. During the integration and system testing phase, the
different modules are integrated in a planned manner. Various modules
making up a software are almost never integrated in one shot (can you guess
the reason for this?). Integration of various modules are normally carried out
incrementally over a number of steps. During each integration step,
previously planned modules are added to the partially integrated system and
the resultant system is tested. Finally, after all the modules have been
successfully integrated and tested, the full working system is obtained.
System testing is carried out on this fully working system.

Integration testing is carried out to verify that the interfaces among different units are
working satisfactorily. On the other hand, the goal of system testing is to ensure that
the developed system conforms to the requirements that have been laid out in the
SRS document.

System testing usually consists of three different kinds of testing activities:

-testing: testing is the system testing performed by the development

team.
-testing: This is the system testing performed by a friendly set of
customers.
Acceptance testing: After the software has been delivered, the
customer performs system testing to determine whether t o accept the
delivered software or to reject it.
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

We discuss various integration and system testing techniques in more detail

in Chapter 10.

Maintenance
The total effort spent on maintenance of a typical software during its
operation phase is much more than that required for developing the
software itself. Many studies carried out in the past confirm this and
indicate that the ratio of relative effort of developing a typical software
product and the total effort spent on its maintenance is roughly 40:60.
Maintenance is required in the following three types of situations:

Corrective maintenance: This type of maintenance is carried out to

correct errors that were not discovered during the product
development phase.
Perfective maintenance: This type of maintenance is carried out to
improve the performance of the system, or to enhance the
functionalities of the system based on customer’s requests.
Adaptive maintenance: Adaptive maintenance is usually required for
porting the software to work in a new environment. For example,
porting may be required to get the software to work on a new
computer platform or with a new operating system.

Various maintenance activities have been discussed in more detail in

Chapter 13.

Shortcomings of the classical waterfall model

The classical waterfall model is a very simple and intuitive model.
However, it suffers from several shortcomings. Let us identify some of
the important shortcomings of the classical waterfall model:
No feedback paths: In classical waterfall model, the evolution of a software
from one phase to the next is analogous to a waterfall. Just as water in a
waterfall after having flowed down cannot flow back, once a phase is
complete, the activities carried out in it and any artifacts produced in this
phase are considered to be final and are closed for any rework. This requires
that all activities during a phase are flawlessly carried out.
The classical waterfall model is idealistic in the sense that it assumes that
no error is ever committed by the developers during any of the life cycle
phases, and therefore, incorporates no mechanism for error correction.
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

Contrary to a fundamental assumption made by the classical waterfall

model, in practical development environments, the developers do commit a
large number of errors in almost every activity they carry out during various
phases of the life cycle. After all, programmers are humans and as the old
adage says to err is humane. The cause for errors can be many—oversight,
wrong interpretations, use of incorrect solution scheme, communication gap,
etc. These defects usually get detected much later in the life cycle. For
example, a design defect might go unnoticed till the coding or testing phase.
Once a defect is detected at a later time, the developers need to redo some
of the work done during that phase and also redo the work of later phases
that are affected by the rework. Therefore, in any non-trivial software
development project, it becomes nearly impossible to strictly follow the
classical waterfall model of software development.
Difficult to accommodate change requests: This model assumes that all
customer requirements can be completely and correctly defined at the
beginning of the project. There is much emphasis on creating an
unambiguous and complete set of requirements. But, it is hard to achieve this
even in ideal project scenarios. The customers’ requirements usually keep on
changing with time. But, in this model it becomes difficult to accommodate
any requirement change requests made by the customer after the
requirements specification phase is complete, and this often becomes a
source of customer discontent.
Inefficient error corrections: This model defers integration of code and
testing tasks until it is very late when the problems are harder to resolve.
No overlapping of phases: This model recommends that the phases be
carried out sequentially—new phase can start only after the previous one
completes. However, it is rarely possible to adhere to this recommendation
and it leads to a large number of team members to idle for extended periods.
Fo r example, for efficient utilisation of manpower, the testing team might
need to design the system test cases immediately after requirements
specification is complete. (We shall discuss in Chapter 10 that the system test
cases are designed solely based on the SRS document). In this case, the
activities of the design and testing phases overlap. Consequently, it is safe to
say that in a practical software development scenario, rather than having a
precise point in time at which a phase transition occurs, the different phases
need to overlap for cost and efficiency reasons.

Is the classical waterfall model useful at all?

******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

We have already pointed out that it is hard to use the classical waterfall
model in real projects. In any practical development environment, as the
software takes shape, several iterations through the different waterfall stages
become necessary for correction of errors committed during various phases.
Therefore, the classical waterfall model is hardly usable for software
development. But, as suggested by Parnas [1972] the final documents for the
product should be written as if the product was developed using a pure
classical waterfall.

Irrespective of the life cycle model that is actually followed for a product
development, the final documents are always written to reflect a classical waterfall
model of development, so that comprehension of the documents becomes easier for
any one reading the document.

The rationale behind preparation of documents based on the classical

waterfall model can be explained using Hoare’s metaphor of mathematical
theorem [1994] proving—A mathematician presents a proof as a single chain
of deductions, even though the proof might have come from a convoluted set
of partial attempts, blind alleys and backtracks. Imagine how difficult it would
be to understand, if a mathematician presents a proof by retaining all the
backtracking, mistake corrections, and solution refinements he made while
working out the proof.
2.2.2 Iterative Waterfall Model
We had pointed out in the previous section that in a practical software
development project, the classical waterfall model is hard to use. We had
branded the classical waterfall model as an idealistic model. In this context,
the iterative waterfall model can be thought of as incorporating the necessary
changes to the classical waterfall model to make it usable in practical
software development projects.

The main change brought about by the iterative waterfall model to the classical
waterfall model is in the form of providing feedback paths from every phase to its
preceding phases.

The feedback paths introduced by the iterative waterfall model are shown
in Figure 2.3. The feedback paths allow for correcting errors committed by a
programmer during some phase, as and when these are detected in a later
phase. For example, if during the testing phase a design error is identified,
then the feedback path allows the design to be reworked and the changes to
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

b e reflected in the design documents and all other subsequent documents.

Please notice that in Figure 2.3 there is no feedback path to the feasibility
stage. This is because once a team having accepted to take up a project,
does not give up the project easily due to legal and moral reasons.

Figure 2.3: Iterative waterfall model.

Almost every life cycle model that we discuss are iterative in nature, except
the classical waterfall model and the V-model—which are sequential in
nature. In a sequential model, once a phase is complete, no work product of
that phase are changed later.

Phase containment of errors

No matter how careful a programmer may be, he might end up committing
some mistake or other while carrying out a life cycle activity. These mistakes
result in errors (also called faults o r bugs ) in the work product. It is
advantageous to detect these errors in the same phase in which they take
place, since early detection of bugs reduces the effort and time required for
correcting those. For example, if a design problem i s detected in the design
phase itself, then the problem can be taken care of much more easily than if
the error is identified, say, at the end of the testing phase. In the later case,
it would be necessary not only to rework the design, but also to appropriately
redo the relevant coding as well as the testing activities, thereby incurring
higher cost. It may not always be possible to detect all the errors in the same
phase in which they are made. Nevertheless, the errors should be detected as

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

early as possible.

The principle of detecting errors as close to their points of commitment as possible is

known as phase containment of errors.

For achieving phase containment of errors, how can the developers detect
almost all error that they commit in the same phase? After all, the end
product of many phases are text or graphical documents, e.g. SRS document,
design document, test plan document, etc. A popular technique is to
rigorously review the documents produced at the end of a phase.

Phase overlap
Even though the strict waterfall model envisages sharp transitions to
occur from one phase to the next (see Figure 2.3), in practice the
activities of different phases overlap (as shown in Figure 2.4) due to
two main reasons:

In spite of the best effort to detect errors in the same phase in which
they are committed, some errors escape detection and are detected in
a later phase. These subsequently detected errors cause the activities
of some already completed phases to be reworked. If we consider such
rework after a phase is complete, we can say that the activities
pertaining to a phase do not end at the completion of the phase, but
overlap with other phases as shown in Figure 2.4.
An important reason for phase overlap is that usually the work required
to be carried out in a phase is divided among the team members.
Some members may complete their part of the work earlier than other
members. If strict phase transitions are maintained, then the team
members who complete their work early would idle waiting for the
phase to be complete, and are said to be in a blocking state. Thus the
developers who complete early would idle while waiting for their team
mates to complete their assigned work. Clearly this is a cause for
wastage of resources and a source of cost escalation and inefficiency.
As a result, in real projects, the phases are allowed to overlap. That is,
once a developer completes his work assignment for a phase, proceeds
to start the work for the next phase, without waiting for all his team
members to complete their respective work allocations.

Considering these situations, the effort distribution for different phases with
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

time would be as shown in Figure 2.4.

Figure 2.4: Distribution of effort for various phases in the iterative waterfall model.

Shortcomings of the iterative waterfall model

The iterative waterfall model is a simple and intuitive software
development model. It was used satisfactorily during 1970s and 1980s.
However, the characteristics of software development projects have
changed drastically over years. In the 1970s and 1960s, software
development projects spanned several years and mostly involved
generic software product development. The projects are now shorter,
and involve Customised software development. Further, software was
earlier developed from scratch. Now the emphasis is on as much reuse
of code and other project artifacts as possible. Waterfall-based models
have worked satisfactorily over last many years in the past. The
situation has changed substantially now. As pointed out in the first
chapter several decades back, every software was developed from
scratch. Now, not only software has become very large and complex,
very few (if at all any) software project is being developed from scratch.
The software services (customised software) are poised to become the
dominant types of projects. In the present software development
projects, use of waterfall model causes several problems. In this
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

context, the agile models have been proposed about a decade back
that attempt to overcome the important shortcomings of the waterfall
model by suggesting certain radical modification to the waterfall style of
software development. In Section 2.4, we discuss the agile model.
Some of the glaring shortcomings of the waterfall model when used in
the present-day software development projects are as following:
Difficult to accommodate change requests: A major problem with the
waterfall model is that the requirements need to be frozen before the
development starts. Based on the frozen requirements, detailed plans are
made for the activities to be carried out during the design, coding, and
testing phases. Since activities are planned for the entire duration,
substantial effort and resources are invested in the activities as developing
the complete requirements specification, design for the complete functionality
and so on. Therefore, accommodating even small change requests after the
development activities are underway not only requires overhauling the plan,
but also the artifacts that have already been developed.

Once requirements have been frozen, the waterfall model provides no scope for any
modifications to the requirements.

While the waterfall model is inflexible to later changes to the requirements,

evidence gathered from several projects points to the fact that later changes
to requirements are almost inevitable. Even f o r projects with highly
experienced professionals at all levels, as well as computer savvy customers,
requirements are often missed as well as misinterpreted. Unless change
requests are encouraged, the developed functionalities would be misfit to the
true customer requirements. Requirement changes can arise due to a variety
of reasons including the following—requirements were not clear to the
customer, requirements were misunderstood, business process o f the
customer may have changed after the SRS document was signed off, etc. In
fact, customers get clearer understanding of their requirements only after
working on a fully developed and installed system.
The basic assumption made in the iterative waterfall model that methodical
requirements gathering and analysis alone would comprehensively and
correctly identify all the requirements by the end of the requirements phase is
flawed.
Incremental delivery not supported: In the iterative waterfall model, the
full software is completely developed and tested before it is delivered to the
customer. There is no provision for any intermediate deliveries to occur. This
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

is problematic because the complete application may take several months or

years to be completed and delivered to the customer. By the time the
software is delivered, installed, and becomes ready for use, the customer’s
business process might have changed substantially. This makes the
developed application a poor fit to the customer’s requirements.
Phase overlap not supported: For most real life projects, i t becomes
difficult to follow the rigid phase sequence prescribed by the waterfall model.
By the term a rigid phase sequence, we mean that a phase can start only after
the previous phase is complete in all respects. As already discussed, strict
adherence to the waterfall model creates blocking states. The waterfall model
is usually adapted for use in real-life projects by allowing overlapping of
various phases as shown in Figure 2.4.
Error correction unduly expensive: In waterfall model, validation is
delayed till the complete development of the software. As a result, the
defects that are noticed at the time of validation incur expensive rework and
result in cost escalation and delayed delivery.
Limited customer interactions: This model supports very limited customer
interactions. It is generally accepted that software developed in isolation
from the customer is the cause of many problems. In fact, interactions occur
only at the start of the project and at project completion. As a result, the
developed software usually turns out to be a misfit to the customer’s actual
requirements.
Heavy weight: The waterfall model overemphasises documentation. A
significant portion of the time of the developers is spent in preparing
documents, and revising them as changes occur over the life cycle. Heavy
documentation though useful during maintenance and for carrying out review,
is a source of team inefficiency.
No support for risk handling and code reuse: It becomes difficult to use
the waterfall model in projects that are susceptible to various types of risks,
or those involving significant reuse of existing development artifacts. Please
recollect that software services types of projects usually involve significant
reuse.
2.2.3 V-Model
A popular development process model, V-model is a variant of the waterfall
model. As is the case with the waterfall model, this model gets its name from
its visual appearance (see Figure 2.5). In this model verification and
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

validation activities are carried out throughout the development life cycle,
and therefore the chances bugs in the work products considerably reduce.
This model is therefore generally considered to be suitable for use in projects
concerned with development of safety-critical software that are required to
have high reliability.

Figure 2.5: V-model.

As shown in Figure 2.5, there are two main phases—development and

validation phases. The left half of the model comprises the development
phases and the right half comprises the validation phases.

In each development phase, along with the development of a work

product, test case design and the plan for testing the work product are
carried out, whereas the actual testing is carried out in the validation
phase. This validation plan created during the development phases is
carried out in the corresponding validation phase which have been
shown by dotted arcs in Figure 2.5.
In the validation phase, testing is carried out in three steps—unit,
integration, and system testing. The purpose of these three different
steps of testing during the validation phase is to detect defects that
arise in the corresponding phases of software development—

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

requirements analysis and specification, design, and coding

respectively.

V-model versus waterfall model

We have already pointed out that the V-model can be considered to be
an extension of the waterfall model. However, there are major
differences between the two. As already mentioned, in contrast to the
iterative waterfall model where testing activities are confined to the
testing phase only, in the V-model testing activities are spread over the
entire life cycle. As shown in Figure 2.5, during the requirements
specification phase, the system test suite design activity takes place.
During the design phase, the integration test cases are designed.
During coding, the unit test cases are designed. Thus, we can say that
in this model, development and validation activities proceed hand in
hand.

Advantages of V-model
The important advantages of the V-model over the iterative waterfall
model are as following:

In the V-model, much o f the testing activities (test case design, test
planning, etc.) are carried out in parallel with the development
activities. Therefore, before testing phase starts significant part of the
testing activities, including test case design and test planning, is
already complete. Therefore, this model usually leads to a shorter
testing phase and an overall faster product development as compared
to the iterative model.
Since test cases are designed when the schedule pressure has not built
up, the quality of the test cases are usually better.
The test team is reasonably kept occupied throughout the
development cycle in contrast to the waterfall model where the testers
are active only during the testing phase. This leads to more efficient
manpower utilisation.
In the V-model, the test team is associated with the project from the
beginning. Therefore they build up a good understanding of the
development artifacts, and this in turn, helps them to carry out
effective testing of the software. In contrast, in the waterfall model
often the test team comes on board late in the development cycle,
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

since no testing activities are carried out before the start of the
implementation and testing phase.

Disadvantages of V-model
Being a derivative of the classical waterfall model, this model inherits
most of the weaknesses of the waterfall model.
2.2.4 Prototyping Model
The prototype model is also a popular life cycle model. The prototyping
model can be considered to be an extension of the waterfall model.
This model suggests building a working prototype of the system, before
development of the actual software. A prototype is a toy and crude
implementation of a system. It has limited functional capabilities, low
reliability, o r inefficient performance as compared to the actual
software. A prototype can be built very quickly by using several
shortcuts. The shortcuts usually involve developing inefficient,
inaccurate, or dummy functions. The shortcut implementation of a
function, for example, may produce the desired results by using a table
look-up rather than by performing the actual computations. Normally
the term rapid prototyping is used when software tools are used for
prototype construction. For example, tools based on fourth generation
languages (4GL) may be used to construct the prototype for the GUI
parts.
Necessity of the prototyping model
The prototyping model is advantageous to use for specific types of
projects. In the following, we identify three types of projects for which
the prototyping model can be followed to advantage:

It is advantageous to use the prototyping model for development of

the graphical user interface (GUI) part of an application. Through the
use of a prototype, it becomes easier to illustrate the input data
formats, messages, reports, and the interactive dialogs to the
customer. This is a valuable mechanism for gaining better
understanding of the customers’ needs. In this regard, the prototype
model turns out to be especially useful in developing the graphical user
interface (GUI) part of a system. For the user, it becomes much easier

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

to form an opinion regarding what would be more suitable by

experimenting with a working user interface, rather than trying to
imagine the working of a hypothetical user interface.

The GUI part of a software system is almost always developed using the prototyping
model.

The prototyping model is especially useful when the exact technical

solutions are unclear to the development team. A prototype can help
them to critically examine the technical issues associated with product
development. For example, consider a situation where the
development team has to write a command language interpreter as
part of a graphical user interface development. Suppose none of the
team members has ever written a compiler before. Then, this lack of
familiarity with a required development technology is a technical risk.
This risk can be resolved by developing a prototype compiler for a very
small language to understand the issues associated with writing a
compiler for a command language. Once they feel confident in writing
compiler for the small language, they can use this knowledge to
develop the compiler for the command language. Often, major design
decisions depend on issues such as the response time of a hardware
controller, or the efficiency of a sorting algorithm, etc. In such
circumstances, a prototype is often the best way to resolve the
technical issues.
An important reason for developing a prototype is that it is impossible
to “get it right” the first time. As advocated by Brooks [1975], one
must plan to throw away the software in order to develop a good
software later. Thus, the prototyping model can be deployed when
development of highly optimised and efficient software is required.

From the above discussions, we can conclude the following:

The prototyping model is considered to be useful for the development of not only the
GUI parts of a software, but also for a software project for which certain technical
issues are not clear to the development team.

Life cycle activities of prototyping model

The prototyping model of software development is graphically shown in

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

Figure 2.6. As shown in Figure 2.6, software is developed through two

major activities—prototype construction and iterative waterfall-based
software development.
Prototype development: Prototype development starts with an initial
requirements gathering phase. A quick design is carried out and a prototype
is built. The developed prototype is submitted to the customer for evaluation.
Based on the customer feedback, the requirements are refined and the
prototype is suitably modified. This cycle of obtaining customer feedback and
modifying the prototype continues till the customer approves the prototype.
Iterative development: Once the customer approves the prototype, the
actual software is developed using the iterative waterfall approach. In spite
of the availability of a working prototype, the SRS document is usually
needed to be developed since the SRS document is invaluable for carrying out
traceability analysis, verification, and test case design during later phases.
However, for GUI parts, the requirements analysis and specification phase
becomes redundant since the working prototype that has been approved by
the customer serves as an animated requirements specification.
T h e code for the prototype is usually thrown away. However, the
experience gathered from developing the prototype helps a great deal in
developing the actual system.

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

Figure 2.6: Prototyping model of software development.

Even though the construction o f a throwaway prototype might involve incurring

additional cost, for systems with unclear customer requirements and for systems with
unresolved technical issues, the overall development cost usually turns out to be
lower compared to an equivalent system developed using the iterative waterfall
model.

By constructing the prototype and submitting it for user evaluation, many

customer requirements get properly defined and technical issues get resolved
by experimenting with the prototype. This minimises later change requests
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

from the customer and the associated redesign costs.

Strengths of the prototyping model

This model is the most appropriate for projects that suffer from technical
and requirements risks. A constructed prototype helps overcome these
risks.

Weaknesses of the prototyping model

The prototype model can increase the cost of development for projects
that are routine development work and do not suffer from any
significant risks. Even when a project is susceptible to risks, the
prototyping model is effective only for those projects for which the risks
can be identified upfront before the development starts. Since the
prototype is constructed only at the start of the project, the prototyping
model is ineffective for risks identified later during the development
cycle. The prototyping model would not be appropriate for projects for
which the risks can only be identified after the development is
underway.
2.2.5 Incremental Development Model
This life cycle model is sometimes referred to as the successive versions model
and sometimes as the incremental model. In this life cycle model, first a
simple working system implementing only a few basic features is built and
delivered to the customer. Over many successive iterations successive
versions are implemented and delivered to the customer until the desired
system is realised. The incremental development model has been shown in
Figure 2.7.

Figure 2.7: Incremental software development.

Life cycle activities of incremental development model

******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

In the incremental life cycle model, the requirements of the software are
first broken down into several modules or features that can be
incrementally constructed and delivered. This has been pictorially
depicted i n Figure 2.7. At any time, plan is made only for the next
increment and no long-term plans a r e made. Therefore, it becomes
easier to accommodate change requests from the customers.
The development team first undertakes to develop the core features of the
system. The core or basic features are those that do not need to invoke any
services from the other features. On the other hand, non-core features need
services from the core features. Once the initial core features are developed,
these are refined into increasing levels of capability by adding new
functionalities in successive versions. Each incremental version is usually
developed using an iterative waterfall model of development. The
incremental model is schematically shown in Figure 2.8. As each successive
version of the software is constructed and delivered to the customer, the
customer feedback is obtained on the delivered version and these feedbacks
are incorporated in the next version. Each delivered version of the software
incorporates additional features over the previous version and also refines the
features that were already delivered to the customer.
The incremental model has schematically been shown in Figure 2.8. After
the requirements gathering and specification, the requirements are split into
several versions. Starting with the core (version 1), in each successive
increment, the next version is constructed using an iterative waterfall model
of development and deployed at the customer site. After the last (shown as
version n) has been developed and deployed at the client site, the full
software is deployed.

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

Figure 2.8: Incremental model of software development.

Advantages
The incremental development model offers several advantages. Two
important ones are the following:

Error reduction: The core modules are used by the customer from
the beginning and therefore these get tested thoroughly. This reduces
chances of errors in the core modules of the final product, leading to
greater reliability of the software.
Incremental resource deployment: This model obviates the need
for the customer to commit large resources at one go for development
of the system. It also saves the developing organisation from deploying
large resources and manpower for a project in one go.

2.2.6 Evolutionary Model

This model has many of the features of the incremental model. As in
case of the incremental model, the software is developed over a
number of increments. At each increment, a concept (feature) is
implemented and is deployed at the client site. The software is

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

successively refined and feature-enriched until the full software is

realised. The principal idea behind the evolutionary life cycle model is
conveyed by its name. In the incremental development model,
complete requirements are first developed and the SRS document
prepared. In contrast, in the evolutionary model, the requirements,
plan, estimates, and solution evolve over the iterations, rather than
fully defined and frozen in a major up-front specification effort before
the development iterations begin. Such evolution is consistent with the
pattern of unpredictable feature discovery and feature changes that
take place in new product development.
Though the evolutionary model can also be viewed as an extension o f the
waterfall model, but it incorporates a major paradigm shift that has been
widely adopted in many recent life cycle models. Due to obvious reasons, the
evolutionary software development process is sometimes referred to as
design a little, build a little, test a little, deploy a little model. This means that
after the requirements have been specified, the design, build, test, and
deployment activities are iterated. A schematic representation of the
evolutionary model of development has been shown in Figure 2.9.

Advantages
The evolutionary model of development has several advantages. Two
important advantages of using this model are the following:

Effective elicitation of actual customer requirements: In this

model, the user gets a chance to experiment with a partially developed
software much before the complete requirements are developed.
Therefore, the evolutionary model helps to accurately elicit user
requirements with the help of feedback obtained on the delivery of
different versions of the software. As a result, the change requests
after delivery of the complete software gets substantially reduced.
Easy handling change requests: In this model, handling change
requests is easier as no long term plans are made. Consequently,
reworks required due to change requests are normally much smaller
compared to the sequential models.

Disadvantages
The main disadvantages of the successive versions model are as follows:

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

Figure 2.9: Evolutionary model of software development.

Feature division into incremental parts can be non-trivial: For

many development projects, especially for small-sized projects, it is
difficult to divide the required features into several parts that can be
incrementally implemented and delivered. Further, even for larger
problems, often the features are so interwined and dependent on each
other that even an expert would need considerable effort to plan the
incremental deliveries.
Ad hoc design: Since at a time design for only the current increment is
done, the design can become ad hoc without specific attention being
paid to maintainability and optimality. Obviously, for moderate sized
problems and for those for which the customer requirements are clear,
the iterative waterfall model can yield a better solution.

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

Applicability of the evolutionary model

The evolutionary model is normally useful for very large products, where it is
easier t o find modules for incremental implementation. Often evolutionary
model is used when the customer prefers to receive the product in increments
so that he can start using the different features as and when they are
delivered rather than waiting all the time for the full product to be developed
and delivered. Another important category of projects for which the
evolutionary model is suitable, is projects using object-oriented development.

The evolutionary model is well-suited to use in object-oriented software development

projects.

Evolutionary model is appropriate for object-oriented development project,

since it is easy to partition the software into stand alone units in terms of the
classes. Also, classes are more or less self contained units that can be
developed independently.

2.3 RAPID APPLICATION DEVELOPMENT (RAD)

The rapid application development (RAD) model was proposed in the early
nineties in an attempt to overcome the rigidity of the waterfall model
(and its derivatives) that makes it difficult to accommodate any change
requests from the customer. It proposed a few radical extensions to the
waterfall model. This model has the features of both prototyping and
evolutionary models. It deploys an evolutionary delivery m o de l to
obtain and incorporate the customer feedbacks on incrementally
delivered versions.
In this model prototypes are constructed, and incrementally the features
are developed and delivered to the customer. But unlike the prototyping
model, the prototypes are not thrown away but are enhanced and used in the
software construction
The major goals of the RAD model are as follows:

To decrease the time taken and the cost incurred to develop software
systems.
To limit the costs of accommodating change requests.
T o reduce the communication gap between the customer and the
developers.

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

Main motivation
In the iterative waterfall model, the customer requirements need to be
gathered, analysed, documented, and signed off upfront, before any
development could start. However, often clients do not know what they
exactly wanted until they saw a working system. It has now become
well accepted among the practitioners that only through the process
commenting on an installed application that the exact requirements can
be brought out. But in the iterative waterfall model, the customers do
not get to see the software, until the development is complete in all
respects and the software has been delivered and installed. Naturally,
the delivered software often does not meet the customer expectations
and many change request are generated by the customer. The changes
are incorporated through subsequent maintenance efforts. This made
the cost of accommodating the changes extremely high and it usually
took a long time to have a good solution in place that could reasonably
meet the requirements of the customers. The RAD model tries to
overcome this problem by inviting and incorporating customer feedback
on successively developed and refined prototypes.
2.3.1 Working of RAD
In the RAD model, development takes place in a series of short cycles or
iterations. At any time, the development team focuses on the present iteration
only, and therefore plans are made for one increment at a time. The time planned
for each iteration is called a time box. Each iteration is planned to enhance the
implemented functionality of the application by only a small amount. During each
time box, a quick-and-dirty prototype-style software for some functionality is
developed. The customer evaluates the prototype and gives feedback on the
specific improvements that may be necessary. The prototype is refined based on
the customer feedback. Please note that the prototype is not meant to be released
to the customer for regular use though.
The development team almost always includes a customer representative
to clarify the requirements. This is intended to make the system tuned to the
exact customer requirements and also to bridge the communication gap
between the customer and the development team. The development team
usually consists of about five to six members, including a customer
representative.
How does RAD facilitate accommodation of change requests?
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

The customers usually suggest changes to a specific feature only after

they have used it. Since the features are delivered in small increments,
the customers are able to give their change requests pertaining to a
feature already delivered. Incorporation of such change requests just
after the delivery of an incremental feature saves cost as this is carried
out before large investments have been made in development and
testing of a large number of features.
How does RAD facilitate faster development?
The decrease in development time and cost, and at the same time an
increased flexibility to incorporate changes are achieved in the RAD
model in two main ways—minimal use of planning and heavy reuse of
any existing code through rapid prototyping. The lack of long-term and
detailed planning gives the flexibility to accommodate later
requirements changes. Reuse of existing code has been adopted as an
important mechanism of reducing the development cost.
RAD model emphasises code reuse as an important means for completing a
project faster. In fact, the adopters of the RAD model were the earliest to
embrace object-oriented languages and practices. Further, RAD advocates
use of specialised tools to facilitate fast creation of working prototypes. These
specialised tools usually support the following features:

Visual style of development.

Use of reusable components.

2.3.2 Applicability of RAD Model

The following are some of the characteristics of an application that
indicate its suitability to RAD style of development:

Customised software: As already pointed out a customised software is

developed for one or two customers only by adapting an existing software. In
customised software development projects, substantial reuse is usually made of
code from pre-existing software. For example, a company might have
developed a software for automating the data processing activities at
one or more educational institutes. When any other institute requests
for an automation package to be developed, typically only a few
aspects needs to be tailored—since among different educational

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

institutes, most of the data processing activities such as student

registration, grading, fee collection, estate management, accounting,
maintenance of staff service records etc. are similar to a large extent.
Projects involving such tailoring can be carried out speedily and cost-
effectively using the RAD model.
Non-critical software: The RAD model suggests that a quick and
dirty software should first be developed and later this should be refined
into the final software for delivery. Therefore, the developed product is
usually far from being optimal in performance and reliability. In this
regard, for well understood development projects and where the scope
of reuse is rather restricted, the Iiterative waterfall model may provide
a better solution.
Highly constrained pro ject schedule: RAD aims to reduce
development time at the expense of good documentation,
performance, and reliability. Naturally, for projects with very
aggressive time schedules, RAD model should be preferred.
Large software: Only for software supporting many features (large
software) can incremental development and delivery be meaningfully
carried out.

Application characteristics that render RAD unsuitable

The RAD style of development is not advisable if a development project
has one or more of the following characteristics:

Generic products (wide distribution): As we have already pointed

out in Chapter 1, software products are generic in nature and usually
have wi de distribution. For such systems, optimal performance and
reliability are imperative in a competitive market. As it has already
been discussed, the RAD model of development may not yield systems
having optimal performance and reliability.
Requirement of optimal performance and/or reliability: For
certain categories of products, optimal performance or reliability is
required. Examples of such systems include an operating system (high
reliability required) and a flight simulator software (high performance
required). If such systems are to be developed using the RAD model,
the desired product performance and reliability may not be realised.
Lack of similar products: If a company has not developed similar

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

software, then it would hardly be able to reuse much of the existing

artifacts. In the absence of sufficient plug-in components, it becomes
difficult to develop rapid prototypes through reuse, and use of RAD
model becomes meaningless.
Monolithic entity: For certain software, especially small-sized
software, it may be hard to divide the required features into parts that
can be incrementally developed and delivered. In this case, it becomes
difficult to develop a software incrementally.

2.3.3 Comparison of RAD with Other Models

In this section, we compare the relative advantages and disadvantages
of RAD with other life cycle models.

RAD versus prototyping model

In the prototyping model, the developed prototype is primarily used by the
development team to gain insights into the problem, choose between
alternatives, and elicit customer feedback. The code developed during
prototype construction is usually thrown away. In contrast, in RAD it is the
developed prototype that evolves into the deliverable software.

Though RAD is expected to lead to faster software development compared to the

traditional models (such as the prototyping model), though the quality and reliability
would be inferior.

RAD versus iterative waterfall model

In the iterative waterfall model, all the functionalities of a software are
developed together. On the other hand, in the RAD model the product
functionalities are developed incrementally through heavy code and
design reuse. Further, in the RAD model customer feedback is obtained
on the developed prototype after each iteration and based on this the
prototype is refined. Thus, it becomes easy to accommodate any
request for requirements changes. However, the iterative waterfall
model does not support any mechanism to accommodate any
requirement change requests. The iterative waterfall model does have
some important advantages that include the following. Use of the
iterative waterfall model leads to production of good quality
documentation which can help during software maintenance. Also, the
developed software usually has better quality and reliability than that
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

developed using RAD.

RAD versus evolutionary model

Incremental development is the hallmark of both evolutionary and RAD
models. However, in RAD each increment results in essentially a quick
and dirty prototype, whereas in the evolutionary model each increment
is systematically developed using the iterative waterfall model. Also in
the RAD model, software is developed in much shorter increments
compared the evolutionary model. In other words, the incremental
functionalities that are developed are of fairly larger granularity in the
evolutionary model.

2.4 AGILE DEVELOPMENT MODELS

As already pointed out, though the iterative waterfall model has been very
popular during the 1970s and 1980s, developers face several problems while
using it on present day software projects. The main difficulties included
handling change requests from customers during product development, and
the unreasonably high cost and time that is incurred while developing
customised applications. Capers Jones carried out research involving 800 real-
life software development projects, and concluded that on the average 40 per
cent of the requirements is arrived after the development has already begun.
In this context, over the last two decade or so, several life cycle models have
been proposed to overcome the important shortcomings o f the waterfall-
based models that become conspicuous when used in modern software
development projects.

Over the last two decades or so, projects using iterative waterfall-based life cycle
models are becoming rare due to the rapid shift in the characteristics of the software
development projects over time. Two changes that are becoming noticeable are rapid
shift from development of software products to development of customised software
and the increased emphasis and scope for reuse.

In the following, a few reasons why the waterfall-based development was

becoming difficult to use in project in recent times:

In the traditional iterative waterfall-based software development

models, the requirements for the system are determined at the start of
a development project and are assumed to be fixed from that point on.
Later changes to the requirements after the SRS document has been
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

completed are discouraged. If at all any later requirement changes

becomes unavoidable, then the cost of accommodating it becomes
prohibitively high. On the other hand, accumulated experience
indicates that customers frequently change their requirements during
the development period due to a variety of reasons.
As pointed out in Chapter 1, over the last two decades or so,
customised applications (services) has become common place and the
sales revenue generated world wide from services already exceeds
that of the software products. Clearly, iterative waterfall model is not
suitable for development of such software. Since customization
essentially involves reusing most of the parts of an existing application
and consists of only carrying out minor modifications by writing
minimal amounts of code. For such development projects, the need for
more appropriate development models was deeply felt, and many
researchers started to investigate in this direction.
Waterfall model is called a heavy weight model, since there is too much
emphasis on producing documentation and usage of tools. This is often
a source of inefficiency and causes the project completion time to be
much longer in comparison to the customer expectations.
Waterfall model prescribes almost no customer interactions after the
requirements have been specified. In fact, in the waterfall model of
software development, customer interactions are largely confined to
the project initiation and project completion stages.

The agile software development model was proposed in the mid-1990s to

overcome the serious shortcomings of the waterfall model of development
identified above. The agile model was primarily designed to help a project to
adapt to change requests quickly.1Thus, a major aim of the agile models is to
facilitate quick project completion. But, how is agility achieved in these
models? Agility is achieved by fitting the process to the project, i.e. removing
activities that may not be necessary for a specific project. Also, anything that
that wastes time and effort is avoided.
Please note that agile model is being used as an umbrella term to refer to a
group of development processes. These processes share certain common
characteristics, but do have certain subtle differences among themselves. A
few popular agile SDLC models are the following:

Crystal
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

Atern (formerly DSDM)

Feature-driven development
Scrum
Extreme programming (XP)
Lean development
Unified process

In the agile model, the requirements are decomposed into many small
parts that can be incrementally developed. The agile model adopts an
iterative approach. Each incremental part is developed over an iteration. Each
iteration is intended to be small and easily manageable and lasting f o r a
couple of weeks only. At a time, only one increment is planned, developed,
and then deployed at the customer site. No long-term plans are made. The
time to complete an iteration is called a time box. The implication of the term
time box is that the end date for an iteration does not change. That is, the
delivery date is considered sacrosanct. The development team can, however,
decide to reduce the delivered functionality during a time box if necessary.
A central principle of the agile model is the delivery of an increment to the
customer after each time box. A few other principles that are central to the
agile model are discussed below.
2.4.1 Essential Idea behind Agile Models
For establishing close contact with the customer during development and
to gain a clear understanding of the domain-specific issues, each agile
project usually includes a customer representative in the team. At the
end of each iteration, stakeholders and the customer representative
review the progress made and re-evaluate the requirements. A
distinguishing characteristics of the agile models is frequent delivery of
software increments to the customer.
Agile model emphasise face-to-face communication over written
documents. It is recommended that the development team size be
deliberately kept small (5–9 people) to help the team members meaningfully
engage in face-to-face communication and have collaborative work
environment. It is implicit then that the agile model is suited to the
development of small projects. However, if a large project is required to be
developed using the agile model, it is likely that the collaborating teams
might work at different locations. In this case, the different teams are needed
to maintain as much daily contact as possible through video conferencing,
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

telephone, e-mail, etc.

The agile model emphasises incremental release of working software as the primary
measure of progress.

The following important principles behind the agile model were publicised
in the agile manifesto in 2001:

Working software over comprehensive documentation.

Frequent delivery of incremental versions of the software to the
customer in intervals of few weeks.
Requirement change requests from the customer are encouraged and
are efficiently incorporated.
Having competent team members and enhancing interactions among
them is considered much more important than issues such as usage of
sophisticated tools or strict adherence to a documented process. It is
advocated that enhanced communication among the development
team members can be realised through face-to-face communication
rather than through exchange of formal documents.
Continuous interaction with the customer is considered much more
important rather than effective contract negotiation. A customer
representatives is required to be a part of the development team, thus
facilitating close, daily co-operation between customers and
developers.

Agile development projects usually deploy pair programming.

In pair programming, two programmers work together at one work station. One types
in code while the other reviews the code as it is typed in. T he two programmers
switch their roles every hour or so.

Several studies indicate that programmers working in pairs produce

compact well-written programs and commit fewer errors as compared to
programmers working alone.

Advantages and disadvantages of agile methods

The agile methods derive much of their agility by relying on the tacit
knowledge of the team members about the development project and
informal communications to clarify issues, rather than spending
significant amounts of time in preparing formal documents and
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

reviewing them. Though this eliminates some overhead, but lack of

adequate documentation may lead to several types of problems, which
are as follows:

Lack of formal documents leaves scope for confusion and important

decisions taken during different phases can be misinterpreted at later
points of time by different team members.
In the absence of any formal documents, it becomes difficult to get
important project decisions such as design decisions to be reviewed by
external experts.
When the project completes and the developers disperse, maintenance
can become a problem.

2.4.2 Agile versus Other Models

In the following subsections, we compare the characteristics of the agile
model with other models of development.

Agile model versus iterative waterfall model

The waterfall model is highly structured and systematically steps through
requirements-capture, analysis, specification, design, coding, and
testing stages in a planned sequence. Progress is generally measured in
terms of the number of completed and reviewed artifacts such as
requirement specifications, design documents, test plans, code reviews,
etc. for which review is complete. In contrast, while using an agile
model, progress is measured in terms of the developed and delivered
functionalities. In agile model, delivery of working versions of a
software is made in several increments. However, as regards to
similarity it can be said that agile teams use the waterfall model on a
small scale, repeating the entire waterfall cycle in every iteration.
If a project being developed using waterfall model is cancelled mid-way
during development, then there i s nothing to show from the abandoned
project beyond several documents. With agile model, even if a project is
cancelled midway, it still leaves the customer with some worthwhile code,
that might possibly have already been put into live operation.

Agile versus exploratory programming

Though a few similarities do exist between the agile and exploratory
programming styles, there are vast differences between the two as
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

well. Agile development model’s frequent re- evaluation of plans,

emphasis on face-to-face communication, and relatively sparse use of
documentation are similar to that of the exploratory style. Agile teams,
however, do follow defined and disciplined processes and carry out
systematic requirements capture, rigorous designs, compared to chaotic
coding in exploratory programming.

Agile model versus RAD model

The important differences between the agile and the RAD models are
the following:

Agile model does not recommend developing prototypes, but

emphasises systematic development of each incremental feature. In
contrast, the central theme of RAD is based on designing quick-and-
dirty prototypes, which are then refined into production quality code.
Agile projects logically break down the solution into features that are
incrementally developed and delivered. The RAD approach does not
recommend this. Instead, developers using the RAD model focus on
developing all the features of an application by first doing it badly and
then successively improving the code over time.
Agile teams only demonstrate completed work to the customer. In
contrast, RAD teams demonstrate to customers screen mock ups, and
prototypes, that may be based on simplifications such as table look-ups
rather than actual computations.

2.4.3 Extreme Programming Model

Extreme programming (XP) is an important process model under the
agile umbrella and was proposed by Kent Beck in 1999. The name of
this model reflects the fact that it recommends taking t he s e best
practices that have worked well in the past in program development
projects to extreme levels. This model is based on a rather simple
philosophy: ”If something is known to be beneficial, why not put it to
constant use?” Based on this principle, it puts forward several key
practices that need to be practised to the extreme. Please note that
most of the key practices that it emphasises were already recognised as
good practices for some time.

Good practices that need to be practised to the extreme

******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

In the following subsections, we mention some of the good practices that

have been recognised in the extreme programming model and the
suggested way to maximise their use:
Code review: It is good since it helps detect and correct problems most
efficiently. It suggests pair programming as the way to achieve continuous
review. In pair programming, coding is carried out by pairs of programmers.
The programmers take turn in writing programs and while one writes the
other reviews code that is being written.
Testing: Testing code helps to remove bugs and improves its reliability. XP
suggests test-driven development (TDD) to continually write and execute test
cases. In the TDD approach, test cases are written even before any code is
written.
Incremental development: Incremental development is good, since it
helps to get customer feedback, and extent of features delivered is a reliable
indicator of progress. It suggests that the team should come up with new
increments every few days.
Simplicity: Simplicity makes it easier to develop good quality code, as well
as to test and debug it. Therefore, one should try to create the simplest code
that makes the basic functionality being written to work. For creating the
simplest code, one can ignore the aspects such as efficiency, reliability,
maintainability, etc. Once the simplest thing works, other aspects can be
introduced through refactoring.
Design: Since having a good quality design is important to develop a good
quality solution, everybody should design daily. This can be achieved through
refactoring, whereby a working code is improved for efficiency and
maintainability.
Integration testing: It is important since it helps identify the bugs at the
interfaces of different functionalities. To this end, extreme programming
suggests that the developers should achieve continuous integration, by
building and performing integration testing several times a day.

Basic idea of extreme programming model

XP is based on frequent releases (called iteration ), during which the
developers implement “user stories”. User stories are similar to use
cases, but are more informal and are simpler. A user story is the
conversational description by the user about a feature of the required

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

system. For example, a user story about a library software can be:

A library member can issue a book.

A library member can query about the availability of a book.
A library member should be able to return a borrowed book.

A user story is a simplistic statement of a customer about a functionality he needs, it

does not mention about finer details such as the different scenarios that can occur,
the precondition (state at which the system) to be satisfied before the feature can be
invoked, etc.
On the basis o f user stories, the project team proposes “metaphors”—a
common vision of how the system would work. The development team may
decide to construct a spike for some feature. A spike, is a very simple program
that is constructed to explore the suitability of a solution being proposed. A
spike can be considered to be similar to a prototype.
X P prescribes several basic activities to be part of the software
development process. We discuss these activities in the following
subsections:
Coding: XP argues that code is the crucial part o f any system development
process, since without code it is not possible to have a working system.
Therefore, utmost care and attention need to be placed on coding activity.
However, the concept of code as used in XP has a slightly different meaning
from what is traditionally understood. For example, coding activity includes
drawing diagrams (modelling) that will be transformed to code, scripting a
web-based system, and choosing among several alternative solutions.
Testing: XP places high importance on testing and considers it be the
primary means for developing a fault-free software.
Listening: The developers need to carefully listen to the customers if they
have to develop a good quality software. Programmers may not necessarily
be having an in-depth knowledge of the the specific domain of the system
under development. On the other hand, customers usually have this domain
knowledge. Therefore, for the programmers to properly understand what the
functionality of the system should be, they have to listen to the customer.
Designing: Without proper design, a system implementation becomes too
complex and the dependencies within the system become too numerous and
it becomes very difficult to comprehend the solution, and thereby making
maintenance prohibitively expensive. A good design should result in
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

elimination of complex dependencies within a system. Thus, effective use of a

suitable design technique is emphasised.
Feedback: It espouses the wisdom: “A system staying out of users is trouble
waiting to happen”. It recognises the importance of user feedback in
understanding the exact customer requirements. The time that elapses
between the development of a version and collection of feedback on it is
critical to learning and making changes. It argues that frequent contact with
the customer makes the development effective.
Simplicity: A corner-stone of XP is based on the principle: “build something
simple that will work today, rather than trying to build something that would
take time and yet may never be used”. This in essence means that attention
should be focused on specific features that are immediately needed and
making them work, rather than devoting time and energy on speculations
about future requirements.

XP is in favour of making the solution to a problem as simple as possible. In contrast,

the traditional system development methods recommend planning for reusability and
future extensibility of code and design at the expense of higher code and design
complexity.

Applicability of extreme programming model

The following are some of the project characteristics that indicate the
suitability of a project for development using extreme programming
model:
Projects involving new technology or research pro jects: In this case,
the requirements change rapidly and unforeseen technical problems need to
be resolved.
Small projects: Extreme programming was proposed in the context of small
teams as face to face meeting is easier to achieve.

Project characteristics not suited to development using

agile models
The following are some of the project characteristics that indicate
unsuitability of agile development model for use in a development
project:

Stable requirements: Conventional development models are more

suited to use in projects characterised by stable requirements. For such
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

projects, it is known that few changes, if at all, will occur. Therefore,

process models such as iterative waterfall model that involve making
long-term plans during project initiation can meaningfully be used.
Mission critical or safety critical systems: In the development of
such systems, the traditional SDLC models are usually preferred to
ensure reliability.

2.4.4 Scrum Model

In the scrum model, a project is divided into small parts of work that can
be incrementally developed and delivered over time boxes that are
called sprints. The software therefore gets developed over a series of
manageable chunks. Each sprint typically takes only a couple of weeks
to complete. At the end of each sprint, stakeholders and team members
meet to assess the progress made and the stakeholders suggest to the
development team any changes needed to features that have already
been developed and any overall improvements that they might feel
necessary.
In the scrum model, the team members assume three fundamental roles—
software owner, scrum master, and team member. The software owner is
responsible for communicating the customers vision of the software to the
development team. The scrum master acts as a liaison between the software
owner and the team, thereby facilitating the development work.

2.5 SPIRAL MODEL

This model gets its name from the appearance of its diagrammatic
representation that looks like a spiral with many loops (see Figure
2.10). The exact number of loops of the spiral is not fixed and can vary
from project to project. The number of loops shown in Figure 2.10 is
just an example. Each loop of the spiral is called a phase of the software
process. The exact number of phases through which the product is
developed can be varied by the project manager depending upon the
project risks. A prominent feature of the spiral model is handling
unforeseen risks that can show up much after the project has started. In
this context, please recollect that the prototyping model can be used
effectively only when the risks in a project can be identified upfront
before the development work starts. As we shall discuss, this model
achieves this by incorporating much more flexibility compared to SDLC

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

other models.
While the prototyping model does provide explicit support for risk handling,
the risks are assumed to have been identifie d completely before the project
start. This is required since the prototype is constructed only at the start of
the project. In contrast, in the spiral model prototypes are built at the start of
every phase. Each phase of the model is represented as a loop in its
diagrammatic representation. Over each loop, one or more features of the
product are elaborated and analysed and the risks at that point of time are
identified and are resolved through prototyping. Based on this, the identified
features are implemented.

Figure 2.10: Spiral model of software development.

Risk handling in spiral model

A risk is essentially any adverse circumstance that might hamper the
successful completion of a software project. As an example, consider a
project for which a risk can be that data access from a remote database
might be too slow to be acceptable by the customer. This risk can be
resolved by building a prototype of the data access subsystem and
experimenting with the exact access rate. If the data access rate is too
slow, possibly a caching scheme can be implemented or a faster

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

communication scheme can be deployed to overcome the slow data

access rate. Such risk resolutions are easier done by using a prototype
as the pros and cons of an alternate solution scheme can evaluated
faster and inexpensively, as compared to experimenting using the
actual software application being developed. The spiral model supports
coping up with risks by providing the scope to build a prototype at every
phase of software development.
2.5.1 Phases of the Spiral Model
Each phase in this model is split into four sectors (or quadrants) as
shown in Figure 2.10. In the first quadrant, a few features of the
software are identified to be taken u p for immediate development
based on how crucial it is to the overall software development. With
each iteration around the spiral (beginning at the center and moving
outwards), progressively more complete versions of the software get
built. In other words, implementation of the identified features forms a
phase.
Quadrant 1: The objectives are investigated, elaborated, and analysed.
Based on this, the risks involved in meeting the phase objectives are
identified. In this quadrant, alternative solutions possible for the phase under
consideration are proposed.
Quadrant 2: During the second quadrant, the alternative solutions are
evaluated to select the best possible solution. To be able to do this, the
solutions are evaluated by developing an appropriate prototype.
Quadrant 3: Activities during the third quadrant consist of developing and
verifying the next level of the software. At the end of the third quadrant, the
identified features have been implemented and the next version of the
software is available.
Quadrant 4: Activities during the fourth quadrant concern reviewing the
results of the stages traversed so far (i.e. the developed version of the
software) with the customer and planning the next iteration of the spiral.
The radius of the spiral at any point represents the cost incurred in the
project so far, and the angular dimension represents the progress made so
far in the current phase.
In the spiral model of development, the project manager dynamically
determines the number of phases as the project progresses. Therefore, in this
model, the project manager plays the crucial role of tuning the model to
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

specific projects.
To make the model more efficient, the different features of the software
that can be developed simultaneously through parallel cycles are identified.
To keep our discussion simple, we shall not delve into parallel cycles in the
spiral model.

Advantages/pros and disadvantages/cons of the spiral

model
There are a few disadvantages of the spiral model that restrict its use to
a only a few types of projects. To the developers of a project, the spiral
model usually appears as a complex model to follow, since it is risk-
driven and is more complicated phase structure than the other models
we discussed. It would therefore be counterproductive to use, unless
there are knowledgeable and experienced staff in the project. Also, it is
not very suitable for use in the development of outsourced projects,
since the software risks need to be continually assessed as it is
developed.
In spite of the disadvantages of the spiral model that we pointed out, for
certain categories of projects, the advantages of the spiral model can
outweigh its disadvantages.
For projects having many unknown risks that might show up as the development
proceeds, the spiral model would be the most appropriate development model to
follow.

In this regard, it is much more powerful than the prototyping model.

Prototyping model can meaningfully be used when all the risks associated
with a project are known beforehand. All these risks are resolved by building
a prototype before the actual software development starts.

Spiral model as a meta model

As compared to the previously discussed models, the spiral model can be
viewed as a met a model, since it subsumes all the discussed models. For
example, a single loop spiral actually represents the waterfall model. The
spiral model uses the approach of the prototyping model by first building a
prototype in each phase before the actual development starts. This
prototypes are used as a risk reduction mechanism. The spiral model
incorporates the systematic step- wise approach of the waterfall model. Also,
the spiral model can be considered as supporting the evolutionary model—the
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

iterations along the spiral can be considered as evolutionary levels through

which the complete system is built. This enables the developer to understand
and resolve the risks at each evolutionary level (i.e. iteration along the
spiral).

Case study 2.2

Galaxy Inc. undertook the development of a satellite-based communication between
mobile handsets that can be anywhere on the earth. In contrast to the traditional cell
phones, by using a satellite-based mobile phone a call can be established as long as
both the source and destination phones are in the coverage areas of some base
stations. The system would function through about six dozens of satellites orbiting
the earth. The satellites would directly pick up the signals from a handset and beam
signal to the destination handset. Since the foot prints of the revolving satellites
would cover the entire earth, communication between any two points on the earth,
even between remote places such as those in the Arctic ocean and Antarctica, would
also be possible. However, the risks in the project are many, including determining
how the calls among the satellites can be handed-off when they are themselves
revolving at a very high speed. In the absence of any published material and
availability of staff with experience in development of similar products, many of the
risks cannot be identified at the start of the project and are likely to crop up as the
project progresses. The software would require several million lines of code to be
written. Galaxy Inc. decided to deploy the spiral model for software development
after hiring highly qualified staff. To speed up the software development,
independent parts of the software were developed through parallel cycles on the
spiral. The cost and delivery schedule were refined many times, as the project
progressed. The project was successfully completed after five years from start date

2.6 A COMPARISON OF DIFFERENT LIFE CYCLE MODELS

The classical waterfall model can be considered as the basic model and
all other life cycle models as embellishments of this model. However,
the classical waterfall model cannot be used in practical development
projects, since this model supports no mechanism to correct the errors
that are committed during any of the phases but detected at a later
phase. This problem is overcome by the iterative waterfall model
through the provision of feedback paths.
The iterative waterfall model is probably the most widely used software
development model so far. This model is simple to understand and use.
However, this model is suitable only for well-understood problems, and is not
suitable for development of very large projects and projects that suffer from
large number of risks.

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

The prototyping model is suitable for projects for which either the user
requirements or the underlying technical aspects are not well understood,
however all the risks can be identified before the project starts. This model is
especially popular for development of the user interface part of projects.
The evolutionary approach is suitable for large problems which can be
decomposed into a set of modules for incremental development and delivery.
This model is also used widely for object-oriented development projects. Of
course, this model can only be used if incremental delivery of the system is
acceptable to the customer.
The spiral model is considered a meta model and encompasses all other life
cycle models. Flexibility and risk handling are inherently built into this model.
The spiral model is suitable for development of technically challenging and
large software that are prone to several kinds of risks that are difficult to
anticipate at the start of the project. However, this model is mu ch more
complex than the other models—this is probably a factor deterring its use in
ordinary projects.
Let us now compare the prototyping model with the spiral model. The
prototyping model can be used if the risks are few and can be determined at
the start of the project. The spiral model, on the other hand, is useful when
the risks are difficult to anticipate at the beginning of the project, but are
likely to crop up as the development proceeds.
Let us compare the different life cycle models from the viewpoint of the
customer. Initially, customer confidence is usually high on the development
team irrespective of the development model followed. During the lengthy
development process, customer confidence normally drops off, as no working
software is yet visible. Developers answer customer queries using technical
slang, and delays are announced. This gives rise to customer resentment. On
the other hand, an evolutionary approach lets the customer experiment with
a working software much earlier than the monolithic approaches. Another
important advantage of the incremental model is that it reduces the
customer’s trauma of getting used to an entirely new system. The gradual
introduction of the software via incremental phases provides time to the
customer t o adjust to the new software. Also, from the customer’s financial
view point, incremental development does not require a large upfront capital
outlay. The customer can order the incremental versions as and when he can
afford them.
2.6.1 Selecting an Appropriate Life Cycle Model for a Pro ject

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

We have discussed the advantages and disadvantages of the various life

cycle models. However, how to select a suitable life cycle model for a
specific project? The answer to this question would depend on several
factors. A suitable life cycle model can possibly be selected based on an
analysis of issues such as the following:
Characteristics of the software to be developed: The choice of the life
cycle model to a large extent depends on the nature of the software that is
being developed. For small services projects, the agile model is favoured. On
the other hand, for product and embedded software development, the
iterative waterfall model can be preferred. An evolutionary model is a
suitable model for object-oriented development projects.
Characteristics of the development team: The skill-level of the team
members is a significant factor in deciding about the life cycle model to use.
If the development team is experienced in developing similar software, then
even an embedded software can be developed using an iterative waterfall
model. If the development team is entirely novice, then even a simple data
processing application may require a prototyping model to be adopted.
Characteristics of the customer: If the customer is not quite familiar with
computers, then the requirements are likely to change frequently as it would
be difficult to form complete, consistent, and unambiguous requirements.
Thus, a prototyping model may be necessary to reduce later change requests
from the customers.

SUMMARY

During the development of any type of software, adherence to a

suitable process model has become universally accepted by software
development organisations. Adoption of a suitable life cycle model is
now accepted as a primary necessity for successful completion of
projects.
We discussed only the central ideas behind some important process
models. Good software development organisations carefully and
elaborately document the precise process model they follow and
typically include the following in the document:

– Identification of the different phases.

– Identification of the different activities in each phase and the order in
which they are carried out.
******ebook converter DEMO - www.ebook-converter.com*******