SOFTWARE DEVELOPMENT

LIFE CYCLE
LIFE CYCLE MODEL
A software life cycle model (also called process model) is a descriptive
and diagrammatic representation of the software life cycle. A life cycle
model represents all the activities required to make a software product
transit through its life cycle phases. It also captures the order in which
these activities are to be undertaken. In other words, a life cycle model
maps the different activities performed on a software product from its
inception to retirement. Different life cycle models may map the basic
development activities to phases in different ways. Thus, no matter
which life cycle model is followed, the basic activities are included in all
life cycle models though the activities may be carried out in different
orders in different life cycle models. During any life cycle phase, more
than one activity may also be carried out.
 THE NEED FOR A SOFTWARE LIFE CYCLE MODEL

The development team must identify a suitable life cycle model for the particular project and
then adhere to it. Without using of a particular life cycle model the development of a software
product would not be in a systematic and disciplined manner. When a software product is being
developed by a team there must be a clear understanding among team members about when
and what to do. Otherwise it would lead to chaos and project failure. This problem can be
illustrated by using an example.
Suppose a software development problem is divided into several parts and the 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, another might decide to prepare the test documents
first, and some other engineer might begin with the design phase of the parts assigned to him.
This would be one of the perfect recipes for project failure.
A software life cycle model defines entry and exit criteria for every phase. A phase can start only
if its phase-entry criteria have been satisfied. So without software life cycle model the entry and
exit criteria for a phase cannot be recognized. Without software life cycle models it becomes
difficult for software project managers to monitor the progress of the project.
SDLC Activities
• SDLC provides a series of steps to be followed to design and develop a
software product efficiently. SDLC framework includes the following
steps:
• Communication
This is the first step where the user initiates the request for a desired software product. He
contacts the service provider and tries to negotiate the terms. He submits his request to
the service providing organization in writing.

• Requirement Gathering
This step onwards the software development team works to carry on the project. The
team holds discussions with various stakeholders from problem domain and tries to bring
out as much information as possible on their requirements. The requirements are
contemplated and segregated into user requirements, system requirements and functional
requirements. The requirements are collected using a number of practices as given -
• studying the existing or obsolete system and software,
• conducting interviews of users and developers,
• referring to the database or
• collecting answers from the questionnaires.
• Feasibility Study
After requirement gathering, the team comes up with a rough plan of software
process. At this step the team analyzes if a software can be made to fulfill all
requirements of the user and if there is any possibility of software being no more
useful. It is found out, if the project is financially, practically and technologically
feasible for the organization to take up. There are many algorithms available, which
help the developers to conclude the feasibility of a software project.

• System Analysis
At this step the developers decide a roadmap of their plan and try to bring up the
best software model suitable for the project. System analysis includes
Understanding of software product limitations, learning system related problems
or changes to be done in existing systems beforehand, identifying and addressing
the impact of project on organization and personnel etc. The project team analyzes
the scope of the project and plans the schedule and resources accordingly.
• Software Design
Next step is to bring down whole knowledge of requirements and analysis
on the desk and design the software product. The inputs from users and
information gathered in requirement gathering phase are the inputs of this
step. The output of this step comes in the form of two designs; logical design
and physical design. Engineers produce meta-data and data dictionaries,
logical diagrams, data-flow diagrams and in some cases pseudo codes.

• Coding
This step is also known as programming phase. The implementation of
software design starts in terms of writing program code in the suitable
programming language and developing error-free executable programs
efficiently.
• Testing
An estimate says that 50% of whole software development process
should be tested. Errors may ruin the software from critical level to its
own removal. Software testing is done while coding by the developers
and thorough testing is conducted by testing experts at various levels of
code such as module testing, program testing, product testing, in-house
testing and testing the product at user’s end. Early discovery of errors
and their remedy is the key to reliable software.
• Integration
Software may need to be integrated with the libraries, databases and
other program(s). This stage of SDLC is involved in the integration of
software with outer world entities.
• Implementation
This means installing the software on user machines. At times, software needs post-installation
configurations at user end. Software is tested for portability and adaptability and integration
related issues are solved during implementation.

• Operation and Maintenance

• Disposition
As time elapses, the software may decline on the performance front. It may go completely
obsolete or may need intense upgradation. Hence a pressing need to eliminate a major portion of
the system arises. This phase includes archiving data and required software components, closing
down the system, planning disposition activity and terminating system at appropriate end-of-
system time.
Different software life cycle models
Many life cycle models have been proposed so far. Each of them has some
advantages as well as some disadvantages. A few important and commonly
used life cycle models are as follows:
• Classical Waterfall Model
• Iterative Waterfall Model
• Prototyping Model
• Evolutionary Model
• Spiral Model
• V – model
• Big Bang Model
Classical waterfall model
The classical waterfall model is intuitively the most obvious way to
develop software. Though the classical waterfall model is elegant and
intuitively obvious, it is not a practical model in the sense that it cannot
be used in actual software development projects.
Thus, this model can be considered to be a theoretical way of
developing software. But all other life cycle models are essentially
derived from the classical waterfall model. So, in order to be able to
appreciate other life cycle models it is necessary to learn the classical
waterfall model. Classical waterfall model divides the life cycle into the
following phases as shown in fig.:
Feasibility study - The main aim of feasibility study is to determine whether it would be
financially and technically feasible to develop the product.

