Chapter 2

SOFTWARE LIFE CYCLE MODELS

The ultimate objective of software engineering is to produce good quality maintainable software within
reasonable time frame and at affordable cost. This is achievable only if we have matured processes to produce
it. For a mature process, it should be possible to determine in advance how much time and effort will be
required to produce the final product. This can only be done using data from past experience, which requires
that we must measure the software process.

Software development organizations follow some process when developing a software product. In immature
organizations, the process is usually not written down. In mature organizations, the process is in writing and is
actively managed. A key component of any software development process is the life cycle model on which
the process is based. The particular life cycle model can significant affect overall life cycle costs associated
with a software product. Life cycle of the software starts from concept exploration and ends at the
retirement of the software.

The software life cycle is: “The period of time that starts when a software product is conceived and ends when
the product is no longer available for use. The software life cycle typically includes a requirement phase,
design phase, implementation phase, test phase, installation and check out phase, operation and maintenance
phase, and sometimes retirement phase.”

A software life cycle model is a particular abstraction that represents a software life cycle. A software life cycle
model is often called a software development life cycle model (SDLC). Varieties of life cycle models have
been proposed and are based on tasks involved in developing and maintaining software.

2.1 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)

SDLC is a systematic process for building software that ensures the quality and correctness of the software
built. SDLC process aims to produce high-quality software that meets customer expectations. The system
development should be complete in the pre-defined time frame and cost. SDLC consists of a detailed plan
which explains how to plan, build, and maintain specific software. Every phase of the SDLC life Cycle has its
own process and deliverables that feed into the next phase. SDLC stands for Software Development Life Cycle
and is also referred to as the Application Development life-cycle.

Why SDLC?

Here, are prime reasons why SDLC is important for developing a software system.

 It offers a basis for project planning, scheduling, and estimating

1
  Provides a framework for a standard set of activities and deliverables
 It is a mechanism for project tracking and control
 Increases visibility of project planning to all involved stakeholders of the development process
 Increased and enhance development speed
 Improved client relations
 Helps you to decrease project risk and project management plan overhead

Thus SDLC consists of following steps during its life. They are:

1. Project identification 3. Analysis 6. Testing

and selection
4. Design of software 7. Implementation
2. Project initiation and
5. Coding 8. Maintenance
planning

Project identification
and selection

Project initiation and

planning

Analysis

System design

Coding

Testing

Implementation

Maintenance

2
Project identification and selection: This is the first phase in the SDLC. In this phase, someone identifies the
need for a new system or enhanced system.

When the request is made, the first process that takes place is being divided into three different parts. These
are:

 Request clarification

 Feasibility study

 Request approval

Request Clarification: Many requests from employees and users in the organization are not clearly defined.
Therefore, it becomes necessary that project request must be examined and clarified properly before
considering investigation.

Feasibility Study: An importance outcome of preliminary investigation is the determination that system
request is feasible. There are three aspects in this portion. They are:

o Technical feasibility

o Economic feasibility

o Operational feasibility

Request Approval: It is not necessary that all requested projects are desirable or feasible. However, those
projects that are feasible and desirable should be put into a schedule. After a project request is approved, its
cost, priorities, completion time and personal requirements are estimated which is used for initiation of
development.

Project initiation and planning: This is the second phase of SDLC. The two major activities in this phase are the
formal investigation of the system problem and the presentation of reasons why the system should or should
not be developed by the organization. A critical step at this point is determining the scope of the proposed
system. The project leader and initial team of system analysts also produce a specific plan, which the team will
follow along with the SDLC steps. We can say that this phase of SDLC recognizes the potential of project and
gives a detailed plan for conducting the remaining phases of the SDLC for the proposed system.

