California Software Company

E l n e t S o f t w a r e C i t y, Ta r a m a n i ,
Chennai-600 113.

Life Cycle Models Selection Guidelines

Page 1 of 18
1. Objective

The objective of this guideline is to describe various and most commonly used process
models used in software development with the advantages, disadvantages and guidelines
for selection and assist user to select a particular model depending upon the requirements
of the project.

2. Life Cycle Models

Life cycle models describe the interrelationships between software development phases.

1.1 Definition

A description of the relationships between project phases, including: transition criteria,

feedback mechanisms, milestones, baselines, reviews, and deliverables.

Some most common lifecycle models are

a. Waterfall model
b. Modified waterfall model

c. Incremental/iterative development

d. Prototyping model (the Saw tooth and Shark Tooth Models):

e. Spiral model

f. 'V' model

g. The Reuse Model

h. Exploratory Model

i. Combining and Creating Models

Typically, a life cycle model addresses the following phases of a software project:

Requirements phase
Design phase

Page 2 of 18
 Construction

Testing

Operations and maintenance

Page 3 of 18
 a. Waterfall Model:

The Waterfall life cycle model is the most commonly used model for software
development. It emphasizes that software is developed in sequential phases e.g.
Requirement analysis, design, code, etc. with established milestones, documents, and
reviews at the end of each phase.

There is no overlap of each phases i.e., design can't begin until analysis is completed
and the entire scope of the project is addressed at each phase.

Review and Baseline the requirement document before the design phase.

Review and Baseline the design document before the coding phase.

Review and Baseline the code before the Testing phase.

Review and Baseline the Test Plans before the testing phase.

The waterfall model is represented as follows.

Page 4 of 18
 b. Modified Waterfall Model:

Modified waterfall model is a subset of Waterfall model. The difference between

waterfall model and modified waterfall model is that the software development is not
strictly sequential.

There can be overlapping of phases e.g if one module of the requirement phase is base-
lined then design phase of that particular phase can start. This applies to all the phases.

Advantages:

Requirements are stable

Customers know what they want

Customers will commit

Technology/methodology is well understood

Problem is complex but well-understood

Page 5 of 18
Disadvantages:

Requirements must be fully-specified up front [Does not allow for feedback loops]

Difficult to follow the phases strictly as required by the model

Visibility & control may be poor without careful selection of project milestones

Product not delivered until the end

Guidelines for Selection:

This model is highly suitable for under the following conditions

When requirements are stable

Time flexibility to proceed sequentially

Risk implications are less

Architecture for implementation is well understood

c. Iterative / Incremental Model

In this model, the project is fragmented into smaller components. Each one of these
components is a regular waterfall model. By repeating it a certain number of times, this
model allows for successive refinements of requirements, design and coding.

This model addresses the difficulties posed by the waterfall model but also has a number
of weaknesses.

Iterative development is a very simple concept. Instead of showing up at the end of the
project with a completed system in one giant 'chunk', we schedule deliverables in small
pieces throughout the project life cycle. We get the chance to take customers input at
each step and improve the overall project outcome.

Advantages

Critical risks are resolved before making large investments

Initial iterations enable early user feedback

We can schedule and manage the smaller pieces of work more efficiently

Testing and integration are continuous

Page 6 of 18
 Provides the opportunity to test the project in small pieces to
ensure higher quality

Objective milestones provide short-term focus

Progress is measured by assessing implementations

Partial implementations can be deployedIn the case of rescheduling needs, it is

much easier to move small pieces of the implementation instead of the whole
project.

Regularly scheduled deliverables gives comfort level.

Customer is kept in the 'loop' throughout the entire project.

Disadvantages:

Requires excellent project communication and coordination.

Requires a very efficient change control mechanism.

There is also a chance that clients will increase their demands after each release,
especially towards the end of the project.

Guidelines for Selection

This model can be selected the following conditions

Product Development projects

Useful when sufficient staffing is not available.

This model can be selected to manage technical risks in the project e.g a major
system might require the availability of new hardware that is under development
whose delivery date is uncertain. Increments can be planned in way that avoids
use of this hardware.

Page 7 of 18
 Core of the application to be developed is well understood and
the increments can easily be defined

2. Prototyping Model - (the Saw tooth and Shark Tooth Models):

