Software Life Cycle

2 h e ultimate
Models

objective of software
frame
engineering

and at
is to produce
affordable cost.
This
good
is
be
quality

possible
maintainable

a c h i e v a b l e only

to
if w e
determine

within r e a s o n a b l e
time
process,
it should This c a n
software it. For a m a t u r e the final product.
matured processes
to produce to produce the soft-
nave effort will be required must
measure

how much time

and that we
which requires
aavance from past experience,
done using data
0nly be a
software
when developing
ware process. process mature
follow s o m e In
organizations written down.
development usually not
the process is
Software
of any
immature organizations,
managed. A key component
product. In and is actively
is in writing particular
o r g a n i z a t i o n s , the process the process is basedhe
model on which
is the life cycle associated with a
softwareproduct
software development process costs
overall life cycle ends at the retirement
model.cansignificantly affect
explaration and
htecycle Life of the software
starts from concept
TRAKI97]. cycle
of the software. Terminology, the software life
of software Engineering
standard Glossary
In the IEEE
ends when the.
cycle
is:
when a software product is conceived and
The period of timethat starts cycle typically includes a fèquirement
for use. The software life check out pha_e,.p-
product is no longer available phae, inktallation
and

phasedesign phase iplementation phase,test phase

and maintenance phasa and sometimes retirement that represents a software life
eraion abstraction
software life cvcle model is a particular wVe(SDLO, A
(A often called a software developmen fiia
software life cycle model is tasks involved in developing
CycleJA have been proposed and
are based on
models chapter.
variety of life cycle cycles models are discussed in this
Few well known life
and maintaining software.

2.1 BUILD AND FIX MODEL

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

20
 Software Life Cycle Models

ero

o
Build
code
Coct

Fix a Mailnauc
dpicut
Fig. 2.1: Build and fix model

Although tisapproach may work well onsmall programmingexercises 100or200 linesj

long, this model is totally unsatisfactory for software of any reasonable size
Code soon becomes

unfixable and unenhanceableyThere is noroom for designorany aspect ofdevelopment process

to be carried
isactually
out inastructured detailed way Thecostofthedevelopment using this approach
or

very high as compared to the cost of a properly specified and carefully designed
product. In addition, maintenance of the productcan be extremely dificult without specification
or design documents.

2.2 THE WATERFALL MODEL

The
most familiar model is the waterfall model, which isgiven in Fig. 2.2. This model has five
phases: Requirements analysis and specification? desig, implementation testing and unit
integration and system testingand operation and maintenance. The phases always occur in
this order and do not overlap/The developermust completeeach phase before the next phase
begins. This model is named "Waterfall Model", because its diagrammatic representation
resembles a cascade of waterfalls.
1. Requirement analysis and specification phase(Thegoal of this phase 1s to
understand theexactreauirements ofthecustomer and to document them properly This activity
is usually executed together with the customer, as the goal is to document all functions,
Dertormance and interfacing requirements for the sofiware The requirements describe the
What ofa system, not the how This phase produces a large document, written inanatural
language,contains a description of what the system will do without describing how it will be
done. he resultant document is known as software requirement specification (SRS) document.
The SRS document may act as contract betweenthe developerand customer. If developer
fails to implement full set of requirements, it may amount to failure to implement the contracted
system.
 22 Software Engineering

Requirement analysis
& Specification

Design
ovonl softunane,
Ovon d nehairtue
documula)
Sys SDD
tnt SDD
Implementation &
Solhware
PANe Unit testing

Integration &System
testing

Operation&
Maintenance

Fig. 2.2: Waterfall model

2. Design phase: The SRS document is produced in the previous phase, which contains
ne
exact requirements of the customer. The goal of this phase is to transtorm the requirements
Specification into a structure that is suitable for inmplementation in some programming language.
Here, overall software architecture is defined and
the high level and detailed design work is
performed. This work is documented and known as software design
The information contained in
description (SDD) docunment.
the SDD should be sufficient to begin the coding phase.
3. Implementation and unit
If the SDD is
testing phase: During this phase, design is implemented.
complete, the implementation or coding phase proceeds smoothly, because all the
information needed by the software developers is
containedin the.sDD
During testing, the major activities are centered around the examination and modifica-
tion of the
code.Initially, small modules are tested in isolation from the rest of the sofiware
product. There are problems associated with testing a module in isolation. EHow do we run a
module without anything to call it, to be called by it or, possibly, to output intermediate values
obtained during execution?Such problems solved in this and modules
are phase are tested
after writing some overhead code.
4. Integration and system testing phase: This is a very important phase. Etfective
testing will contribute to the delivery of higher quality software products, more satisfied users,
lower maintenancecosts,and more accurate and reliableresults Itis a very expensive activity
and consumes one-third to one half of the cost of a typical development project.
A s we know, the purpose of unit testing is to determine that each independent module is
Correctly implemented. This gives little chance to determine that the interface befween modules
is also corect, and for this reason integration testing is performed(System testing involves
the testing of the entire system, whereas software is a part ofthe system. This 1sessentiatto
build confidence in the developers before software is delivered to the customer or released in
the market.
5.Operation and maintenance phase Software maintenance is a task that every
development group hasto face, when the softwareis delivered to thecustomer's site,installed
nd is operationalyTherefore, release ofsoftware inaugurates the operation and maintenance
hase of the life cycle, The time spent and effort required to keep the software operational
 s a sm
Software Life Cyclo Models 23

after release is very significant. Despite the fact that it is a very important and challenging
task; it is routinely the poorly managed headache that nobody wants to face.
Software maintenance is a very broad activity that includes error correction, enhance
ment of capabilities, deletion of obsolete capabilities, and optimization/The purpose of this
phase is to preserve the value of the software over time This phase may span for 5 to 50 years m
whereas development may be 1 to 3 years.
This model is easy to understand and renforces the notion ofkdefine before desie and
("design before codeThis model expects complete and accurate requirements early in the
process, which 18 unrealistic. Working software is not available until relatively late in the
process, thus delaying the discovery of serious errors. It also does not incorporate any kind of
risk assessment.
Problems of waterfall model
i) It is difficult to define all requirements at the beginning of a project.
NaCoy (ti) This model is not suitable for accomodating any change.
i i ) A working version of the system is not seen until late in the project's lif.
v ) It does not scale up well to large projects.
(0) Real projects are rarely sequentil. .
Due to these weaknesses, the application of waterfall model should be limited to situa-
ions where therequirements and their implementation are well understood. For example, if
an organisation has experience in developing accounting systems then buildinga new acounting
system based on existing designs could be easily managed with the waterfall model.

2.3 INCREMENT PROCESS MODELS,

Increment process models are effective in the situations where requirements are defined
precisely and there 1s no coniusion about the fiinctionality ot the final product. (Although,
functionality can be delivered in phases as per desired priorities). After every cycle, a useable
product is given to the customer.For example, in the university automation software library
automation module may be deivered in the first phase and examination automation module
in the second phase and as so
on. Every new cycle will have an additional functionality
Increment process models are popular particularlywnen we have to quickly deliver a limited
functionality system,
2.3.1 lterative Enhancement Model
This model has the same phases as the waterfall model, but with fewer restrictions. Generally
the occur in the same order as in the waterfall model, but these may be
phases conducted in
several cycles. A useable product is released at the end of the each cycle, with each release
providing additional functionality [BASI75].
During the first requirements analysis phase, customers and developers specify as many
requirements as possible and prepare a SRS document. Developers and customers then prioritize
these requirements. Developersimplement thespecified requirements in one or more cycles of
design, implementation and test based on the defined priorities. The model is given in Fig. 2.3.
 Software Engineering

24 is the
delivery of
a complete,
opera-

models operational quality

aim of the
waterfall and prototyping
does deliver an A
The this model requirements.
In contrast,
customers
subset of the
the product lease
tional and good quality product.
satisfies only a relea:
developer delivers
that
at each release, but one
in Pig 2.3 Ateach
product releases, and the shown
The complete product is divided
releases a s
is required.
usually have
many
will portion of whatfirst
release. A typical product product that does a model, reles
lease
D c u s t o m e r has a n
operational quality
release. With this
release, some useful work
after first generally waits
months
The customer is able to do months,
whereas the customer
within few weeks or model
may be available and prototyping
waterfall
a product using the
or years to receive
Integration & Operation
TIplementahon & (Instal)
System
Requirements Design Unit testng testing
Release

Integration & Operation

Imolementation& System (Instal)
Design Unt testing testing

Release II

integration & Operation

impiementation& (Install)
Design Unit testing System
testing

Release ll

enhancement model
Fig. 2.3: terative
Ule uweRAnmuut
Development (RAD)
Model h yheud
2.3.2 The Rapid Application IBM in the 1980s and
incremental process model
and w a s developed by
This model is a n Development"(Here, user
James Martin entitled "Rapid Application
described in the book of product. The
continuous

requirement phase to delivery of

the
involvement is essential from expectations and perspective
in require-
user participation
ensures the involvement of user s
and design of the system.
ments elicitation, analysis and is given to u s e r for
evalua-
is started with building a rapid prototype the-
The process
and prototype is refined. The process continues, till
tion. The user feedback is obtained Brainstorm-
any grouping technique
(like FAST, QFD,
requirements are finalised. We may use
elicitation. Software requirement
chapter 3) for fequirèments
details refer
ing Sessions; for documents are prepared with the association
of users.
and specification (SRS) and design
in 2.4.
shown Fig.
There are four phases in this model and these are
With active participation of users

Requirenents User Construction Cut over

planning description

Fig. 2.4: RAD mode Au

 Software Lfe Cycle Models

(i) Requirements planning phase: Requirements are captured using any group
elicitation technique. Some techniques are discussed in
chapter 3. Only issue is the activee
involvement of users for
understanding the project.
(ii) User description: Joint teams of
developers and users are constítuted to prepare,
understand and review the requirements. The team may use automated
tools to captkre
information from the other users,
iii)Construction phase: This phase combines the defailéd desigk, codingarktestin
phase of waterfallmodel Here, we release the product to customer. ft is expected to Use Code
generators, sereen generators and other types of productivity tools
(iv) Cut over phase:This phase incorporates acceptancetesting by the usersinstallation
of the system, and user training,
Inthis modet quickinitíalviews about the product are possibledue to delivery of rapid
prototype.the development time of the product may bereduced due to use pf powerful
developmenttools. It may use CASE tools and framewotks toincrease productivity.(nvolvement
of user may increase the acceptability of the
product.
fuser gnotbeinvolved throughout the life cycle, this may not be an appropriate
model, Developiment tim may not be reduced very significantly,if reusablecomponents are
not available. Highly specialized and skilled developers are expected and such developers may
not be available very
easilyIt may notbeeffective, if system can not be properly modularised.
2.4 EVOLUTIONARY PROCESS MODELS
Evolutionary process model resembles iterative enhancement model The same phases as de
finedtorthe waterfall modeloccur here in acyclicalfashion.This model differs from iterative
enhancement modelin the sensethatthizdoes not requirea useabte producrat theend of each
cycle.jln evolutionary development, reáunements aTe mpiemented y taegory rather than
by priórity
For êxample, in a simple database application, one cycle might implement the graphical
user interface (GUI; another file manipulation; another queries; and another updates. All
four cycles must complete before there is working product available. GUI allows the users to
interact with the system; file manipulation allows data to be saved and retrieved; queries
allow users to get data out of the system,and updates allow users to put data into the system
With any one of those parts missing, the system would be unusable.
In contrast, an iterative enhancement modelwouldstart by developing a very simplistic,
but usable databasg. On the completion of each cycle, the system would hecome more
Sophisticated. It, would, however, provide all the critical functionality by the end of the first
cycle. Evolutionary development and iterative enhancement are somewhat interchangeable.
PEvolutionary development should beused whenit isnotnecessaryto provide a minimal version
volution

o f of the system quickly.

h e s e models are useful for projects using new technology that is not wel understood
This is also used for complex rojects where all functionality must be delivered at one time,
But the requirements are unstable or not well understood at the beginning.
 26

2.4.1 Prototyping Model that the working software

in the last section is
waterfall model a s
discussed of serious e r r o r s . An
A disadvantage of thus delaying the discovery
available until late in the
process,
the software
instead
of developing
S not working prototype of
first develop a current available requirements.(1
alternative to this is to developed as per
the actualsoftware. The working prototype is low reliability, and untested performance
limited functional
capabilities,
Basically, it has
(usually low). prepare the final
to refine the requirements and
(The developers use this prototype evaluated by the customer, it
been
Specincation document. Because
the workingprototype has correct. When the
the resulting specification document will be
that
15 reasonable to expectis reviewed by the customer. Typically this review gives
feedback to the
it of the software, and starts
rOtoLVpe is created, uncertainties in the requirements
developers that helps to r e m o v e as shown in Fig. 2.5.
an iteration of refinement in order to
further clarify requirements

Requirements

Als Quick design

wt tHg Refinement of
requirements as
per suggestions
Impleme

Customer Evaluaton Not accepted by customer

Accepted by customer

Design

impiermentation and Unit testing

S /
d s u

integration & System testing

Operation & Maintenanoe

Fig. 2.5: Prototyping model

TH
The prototype may be a usable program, but is not suitable as the final software product
The be poor
reason may performance, maintainability
or overall
prototyne is thrown away however the experience gathered from developing the prototype
quality. (The code for the
helps in developing the actual system. Therefore the development of a prototype might involve
 Software Life Cycle Models
27

extra cost, but overall cost might turnout to be lower than that of an
using the waterfall model. equivalent system developed
The developers should
develop prototype as early as possible to speed up the software
development process. After all, the sole use of this is to determine the customer's real needs.
Once this has been determined, the
prototype discarded. For this
is
of the prototype is not very important [SCHA96). hotobula reason, mah
the internalstructure
After the finalization of software SR
requirement and specification
(SRS) document, the
prototype is discarded and actual system is then developed using the waterfall
itis used as an input to waterfall model approach,Thus,
and produces maintainable and good quality
This model requires extensive participation and involvement of software.
the customer, which is not
always possible.
2.4.2 Spiral Model
The problem with traditional software process models is that theydo not deal
the uncertainty, which is inherent to software sufficiently with
because project risks were neglected
projects Impurtant software projects have failed
and nobody was prepared when something unforeseen
happened.|Barry Boehm recognized this and tried to incorporate the project riskSactor into
a life cycle model. The result is the spiral model, which was presented in 1986 [BOEH86] and
is shown in Fig. 2.6.
The radial dimension of the model represents the cumulative costs, Each path
the spiral is indicative of increased around
costs.The angular dimension represents the progress made
in
completing each cycle. Each loop of the spiral from X-axis
clockwise through 360° represents
one phase One phase is split roughly into four sectors of major activities:

Planning: Determination of objectives, alternatives and constraints

Risk analysis: Analyze alternatives and attempts to identify and resolve the risks in-
volved
2.Development: Product development and testing product
M Assessment; Customer evaluation, {
During the first phase, planding is performed, risks are/analyzed, prototypes
and customers are built,
evaluate the prototype. During the, second phase, a more refined prototyp 1s
built, requirements are documented and validated, and customers are involved in assessing
the new prototype. By the time
thirdphase begins, risks are known, and a somewhat more
traditional development approach is taken [RAKI97L
M The focus is the identification of problems and the classification of these into different
levels of risks,
the aim being to eliminate high-risk problems before they threaten the sottware
operation or cost.
An important feature of the spiral model is that each phase is completed with a review
bythe people oncerned with the project (designers and programmers).lhis reviewconsista of
areview of all the products developed up to that point and includes the plans for the next cycle.
These plans that
mayare
include a partition of the product in smaller portions for development or
components implemented by individual groups or persons.G the plan for the develop-.
ment fails, thenthe spiralis terminated therwise, it terminates with the initiation ofnew or
modified software.
 Cumulative cost

Progress
through
steps
Evaluate alternatives
icdetity, resolve riakss

Determine Risk analysis (RA)

objectives,
alternatives,
constraints
Risk analysis

Prototype 3 Operational
Risk analysis
ototype

Commitment
Proto
Prototype 1 ype 2
Partition Rats plan
lde cycle Concept of Simulations Models Benchmarks
plan 0peration
Software Software
rqts. product Detailed
Review Develop design design
ment plan Requirements
validation
Code
integration
and test
Design validation
and verification
Unit
test
Integration
and test
Plan
next phases Implemen Acceptance
tation test

Develop, verify
next-level product
V

Fig. 2.6: Spiral model

The advantage of this model is the wide range of options to
features of other accommodate the good
life cycle models.It becomes equivalent to another life
priate situations. It also incorporates software quality cycle modelin appro
The risk analysis and validation objectives into software development.
steps eliminate errors in the early phases of development.
The spiral model has some difficulties that need to
be resolved before it
sally applied life cycle model. These difficulties include lack of can be a univer
explicit process guidance in
determining objectives, constraints, alternatives;)relying on risk assessment expertise,
providing more flexibility than required for many applications. and

2.5 THE UNIFIED PROCESs 2

The unified process is described by I.
Jacobson, G. Booch and J. Rumbaugh in their bookThe
unified software development process" [JACO 98]. It is a software engineering process witn
the goal of
producing good quality maintainable software within specified time and budget.
The unified proces supports iterative development where
of short, fixed length project is developed througin &s ries
miniprojects called iterations. The outcome of each iteration is a testeu
integrated and executable system Bach iteration has its own requirements analysis, desig
 29
Cycle Models
Software Life

system continues to enlarge and

refine withh
implementation and testing activities. Hence, the known as
tim Thus, this approach also
is
thus grows incrementally over enhanced
every iteration and The unífied process is now maintaned
and
development.
iterativeand incremental thus also referred as Rational unified
process (RUP).
and
by Rational software corporation model) is not suitable
due to
we all know, sequential
approach (example waterfall
As Iterative approach is
and uncertainities in software development.
changing requirements and became the basis of unified process.
The process
definitely better than sequential approach the development process
how and when. The role of everyone in
also defines who is doing what,
is defined clearly and precisely.

Process
2.5.1 The Phases of the Unified 2.7. Each
and the life cycle ís shown in the Figure
There are four phases in the unified process to improve the quality of the
be reviewed, if required,
phase has a specific outcome which can
process.

Elaboration Construction Transtion

Inception
Time
Initial operational Release of the
Definition of Planning and
software product
objectives of architecture capability
the project for the project

2.7: The phases of unified process alongwith outcomes ater each phase
Fig.

() Inception: This phase is used to

definethe scope of the work. This is similar to
model. We define the requirements
requirements analysis and specification phase of waterfall and
using the requirements elicitation techniques. Thé customer developer interaction helps
are always changing but
us to capture and define the requirements Although, requirements

these change can be accomodated due to iterative nature of the process. The outcome of the
phase is cleár definition of the objectives of the/project.
(it) Elaboration: How do we plan and design the project ? What resources are required?
What type of architecture may be suitable ? These questions are answered in this phase. We
specify the features and prepare the baselihe of the architecture. This is similar to design
phase of waterfall model. The outcome is the planning and architecture documents of the
project
(u) Construction: The objectives are translated in design and architecture documents.
These documents are the inputs to construction phase and output is the product. We build and
test the product in this phase. The outcome of this phase is the deliverable product to the
Customer sometimes may be
and as beta treated release
(iu) Transition: Transitioning the product to the customers involves many activities
ike deivering,training, supporting, and maintaining the product. The ultimate objective is
the customer's satisfaction. The
phase activities may
continue customers are til the satisfied.
The outeome is the product releasé which also concludes the life cycle of unified process.
These four phases (Inception, Elaboration, Construction and Transition) constitute a
development cycle and produce a'software generation. In the first iteration i.e., initial develop-
ment cycle, first version of the software is produced. The software will be used by users. The
 Software Engineering
30 failure reports etc.
functionality,
may
feedback of the sers in terms of additional
The s a m e process
through ince otivate
inception,elaboration, construction
ction us
to work for second versio generation of the software n on and
to evolve the next ct. Tho
transition phases will repeat 2.8. With several evoluti
cyclesas shown infigure cycles,ofnew
Cycles are known asevolution produced. This process will continue upto the rots
generations of the product
are
tirement the
software product.
Version 1
Construction Transition
Inception Elaboration
Initial development cycle
Version 2
Inception Elaboration Construction Transition
Evolution cycle
Version 3
Inoepton Elaboration Construction Transition
Evalution cycle
Continue till
the product is
retired.

Fig. 2.8: initial development and evolution cycles

The phases are not of equal lengths. The length

fications and environment of the project. In each phase,
mayvary depending on the type, soeoi-
wé progress iteratively and each phase
may consist
o f one or several iterations as shown in Figure 2.9.

inception Elaboration
Constréction Transition

Tme

teration-1
Iterafion-2 Iteration-3 Iteá- Itera- Itera- lteration-7 lteration-8
tign-4| tion-5 tion-6

Interal
First extemal Final release
release
release (beta
release)
Fig. 2.9: Iterations within a phase
Each iteration follows a
contains the activities of
pattern which is similar to waterfall model. Hence, the work-flow
requirements elicitation and analysis, design, implementation ana
testing. However, from one
various activities will iteration
to the next and from
on phase to the next, the emphasi5
one
of activities over time change. Figure 2.10 shows the relative emphasis of the variouS ype
executed concurrently
[KRUC 99]. These activities are not
separated in time. Rather, they are
not much
code is written
throughout the lifetime of the
project. As we have seen in figure
éarly, in the .i
projected, most of the requirements areproject life cycle; but the amount is not zero. Late in u

the project matures, the known, but some new ones are still
emphasis on certain activities identified. Thus, a
are allowed to execute at any time increases or decreases, but
throughout the lifetime of the project acviu
[BO0C 98|.
 31
Software Life Cycle Models

elicitation and analysis.

dedicated to the requirements
The inception phase is primarily
carried out. The elaboration
of the work is defined and some planning work is also
The scope During
phase has thefocus on requirements with someemphasis on design andimplementation.
We produce first
focus is mostly on design and implementation.
the construction phase,
after this phase.
operational product The
The focus of transition phase training,installation and customer interaction.
is on We produce and deliver
feedback of helps us to improve and enhance the product.
customer
the final product here.
Phases

Inception Elaboration Construction ytansition

Core workflows

Requirements
elicitation and
analysis

Design

Implementation

Test
Iteration-1 lteration-2 terat-Itera- tera-ltera Itera
Priliminaryy iion-n tion-n ition-n ition-m tion-m+1
iteration/ +1 +2

Fig. 2.10: Iterations and workilow of unified process

2.5.2 Unified Process Work Products

All four pha_és produce different work products as per outecome of the phases. The
inception phase has the following objectives:
Gathering and analysing the requirements.
Planyíng and preparing a business case and evaluating alternatives for risk manage
ment, scheduling resources, ete.
stimatingg the overall cost and schedule for the project.
Studing the feasibility and calculating profitability of the project.
Many documents are prepared and are shown in Fig. 2.11.
 Software Engineering
32 Project plan
Prototype
Initial risk
assessment

Inception

Business Initial business

mode
Case

Initial project
Vision
document Initial use glossary
case model

of Inception phase
Fig. 2.11: The outconmes

The vision document's emphasis is on requirements and scope of the project. It give
overall ohjective and expectations from the project. Initial use case model
an idea about
use case diagram alongwith actors etc. It may also consist of use cases that can be identifed
at
this early stage.
Initial business case may include revenue model, market conditions, business difficnl

ties and financial forecast etc. Project plan document may include pnses and iterations for
thedevelopment of the project. Prototypes are very useful for the undefstanding of the project
(optional item). A business model may be required to provide ideg about "time to marke"
marketing strategies, cash flows andthresats.
The elaboration phase has the focus on the analysis of problem domain, establishes a
sound architectural foundation, develops project plans and eliminates the risk elements. Some
of the objectives and activities are:
Establishing architectural foundations
Design of use case model
Elaborating the process, infrastructure and development environment
Selecting component, if possiple, for the project
Demonstrating that architecture supportsthe vision at reasonable cost and with speci-
fied time.
The outcomes are given in Fig. 2.12.
A developmert
Revised risk
plan documen

Priliminary Elaboration An executable

user manual architectural
prototype

Use case Architecture

model description
Supplementary
requirements with
document
nonfunctional
requirements
Fig. 2.12: The outcomes of
elaboration phase
 Software Life Cycle Models 33

A use case model (at least 80% complete) is prepared. All use cases are identified
alongwith associated actors. Supplementary requirements document (with nonfunctional
requirements) and software architecture description document are also prepared. A prototyps
is also designed for the customer to give an idea about the final product. A development plan
with iterations, workflows etc. is also prepared. A preliminary user manual, although optional,
may also be prepared in this phase and will refine in the subsequent phases.
The construction phase produces the product for the customer. The objectives and
activities are:
Implementing the project
Minimising development cost
Managing and optimizing resources
.Testing the product
Assessing the product releases against acceptance criteria.
The outcome of this phase is a product ready to use for the customers and is shown in
Fig. 2.13.

Test outline
Operatioral manuais

Test suite
Documentation Construction
manuals

A description
of the current
Software release
product User
manualsS

Fig. 2.13: The oútcomes of construction phase

The outcomes are various operational and documentation manuals alongwith software
product. The test suite documents aré also preserved carefully because they are required during
the maintenance of the software product.
The transition phase lay[ focus on successful delivery and installation of the software
product. The phase includes the following:
Commencement 9f beta testing
Analysis of usey's views
Training of users
Tuning actiitiesinchuding bug fixing and enhancement for performance and usability
Assessing the customer satisfaction
The outcomes are given in Fig. 2.14.
 Software Engineering
34
Transttion

User
feedback
Product
release Beta test
reports

. Fig. 2.14: The outoomes of transition phase

due to its iterative and incremental nature.

The-unified process has many advantagés
can be ensured and learning
Changes can be accomodated, risks can minimised, reusability
be
the product that results from unified process
alongwith project evolution is possible. Hence, the quality of
will be of good quality. The system hasbeen tested several times, improving
related to the customer's
testing. The requirements have been péfined and are more closely
actual expectations.

SELECTION OF A LIFE CYCLE MODEL

26
The selection of suitable model is based on the following characteristics/categories
(i) Requirements
ii) Development team 1
(ii) Users
(iv) Project type and associated risk.

2.6.1 Characteristics of Requirements

There number
important for the selection of an appropriate model.
are
Requirements are very
and analysis. The details are given
of situations and problems during requirements capturing
in Table 2.1.
Table 2.1: Selection of a model based on characteristics of requirements

Requirements Waterfall PrototypeIterative EvolutionarySpiral| RAD

enhancement| develqpment

Are requirements easily Yes No No No No Yes

understandable and defined?

Do we change requirements No Yes No Np Yes No

uite often?

Can we define requiréments Yes No Yes Yes No es

early in the cycle?
Requirements are indicating No Yes Yes Yes Yes No
a complex system to be built
M Lxcpt
wanlad
 Software Life Cycle Models 35

2.6.2 Status of Development Team

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

Table 2.2: Selection based on status of development team

Development Waterfall| Prototype Iterative Evolutionary Spiral RAD

team enhancement develapment
Less experience on similar No Yes No No Yes No
projects e
Less domain knowledge Yes No Yes es Yes No
Do ewto the technolpg)
Less experience on todls to Yes No No No Yes No

be used Wlab ua
No No Yes Yes No Yes
Availability of training,
if required,udal
PALALUlie-nabaRAD

2.6.3 Involvement of Users

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

Table 2.3: Selection based on user's participation

Involvement Waterfall| Prototype Tterative Evoluttonary Spiral RAD

of users enhancement development
User involvement in all No
Yes No No NoYe
phages ustop 6m
KLimited user participation Yes No Yes. Yes Yes N
User have no previous No Yes Yes Yes Yes No
HwR experience of participation
in similar projects l Cabt Wodeal A
A Users are experts of No Yes Yes Yes No Ye
problem domain 1xubt lalula)4 Spos
2.6.4 Type of Project and Associated Risk
selection of
Very few models incorporate risk assessment. Project type is also important for the
a model. Some issues are discussed in Table
2.4.
 36 Software Engineering

Table 2.4: Selection based on type of project with associated risk

PFHTU8
Project type Waterfall| Prototype Iterative
Evolutidnary Spiral RAD
and risk enhancement development
LERI of
Project is the enhancement
the existing system
No No Yes Yes No Yos
wPRunding is stable for Yes Yes No
No No Yes
the project
High reliability lard No No Yes Yes Yes
requirements
ATight project schedule No Yes Yes Ye Yes Yes
G Use of reusable components No Yes No
Are
N Yes
Yes
resources (time, money No Yes No No Yes
Ps people etc.) scarce?

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

REFERENCES
[BASI75] Basili V.R., Iterative Enhancement: A Practical Technique for Software Development",
IEEE Trans on Software Engineering, SE-1, No. 4, 390-396, December 1975.
[BOEH86] Boehm B., A Spiral Model for Sofiuware Development and Enhancement', ACM Software
Engineering Notes, 14-24, August, 1986.
[BOOC98] Booch G. et. al., "Object Oriented Analysis and Design with Applications", 2nd ed., Addison
Wesley Longman Inc., 1998.
[JACO98] Jacobson I., Booch G. and Rumbaugh J., "The Unified Softuware Development Process",
Reading, MA : Addison Wesley Longmen, 1998.
[KRUC99] Kruchten P, "The Rational Unified Process-An Introduction", Addison Wesley Longman
Inc. 1999.
[RAKI971 Rakitin S.R, "Softuware Verification and Validation", Artech House Inc., Norwood, MA, /
1997.
ISCHA96J Schach S., Classical and Object Oriented Software Enginering", IRWIN, USA, 1996.
ITAKA96] Takang A.A. and Grubb P.A., "Software Maintenance-Concepts and Practice", Int. Thomson
Computer Press, Cambridge, U.K, 1996.
 37
Software Life Cycle Models

MULTIPLE CHOICE QUESTIONS

Note: Choose most appropriate answer of the following questions.
2.1. Spiral Model was developed by
(b) Berry Boehm
(a) Bev Littlewood
(d) Victor Basili.
(c) Roger Pressman
small projects?
2.2. Which model is most popular for student's
b) spiral model
(a) waterfall model
d) prototyping model.
(c) quick and fix model
software life cycle model?
2.3. Which is not a
(bspiral model
(a) waterfall model
(c) prototyping model (d) capability maturity model.
considered in
2.4. Project risk factor is
(b) prototyping model
(a) waterfall model

(c) spiral model (d) iterative enhancement model.

2.5. SDLC stands for
(a) software design life cycle
6) software development life cycle
(d) system design life cycle.
(c) system development life cycle
Build and fix model has
2.6.
(a) 3 phases (b) 1 phase

(c) 2 phases (d) 4 phases.

2.7. SRS Stands for
(a) software requirements specification 6) software requirements solutions
(c) system requirements specification (d) none of the above.

2.8. Waterfall model is not suitable for

(a) small projects 6) accomodating change
(c) complex projects (d) none of the above.
2.9. RAD stands for
(a) rapid application development (6) relative application development
(c) ready application development (d) repeated application development.
2.10. RAD model was proposed by
(a) Lucent Technologies (6) motorola

(c) IBM d) microsoft.

2.11. If requirements are easily understandable and defined, which model is best suited?

(a) waterfall model 6) prototyping model

(C)spiral model (d) none of the above.

2.12. If requirements are frequently changing, which model is to be selected
(a) waterfall (6) prototyping model
(c) RAD model (d) iterative enhancement model.
2.13. Ifuser participation is available, which model is to be chosen?
(a) waterfall model (6) iterative enhancement model

(c) spiral model (d)RAD model.