Requirement Analysis: Requirement analysis is done in order to understand the problem the software system
is to solve. The emphasis in requirements analysis is on identifying what is needed from system, not how the
system will achieve its goals. This task is complicated by the fact that there are often at least two parties
involved in software development-a client and a developer. The developer has to develop the system to satisfy
the client’s needs. The developer usually does not understand the client’s problem, and the client often does
not understand the issues involved in software systems. This causes a communication gap, which has to be
adequately bridged during requirements analysis.

In most software projects, the requirements phase ends with a document describing all the requirements. In
other words, the goal of the requirements specification phase is to produce the software requirements

3
specification document (also called the requirements document). The person responsible for the requirements
analysis is often called the analyst.

Software Design: The purpose of the design phase is to plan a solution of the problem specified by the
requirements document. This phase is the first step in moving from the problem domain to the solution
domain. In other words, starting with what is needed; design takes us towards how to satisfy the needs. The
design of a system is perhaps the most critical factor affecting the quality of the software; it has a major
impact on the later phases, particularly testing and maintenance. The output of this phase is the design
document. This document is similar to a blueprint or plan for the solution and is used later during
implementation, testing, and maintenance.

The design activity is often divided into two separate phases-system design and detailed design. System
design, which is sometimes also called top-level design, aims to identify the modules that should be in system,
the specifications of these modules, and how they interact with each other to produce the desired results.

During detailed design, the internal logic of each of the modules specified in system design is decided. During
this phase further details of the data structures and algorithmic of each of the modules is specified.

Coding: Once the design is complete, most of the major decisions about the system have been made.
However, many of the details about the coding the designs, which often depend on the programming
language chosen, are not specified during design. The goal of the coding phase is to translate the design of
the system into code in a given programming language.

The coding phase affects both testing and maintenance profoundly. Well-written code can reduce the testing
and maintenance effort. Because the testing and maintenance costs of software are much higher than coding
cost, the goal of coding should be to reduce the testing and maintenance effort.

An important concept that helps the understandability of programs is structured programming. The goal of
structured programming is to initialize the control flow in the program. That is, the program text should be
organized as a sequence of statements and during execution the statements are executed in the sequence
given in the program.

Testing: Testing is the major quality control measure used during software development. Its basic function is
to detect errors in the software. During requirements analysis and design, the output is a document that is
usually textual and non-executable. After the coding phase, computer programs are available that can be
executed for testing purposes. The goal of the testing to uncover requirement, design, and coding errors in the
programs. Consequently, different levels of testing are used.

Testing is an extremely critical and time consuming activity. It requires proper planning of the overall testing
process.

Implementation: during the final testing, user acceptance is tested, followed by user training. Depending on
the nature of the system, extensive user training may be required. Conversion usually takes place at about the
same time the user is being trained or later. In most conversions a parallel run is conducted where the new
system runs simultaneously with the old system. This method, though costly, provides added assurance
against errors in the candidate system and also gives the user staff an opportunity to gain experience through

4
operation. In some cases, however, parallel processing is not practical. After the candidate system proves
itself, the old system is phased out. There are three types of implementation.

1. Implementation of a computer system to replace a manual system.

2. Implementation of new computer system to replace an existing one.

3. Implementation of a modified application (software) to replace an existing one using the same
computer.

Maintenance: Software maintenance is the enigma of system development. Analysts and programmers
spend far more time maintaining programs than do writing them. Maintenance accounts for 50-80 percent
of total system development. Software maintenance traditionally denotes the process of modifying a
software product after it has been delivered to the customer. Most products need maintenance due to
wear and tear caused by use. On the other hand software product does not “wear out” but need
maintenance on account of the following three main reasons:

1. To rectify some errors observed while the system is in use.

2. To change the program function to interface with new hardware or software.

3. To enhance the performance or modifying the programs according to customer demands.

2.2 SOFTWARE LIFE CYCLE MODELS

A software life cycle model is a particular abstraction that represents a software development life cycle.
Varieties of life cycle models have been proposed and are based on tasks involved in developing and
maintaining software. Selection of model depends largely on the nature of the project, the type of application,
the tools proposed to be used and the kind of controls and documentation that would be required.