• At first project managers or team leaders try to have a rough understanding of what is
required to be done by visiting the client side. They study different input data to the
system and output data to be produced by the system. They study what kind of
processing is needed to be done on these data and they look at the various constraints
on the behavior of the system.

• After they have an overall understanding of the problem they investigate the different
solutions that are possible. Then they examine each of the solutions in terms of what
kind of resources required, what would be the cost of development and what would be
the development time for each solution.

• Based on this analysis they pick the best solution and determine whether the solution
is feasible financially and technically. They check whether the customer budget would
meet the cost of the product and whether they have sufficient technical expertise in
the area of development.
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 them properly. This phase consists
of two distinct activities, namely
• Requirements gathering and analysis
• Requirements specification

• The goal of the requirements gathering activity is to collect all relevant information from the customer
regarding the product to be developed. This is done to clearly understand the customer requirements so
that incompleteness and inconsistencies are removed.
• The requirements analysis activity is begun by collecting all relevant data regarding the product to be
developed from the users of the product and from the customer through interviews and discussions. For
example, to perform the requirements analysis of a business accounting software required by an
organization, the analyst might interview all the accountants of the organization to ascertain their
requirements. The data collected from such a group of users usually contain several contradictions and
ambiguities, since each user typically has only a partial and incomplete view of the system. Therefore it is
necessary to identify all ambiguities and contradictions in the requirements and resolve them through
further discussions with the customer. After all ambiguities, inconsistencies, and incompleteness have
been resolved and all the requirements properly understood, the requirements specification activity can
start. During this activity, the user requirements are systematically organized into a Software
Requirements Specification (SRS) document. The customer requirements identified during the
requirements gathering and analysis activity are organized into a SRS document. The important
components of this document are functional requirements, the nonfunctional requirements, and the
goals of implementation.
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 distinctly different approaches are available: the traditional
design approach and the object-oriented design approach.
• Traditional design approach -Traditional design consists of two different
activities; first a 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 activity. During structured design, the
results of structured analysis are transformed into the software design.
• 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.
• Coding and unit testing:-The purpose of the coding phase (sometimes
called the implementation phase) of software development is to
translate the software design into source code. 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 tested.
During this phase, each module is unit tested to determine the correct
working of all the individual modules. It involves testing each module in
isolation as this is the most efficient way to debug the errors identified
at this stage.
Integration and system testing: -Integration of different modules is undertaken
once they have been coded and unit tested. During the integration and system
testing phase, the modules are integrated in a planned manner. The different
modules making up a software product are almost never integrated in one shot.
Integration is normally carried out incrementally over a number of steps. During
each integration step, the partially integrated system is tested and a set of
previously planned modules are added to it. Finally, when all the modules have
been successfully integrated and tested, system testing is carried out. The goal
of system testing is to ensure that the developed system conforms to its
requirements laid out in the SRS document. System testing usually consists of
three different kinds of testing activities:
• α – testing: It is the system testing performed by the development team.
• β –testing: It is the system testing performed by a friendly set of customers.
• Acceptance testing: It is the system testing performed by the customer
himself after the product delivery to determine whether to accept or reject
the delivered product.
Maintenance: -Maintenance of a typical software product requires much
more than the effort necessary to develop the product itself. Many studies
carried out in the past confirm this and indicate that the relative effort of
development of a typical software product to its maintenance effort is roughly
in the 40:60 ratios. Maintenance involves performing any one or more of the
following three kinds of activities:
• Correcting errors that were not discovered during the product development
phase. This is called corrective maintenance.
• Improving the implementation of the system, and enhancing the
functionalities of the system according to the customer’s requirements. This
is called perfective maintenance.
• 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. This is called adaptive maintenance.
Shortcomings of the classical waterfall
model
The classical waterfall model is an idealistic one since it assumes that no
development error is ever committed by the engineers during any of the life cycle
phases. However, in practical development environments, the engineers do commit
a large number of errors in almost every phase of the life cycle. The source of the
defects can be many: oversight, wrong assumptions, use of inappropriate
technology, communication gap among the project engineers, etc. These defects
usually get detected much later in the life cycle.
For example, a design defect might go unnoticed till we reach the coding or testing
phase. Once a defect is detected, the engineers need to go back to the phase where
the defect had occurred and redo some of the work done during that phase and the
subsequent phases to correct the defect and its effect on the later phases.
Therefore, in any practical software development work, it is not possible to strictly
follow the classical waterfall model.