Prototyping is a model that addresses the fact that requirements are very seldom fully
known at the beginning of a project. The main theme is to build a first, simplified
version of the system and seek feedback from the different groups of People involved
in order to come up with a second, better system. This is repeated until the system
meets the clients' conditions of acceptance.

There are variations on the theme of prototyping that can be exploited to enhance the
probability of project success. For example, a development team may consider the
following approaches:

Creating the user interface without the actual data processing part of the system.
This gives everyone the opportunity to understand the project better in the early
stage. In fact, 80 to 90 percent of any business system code goes to the user
interface.
Creating only one or a few subsystems with their respective functionality
implemented.

Using an existing system to demonstrate the components that will be implemented.

The following steps comprise the prototyping model:

Page 8 of 18
 Requirements: Collection of available requirements at the time.
Design: Once the initial layer of requirements information is
collected, it is integrated into a new or existing design to form a prototype.

Prototype Creation/Modification: Design is used to create a prototype of the

system. This may mean creating a prototype or modifying one.

Assessment: The prototype is presented to the customer for review. Comments

and suggestions are recorded from the customer.

Prototype Refinement: Information gathered from the customer is integrated into

the prototype to refine it.

Systems Implementation: In most cases, the system is rewritten once

requirements are understood.

Advantages:

Improved user communication.

Users like it.

Low risk.

Avoids over design.

Page 9 of 18
 Allows experimentation/innovation.

Spreads labor to user department.

Disadvantages:

Prototyping may lead to false expectations [This is a situation created by the

customer thinking the system is ready to roll out. The customer does not see the
work that has to be done internally such as database normalization and the like.]
Prototyping can lead to poor system design

Resist pressure to extend a rough prototype into a production product.

Cost of Prototype generation.

Page 10 of 18
Guidelines for selection:

This model will be selected for projects under following conditions

When detailed requirements specification is not possible / not clear

More suitable to develop systems which meets the immediate needs of the
customer

More suitable to the development of relatively small systems.

This model is generally used in projects where the technology is new and
requirements are evolving.

This model is used mostly for the development of systems related projects

d. Spiral Model:

The spiral model is a combination of the best features of both the waterfall model and
prototyping. Risk assessment is an added feature to the spiral model. Similar to the
prototyping model, an initial version of the system is developed and then repetitively
modified based on input received from client evaluations. Unlike the prototyping model,
however, the development of each version of the system is carefully designed using the
steps involved in the waterfall model. With each iteration around the spiral, more
complete versions of the system are built.

The risk assessment tasks are there to evaluate whether development should go on or not.
Thus, cost to completion and schedules are revised each time risk assessment is
performed. Based on the output, we may decide to cancel the project if returns cannot be
expected anymore.

The steps of the spiral model are:

Project Objectives: Objectives are determined and alternate approaches are

devised and weighed.
Risk Assessment: Possible alternatives are evaluated in face of the identified
risks. A decision is made as to go on with development and if so, the alternative
that should be chosen is identified.

Engineering: Requirements are put together and the system is developed.

Planning and Management: The customer is given an opportunity to evaluate

the version of the software and provide feedback to engineering.

Page 11 of 18
 The problems posed by this model can be serious. Delays in production of a system
can be serious given the many steps involved in each iteration in the spiral. Also, like
the other models, it cannot claim to be general. This is not a model to use for
developing software that does not involve major risks.

Advantages:

Application domain ranged from non real time administrative tools to distributed
real time ground systems to embedded systems.
Spiral model is a realistic approach to the large scale systems, Embedded Systems
and software projects

Identifies, evaluates and reduces risks

Puts useful software into the hands of users

Valuable feedback provided by production

Use of prototypes

Some critical success factors are

o Risk must be managed

o The culture must be trusting

o Stakeholders must be involved

o The technology must be ready

o Requirements must be flexible

Disadvantages:

Management must be convinced that long evolution can be controlled

If risks are not identified early, affects development.

This model requires considerable risk assessment expertise and relies on this
expertise for success.

Selection Guidelines:

Page 12 of 18
This model can be selected for high-risk projects and to the large
scale system and software.

e. ' V ' Model:

Another variant of the waterfall model -- the V-model -- associates each development
activity with a test or validation at the same level of abstraction. Each development
activity builds a more detailed model of the system than the one before it, and each
validation tests a higher abstraction than its predecessor.

Page 13 of 18
Difference between V Model and Waterfall model

Acceptance Test plan is prepared after the requirements stage

System test plan is developed after system specification and High level design
stage

Integration Test plan is prepared after the High level design and Low Level design

Advantages:

Verification activity at the end of each phase

Baselined deliverable at the end of each phase.

Page 14 of 18
 Critical applications will benefit from the rigid process and
extensive review.

Disadvantages:

Not suited for projects where requirements are not stable.

Incorporation of changes late in the project life cycle are expensive

Selection Guidelines:

Following are the guidelines for the selection of this model

When the requirements are stable and there is a very less chance of change in
requirement.
When the application is a critical application and needs a rigid process and
extensive review

Well suited for environments where requirement are well understood

f. The Reuse Model:

The idea motivating the reuse model is that a system should be built from existing
components. This is suited for Object-Oriented development because, in such
programming languages, we can define objects that can be exported, reused and
modified.

This model implies that a repository for components exists and that additions to it are
made each time possible. Building a system in this fashion involves getting
components from the repository if they exist, making them fit together. If they don't
exist, the engineer will build it and add it to the repository for future use.

The Reuse model consists of the following steps

Definition of Requirements. Initial system requirements are collected. These

requirements are usually a subset of complete system requirements.
Definition of Objects. The objects, which can support the necessary system
components, are identified.

Collection of Objects. The system libraries are scanned to determine whether or

not the needed objects are available. Copies of the needed objects are downloaded
from the system.

Creation of Customized Objects. Objects that have been identified as needed,

but that are not available in the library are created.

Page 15 of 18
 Prototype Assembly. A prototype version of the system is
created and/or modified using the necessary objects.

Prototype Evaluation. The prototype is evaluated to determine if it adequately

addresses customer needs and requirements.

Requirements Refinement. Requirements are further refined as a more detailed

version of the prototype is created.

Objects Refinement. Objects are refined to reflect the changes in the

requirements

Advantages

Less cycle time and hence more profitable

Less resource requirements

Easy to assemble modular components written in a general way

Code that has been used before (debugged) is a lot more stable than fresh code.

Encourages development and maintenance of reusable components repository

Disadvantages:

Limited to Object-Oriented development environments.

Writing general modules and components requires more effort than writing
special-purpose ones.

Selection Guidelines:

Highly suitable for Object Oriented projects and open source solutions

g. Exploratory Model

Sometimes, it is very difficult to identify what the requirements are. In this case, we may
have to build a set of requirements with what is readily available. Assumptions are made
on how the system might work and further insights and suggestions are iteratively
combined to create a usable system. A typical characteristic of this model is that
validation is based on end results and not on the respect of initial requirements.

The following steps constitute the exploratory model:

Page 16 of 18
Initial Specification Development: This is done with the available
information only. No time is devoted to researching other specifications
than those readily available. This provides a rudimentary starting point.

System Construction/Modification: The system is created or modified according to

available information such as new ideas, heuristics and hypotheses.

System Test: The system is tested and ideas on how to make it better are gathered.

System Implementation: After n iterations, satisfactory results are obtained and a final
implementation is produced.

Advantages:

Extremely simple in its construction

Page 17 of 18
Disadvantages:

Limited to very high level languages that allow for rapid development such as
Prolog or LISP,
Its cost effectiveness is not predictable

Often yields inefficient or crudely designed systems, as a result of the trial and
error way of constructing software.

Non availability of precise specification

Validation is based on the end result not on its adherence to pre-conceived

requirements

Selection guidelines

This model can be selected for projects of theoretical areas like artificial intelligent

Combining and Creating Models

A process model is meant to support systems development, not the other way around.
Hence, we must be able to choose to combine the elements of these canonical models
that best fit our needs. In addition, when circumstances change beyond the limits of
the model, its results are no longer predictable.

The selection of an appropriate model hinges primarily on two factors. These are:

Organizational environment
Nature of the application to build

The organizational environment determines with what ease we can implement a particular
model and the nature of the application will call for a certain number of activities to take
place, partly determining the model to choose or to borrow from.

Page 18 of 18