2.3 BUILD AND FIX MODEL

Sometimes a product is constructed without specifications or any attempt at design. Instead, the developer
simply builds a product that is reworked as many times as necessary to satisfy the client.

This is an ad-hoc approach and not well defined. Basically, it is simple two phase model. The first phase is to
write code and the next phase is to fix as shown in fig. 2.1. Fixing in this context may be error correction or
addition of further functionality.

5
 Fig.2.1: Build and fix model

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

2.4 WATERFALL MODEL

The most familiar model is the waterfall model. This model has six phases:

1. Requirement analysis and specification

2. Design

3. Coding and unit testing

4. Integration and system testing

5. Implementation

6. Operation and maintenance

The phases always occur in this order and do not overlap. The developer must complete each phase before
the next phase begins. This model is named “Waterfall Model”, because its diagrammatic representation
resembles a cascade of waterfalls.

Requirement analysis
and specification

Design

Coding & Unit testing

Integration and System

Testing

Implementation

Operation
&Maintenance
6
 1. Requirement analysis and specification phase: The goal of this phase is to understand the exact
requirements of the customer and to document them properly. This activity is usually executed
together with the customer, as the goal is to document all functions, performance and interfacing
requirements for the software. The requirements describe the “what” of a system not the “how”. This
phase produces a large document, written in natural language, contains a description of what the
system will do without describing how it will be done. The resultant document is known as software
requirement specification (SRS) document.

2. Design phase: The SRS document is produced in the previous phase, which contains the exact
requirements of the customer. The goal of this phase is to transform the requirements specification
into a structure that is suitable for implementation in some programing 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 description (SDD) document. The information contained
in the SDD should be sufficient to begin the coding phase.

3. Coding and Unit testing: During this phase coding proceeds smoothly because all the information
needed by the software development is contained in the SDD. The main purpose of this phase of
waterfall model is to translate the software design into source code. The end product of this phase is
a set of program modules. Unit testing i.e; testing of each individual module. The purpose of unit
testing is to determine the correct working of the individual modules.

4. Integration and system testing: This is very important phase. Effective testing will contribute to the
delivery of higher quality software products, more satisfied users, lower maintenance costs and more
accurate and reliable results.

During this phase individual program units or programs are integrated and tested as a complete system
to ensure that software requirements have been met. After system testing, the software is delivered to
the customer.

5. Implementation: This is the process in which the developed system is handed over to the client.

6. Operation and maintenance: Software maintenance is a task that every development group has to
face, when the software is delivered to the customer’s site, installed and is made operational.
Therefore, release of software inaugurates the operation and maintenance phase of the life cycle. The
time spent and effort required to keep the software operational after release is very significant.
Despite the fact that it is a very important and challenging phase.

Advantages of Waterfall Model:

1. The waterfall model is the oldest and the most widely used paradigm for software engineering.

2. This model provides a systematic and sequential approach to software development.

3. It is very useful where the requirements are well understood.

Disadvantage of Waterfall Model:

7
 1. This process model insists on a complete set of user requirements before commencement of design. It
is often difficult for the customer to state all requirements explicitly.

2. It does not incorporate any kind of risk assessment.

3. Working software is not available until late in process.

4. Neither user nor management can see how good or bad the system is until it comes in.

5. It is necessary to gather all the knowledge necessary for planning the entire project in the beginning.

2.4 INCREMENT PROCESS MODELS

Increment process models are effective in the situations where requirements are defined precisely and
there is no confusion about the functionality of 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 delivered 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 particularly when we have to quickly deliver a limited
functionality system.

2.4.1 ITERATIVE ENCHANCEMENT MODEL

This model has the same phases as the waterfall models, but with fewer restrictions. Generally the phases
occur in the same order as in the waterfall model, but these may be conducted in several cycles. A useable
product is released at the end of each cycle, with each release providing additional functionality.
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.
Developers implement the specific requirements in one or more cycles of design, implementation and test
based on the defined priorities. The model is given in Fig. 2.4.

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

