Study Material for Management Information System (MIS) BBAN-402

Chapter 8

Software Development Life Cycle

Important Points

• A software life cycle is a series of identifiable stages that a software product undergoes during its lifetime. Each stage is
called a Life Cycle Phase.
• A Software Development Life Cycle (SDLC) Model is a descriptive and diagrammatic representation of a software life
cycle.
• A life cycle model represents all the activities required to make a software product transit through its life cycle phases.
• It captures the order in which these activities are to be undertaken.
• Software Life Cycle Model is also called Software Process Model, since the software development activities are some
sequence of well-defined steps (like manufacturing process of a product).

Advantages of Software Development Life Cycle Model

1) The primary advantage to a life cycle model is that it encourages development of a software in a systematic and disciplined
manner . For example, when a program is developed by a single programmer, he has the freedom to decide the exact steps
through which he will develop the program. However, when a software product is developed by a team, it is necessary to
have a precise understanding among the team members as when and what to do, otherwise , it may lead to chaos and
software development project failure.
2) A SDLC model identifies the different phases in the life cycle of a software product by grouping the similar software
development activities into a phase of life cycle. Each phase can only begin only when the corresponding phase-entry
criteria are satisfied. Similarly, a phase can be considered to be complete only when the corresponding exit criteria is
satisfied.

Classical Waterfall Model

It is the theoretical and fundamental model of any software development life cycle. It divides the software development life
cycle into six phases. The name of the model is justified by its diagrammatic representation which resembles a cascade of
waterfalls.

Figure 1: Classical Waterfall SDLC Model

Page | 1
Chapter 8 – Software Development Life Cycle

Phases of Waterfall Model

1. Feasibility Study

The main aim of the feasibility study phase is to determine whether it would be financially and technically
feasible to develop the software product. This phase activities involves the analysis of the problem and collection of all
relevant information relating to the software product such as the different data items which would be inputted to the sys tem,
the processing required to be carried out on these inputted data, the output data required to be produced by the software.

The collected data are analyzed to arrive at the following:

a) An abstract problem definition

b) Formulation of the different solution strategies
c) Analysis of alternative solution strategies to compare their benefits and shortcomings.

This analysis usually requires to make approximate estimates of resources required, cost of development and development time
following each solution strategies.

2. Requirement Analysis & Specification

The aim of this phase is to understand the exact requirements of the customers and to document them properly.

This phase consists of two distinct subphase activities namely,

a) Requirement Gathering and Analysis – The goal of this subphase is to collect all relevant information from the
customer regarding the software product to be developed with a view to clearly understand the customer’s requirements
and eliminating the incompleteness and inconsistency in the requirements. It is done by interviews and discussions with
the customers and end user.

Note: Software customers and users are different. For example, the customer may be an organization and user can be an
employee of the organization.

b) Requirement Specification – The customer requirements identified during the previous subphase are organized into
a Software Requirement Specification Document (SRS). The important components of the SRS document are:
i. Functional Requirement – what the software will do?
ii. Non-functional Requirement – like environment, user type, etc.
iii. Goals of Implementation

3. Design

The aim of this phase is to transform the SRS document into a structure that is suitable for implementation in some programming
language.

In technical terms, the software architecture is derived from the SRS document.

Two distinct design approaches (subphases) are used:

i. Traditional Design Approach

a. Structured Analysis – It is carried out on SRS document, where the detailed structure of the problem is
examined. Data Flow Diagrams (DFD) are used to perform the structured analysis and to document the
result. During the structured analysis, the functional requirements in the SRS document are decomposed into
subfunctions and the data flow among the subfunctions are analyzed ad represented diagrammatically in the
form of DFDs.

Page | 2
 Study Material for Management Information System (MIS) BBAN-402

b. Structured Design – the results of structured analysis are transformed into software design. It consists of
two activities
i. Architectural Design (High Level Design) – involves decomposing the software system into modules
and representing the interfaces and establishing relationship among the modules.
ii. Detailed Design (Low Level Design) – involves designing the internal components of each modules in
greater details i.e. the data structure and algorithms of the modules are designed and documented.
ii. Objected Orient Design (OOD) Approach – Here the requirement components of the SRS document are treated
as individual object and using the concept of real-world object behavior and representation, the designing the
software is done.

4. Coding & Unit Testing