Requirements Design Implementation Integration & Operation

8
testing unit System (Install)
Testing
 Release I

Design Implementation Integration & Operation

testing unit System (Install)
Testing
Release II

Design Implementation Integration & Operation

testing unit System (Install)
Testing
Release III
Fig.2.4: Iterative enhancement model

2.4.2 RAPID APPLICATION DEVELOPMENT (RAD) MODEL

This model is an incremental process model and was developed by IBM in the 1980s and described in the book
of James Martin entitled “Rapid Application Development “. Here, user involvement is essential from
requirement phase to delivery of the product. The continuous user participation ensures the involvement of
user’s expectation and perspective in requirements elicitation, analysis and design of the system.
The process is started with building a rapid prototype and is given user for evaluation. The user feedback is
obtained and prototype is refined. The process continues, till the requirements are finalized. We may use any
grouping technique (Like FAST, QFD, Brainstorming Session) for requirements elicitation. Software
requirement and specification (SRS) and design documents are prepared with the association of users.
There are four phases in this model and these are shown in Fig. 2.5.
With active participation of users

Requirements User description Construction Cut Over

planning

Fig. 2.5: RAD Model

(i) Requirements planning phase: Requirements are captured using any group elicitation techniques.
Only issue is the active involvement of users for understanding the project.
(ii) User description: Joint teams of developer and users are constituted to prepare, understand and
review the requirements. The team may use automated tools to capture information from the other
users.
(iii) Construction Phase: This phase combines the detailed design, coding and testing phase of waterfall
model. Here, we release the product to customer. It is expected to use code generators, screen
generators and other types of productivity tools.

9
 (iv) Cut over phase: This phase incorporates acceptance testing by the users, installation of the system,
and user training.
In this model, quick initial views about the products are possible due to delivery of rapid prototype. The
development time of the product may be reduced due to use of powerful development tools. It may use
CASE tools and frameworks to increase productivity. Involvement of user may increase the acceptability of
the product.

If user cannot be involved throughout the life cycle, this may not be an appropriate model. Development time
may not be reduced very significantly, if reusable components are not available. Highly specialized and skilled
developers are expected and such developers may not be available very easily. It may not be effective, if system
cannot be properly modularized.

2.5 EVOLUTIONARY PROCESS MODEL

Evolutionary process model reassemble iterative enhancement model. The same phases as defined for the
waterfall model occur here in a cyclical fashion. This model differs from iterative enhancement model in the
sense that this does not require a useable product at the end of each cycle. In evolutionary development,
requirements are implemented by category rather than by priority.
For example, in a simple database application, one cycle might implement the graphical user Interface (GUI);
another file manipulation; another queries; 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 interactive enhancement model would start by developing a very simplistic, but usable database.
On the completion of each cycle, the system would become more sophisticated. It would, however, provide all
the critical functionality by the end of the first cycle. Evolutionary development and iterative enhancement are
somewhat interchangeable. Evolutionary development should be used when it is not necessary to provide a
minimal version of the system quickly.
These models are useful for projects using new technology that is not well understood. This is also used for
complex projects where all functionality must be delivered at one time, but the requirements are unstable or not
well understood at the beginning.

2.5.1 PROTOTYPING MODEL

A disadvantage of waterfall model is that the working software is not available until late in the process, thus
delaying the discovery of serious errors. An alternative to this is to first develop a working prototype of the
software instead of developing the actual software. The working prototype is developed as per current
available requirements.

10
The developers use this prototype to refine the requirements and prepare the final specification document.
Because the working prototype has been evaluated by the customer, it is reasonable to expect that the
resulting specification document will be correct. When the prototype is created, it is reviewed by the
customer. Typically this review gives feedback to the developers that help to remove uncertainties in the
requirements of the software, and starts an iteration of refinement in order to clarify requirements.

Requirements

Refinement of
Quick design requirements as per
suggestions

Impalement

Customer Evaluation Not accepted by user

Accepted by customer
Design

Implementation & Unit testing

Integration & System testing

Operation & Maintenance

Fig.: Prototyping model

The prototype may be a usable program, but is not suitable as the final software product. The reason may be
poor performance, maintainability or overall quality. The code for the prototype is thrown away; however the
experience gathered from developing the prototype helps in developing the actual system.

After the finalization of software requirement and specification (SRS) document, the prototype is discarded
and actual system is then developed using the waterfall approach.

2.5.2 SPIRAL MODEL

Spiral model is one of the most important Software Development Life Cycle models, which provides support
for Risk Handling. In its diagrammatic representation, it looks like a spiral with many loops. The exact number
of loops of the spiral is unknown and can vary from project to project. Each loop of the spiral is called a Phase
of the software development process. The exact number of phases needed to develop the product can be
varied by the project manager depending upon the project risks. As the project manager dynamically
determines the number of phases, so the project manager has an important role to develop a product using
the spiral model.
11
The Radius of the spiral at any point represents the expenses (cost) of the project so far, and the angular
dimension represents the progress made so far in the current phase.

The below diagram shows the different phases of the Spiral Model: –

Each phase of the Spiral Model is divided into four quadrants as shown in the above figure. The functions of
these four quadrants are discussed below-

1. Objectives determination and identify alternative solutions: Requirements are gathered from the
customers and the objectives are identified, elaborated, and analyzed at the start of every phase. Then
alternative solutions possible for the phase are proposed in this quadrant.
2. Identify and resolve Risks: During the second quadrant, all the possible solutions are evaluated to
select the best possible solution. Then the risks associated with that solution are identified and the
risks are resolved using the best possible strategy. At the end of this quadrant, the Prototype is built
for the best possible solution.
3. Develop next version of the Product: During the third quadrant, the identified features are developed
and verified through testing. At the end of the third quadrant, the next version of the software is
available.
4. Review and plan for the next Phase: In the fourth quadrant, the Customers evaluate the so far
developed version of the software. In the end, planning for the next phase is started.

Risk Handling in Spiral Model

A risk is any adverse situation that might affect the successful completion of a software project. The most
important feature of the spiral model is handling these unknown risks after the project has started. Such risk
resolutions are easier done by developing a prototype. The spiral model supports copying up with risks by
providing the scope to build a prototype at every phase of the software development.

The Prototyping Model also supports risk handling, but the risks must be identified completely before the
start of the development work of the project. But in real life project risk may occur after the development
work starts, in that case, we cannot use the Prototyping Model. In each phase of the Spiral Model, the

12
features of the product dated and analyzed, and the risks at that point in time are identified and are resolved
through prototyping. Thus, this model is much more flexible compared to other SDLC models.

Advantages of Spiral Model:

Below are some advantages of the Spiral Model.

1. Risk Handling: The projects with many unknown risks that occur as the development proceeds, in that
case, Spiral Model is the best development model to follow due to the risk analysis and risk handling at
every phase.
2. Good for large projects: It is recommended to use the Spiral Model in large and complex projects.
3. Flexibility in Requirements: Change requests in the Requirements at later phase can be incorporated
accurately by using this model.
4. Customer Satisfaction: Customer can see the development of the product at the early phase of the
software development and thus, they habituated with the system by using it before completion of the
total product.

Disadvantages of Spiral Model:

Below are some main disadvantages of the spiral model.

1. Complex: The Spiral Model is much more complex than other SDLC models.
2. Expensive: Spiral Model is not suitable for small projects as it is expensive.
3. Too much dependability on Risk Analysis: The successful completion of the project is very much
dependent on Risk Analysis. Without very highly experienced experts, it is going to be a failure to
develop a project using this model.
4. Difficulty in time management: As the number of phases is unknown at the start of the project, so
time estimation is very difficult.

13