The purpose of this phase is to translate the software design into source program code . Each component of design is
implemented as a program module. The end product of this phase is a set of programs that has been individually tested in unit
testing subphase.

5. Integration & System Testing

During this phase, the program modules are integrated in a planned manner , where the integration is normally carried out
incrementally over number of steps. After each integration, testing is carried out (Integration Testing). 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 software system meets its requirements specified in the SRS document. It consists of three activities:

a)  - Testing – system testing performed by the development team.

b) - Testing – system testing performed by friend set of customers.

c) Acceptance Testing – system testing performed by the end users after the product is delivered.

6. Maintenance

Maintenance involves performing the following three kinds of activities:

a) Corrective Maintenance – correcting errors.

b) Perfective Maintenance – improving the implementation of the software and enhancing its functionalities.
c) Adaptive Maintenance – making the software to work on new environment or platform.

Disadvantages of waterfall Model

a) The Waterfall Model cannot satisfactorily handle the different types of risks that a real-life software product can
encounter. For example, the Waterfall Model, assumes the requirements be completely specified before the rest of the
development activities can start. Thus, it cannot accommodate the uncertainties that exists at the beginning of most of
projects. It cannot be used in software projects where only rough requirements are available at the beginning of the
project.
b) To achieve better efficiency and higher productivity most real-life software development projects cannot follow the rigid
phase sequence imposed by the Waterfall Model, which creates a blocking states in the system. That is, some team
members would have to wait for a particular phase to complete before they can start their next activity.

Iterative Waterfall Model

The classical waterfall model is an idealistic one since it assumes that no development error is ever committed by the
software engineers during any of the life cycle phase. However, in practical development environment, the engineers
Page | 3
Chapter 8 – Software Development Life Cycle

do commit a large number of errors in almost every phase of the software life cycle. The source of defects can be like wrong
estimation, use of inappropriate technology, communication gaps among the project engineers, etc. These defects are usually
get detected much later in the life cycle. So, it is not possible to strictly follow the classical waterfall model .

Figure 2: Iterative Waterfall SDLC Model

Iterative Waterfall Model provides feedback paths from each phase to its preceding phase so that error detected in one phase,
the source of error can be searched through feedback path.

Data Flow Diagram

The Data Flow Diagram (also called Bubble Chart) is a simple graphical formalism that can be used to represent a software
system in terms of input data, various processing carried out on these data, and the output data generated by the system . A
DFD model uses a very limited number of primitive symbols to represent the functions performed by the software and the data
flow among these functions.

Figure 3: Symbols used in Data Flow Diagram (DFD)

A DFD model of a software system graphically shows the transformation of the data input to the software system to the final
results through a hierarchy of levels. A DFD starts with the most abstract definition of the system (level 0 – lowest level) called
Context Diagram and at each subsequent higher levels (level 1, 2,3,…) more details are successively introduced, where

Page | 4
 Study Material for Management Information System (MIS) BBAN-402

processes (functions or activities) are decomposed into their sub-processes and the data flow among these sub-processes are
identified. Every DFD model of a software system must be accompanied by a Data Dictionary that list all the data items appearing
in DFD model.

Example

Problem: A software system called RMS (Root Mean Square) Calculator reads three integers from the user between -1000 to
a2 + b2 + c 2
1000 and determines the RMS value of the three input numbers and display it.
3

Data Dictionary

data items : {integer} 3 asq : integer, variable stores the result of a 2

valid_data : data items bsq : integer, variable stores the result of b2
a : integer, input variable csq : integer, variable stores the result of c 2
b : integer, input variable msq : integer, variable stores the result of mean of a 2, b2, c2 calculation
c : integer, input variable rms : float, variable stores the result of root mean square

Figure 4: Data Flow Diagrams of Root Mean Square Software with Context Diagram, Level 1 & 2

Note: Numbering in each process is used to indicate which process has been decomposed into subprocesses in subsequent
levels like process 0 in level 0 has been decomposed into three process validate input (0.1), compute rms (0.2) and display
result (0.3) in level 1, similarly compute rms (0.2) process has been decomposed into three subprocesses into level 2 as 0.2.1,
0.2.2, 0.2.3, 0.2.4 and 0.2.5. After level 2 no more processes are required to be decomposed so no more levels are presentable.

Page | 5