System Development

Lifecycle

Introduction to SDLC
Systems

Development Life Cycle

(SDLC) adheres to important phases
that are essential for developers, such
as planning, analysis, design, testing
and implementation.

There

are
several
Development Life Cycle
existence.

Systems
Models in

The oldest model, that was originally

regarded
as
"the
Development Life Cycle"

Systems
is the

Contd..
These

stages generally follow the

same basic steps but many different
waterfall methodologies give the steps
different names and the number of
steps seem to vary between 4
(Testing) and 7 (Maintenance).

There

is

no definitively correct
Systems Development Life Cycle
model, but the steps can be
characterized and divided in several
steps

Lifecycle (SDLC)
Systems development life cycle (SDLC)
Provides overall framework for managing

systems development process

Two main approaches to SDLC
Predictive approach assumes project

can be planned out in advance

Adaptive approach more flexible,
assumes project cannot be planned out in
advance
All projects use some variation of SDLC
4

Choosing the Predictive vs.

Adaptive Approach to the SDLC

Initiation/Planning
To generate a high-level view of the intended

project and determine the goals of the project.

The feasibility study is used to present the

project to upper management in an attempt

to gain funding.

Projects are typically evaluated in three areas

of feasibility: economical, operational, and

technical.

It is also used as a reference to keep the

project on track and to evaluate the progress

of the MIS team.

Requirements Gathering and Analysis

The goal of systems analysis is to determine

where the problem is in an attempt to fix

the system.

This

step involves breaking down the

system in different pieces and drawing
diagrams to analyze the situation.

Analyze project goals, break down functions

that need to be created, and attempt to

engage users so that definite requirements
can be defined.

Design
In systems design functions and operations

are described in detail, including screen

layouts, business rules, process diagrams
and other documentation.

The output of this stage will describe the

new system as a collection of modules or

subsystems.

The design stage takes as its initial input

the requirements identified in the approved

requirements document (SRS).

For each requirement, a set of one or more

Contd..

Design elements describe the desired

software features in detail, and generally

include functional hierarchy diagrams,
screen layout diagrams, tables of
business
rules,
business
process
diagrams, and a complete entityrelationship diagram with a full data
dictionary.

These design elements are intended to

describe the software in sufficient detail

that skilled programmers may develop
the software with minimal additional
input.

Build or coding
Modular

and
subsystem
programming
code
will
be
accomplished during this stage.

Unit testing and module testing are

done
in
this
developers.

stage

by

the

This stage is intermingled with the

Testing
The code is tested at various levels in software testing.
Unit,

system
performed.

and

user

acceptance

testing

are

often

This is a grey area as many different opinions exist as to what

the stages of testing are and how much if any iteration

occurs.

Types of testing:

Data set testing.

Unit testing
System testing
Integration testing
Black box testing
White box testing
Module testing
Regression testing
Automation testing

Operations and maintenance

The deployment of the system includes

changes and enhancements before the

decommissioning or sunset of the
system.
Maintaining the system is an important

aspect of SDLC. As key personnel change

positions in the organization, new
changes will be implemented, which will
require system updates

Management and control

The Systems Development Life Cycle (SDLC) phases

serve as a programmatic guide to project activity and

provide a flexible but consistent way to conduct
projects to a depth matching the scope of the project.

It is critical for the project manager to establish and

monitor control objectives during each SDLC phase

while executing projects.

Control objectives help to provide a clear statement

of the desired result or purpose and should be used

throughout the entire SDLC process.

Control

objectives can be grouped into major

categories (Domains), and relate to the SDLC phases
as shown in the figure.

SDLC
SDLC Phases
Phases Related
Related to
to Management
Management

Contd...
To manage and control any SDLC initiative, each project

will be required to establish some degree of a Work

Breakdown Structure (WBS) to capture and schedule
the work necessary to complete the project.

A work breakdown structure (WBS) in project

management and systems engineering, is a tool used to

define and group a project's discrete work elements (or
tasks) in a way that helps organize and define the total
work scope of the project

The WBS and all programmatic material should be kept

in the Project Description section of the project

notebook.

The WBS format is mostly left to the project manager to

establish in a way that best describes the project work.

Strengths of SDLC
Control.
Monitor Large projects.
Detailed steps.
Evaluate costs and completion

targets.
Documentation.
Well defined user input.
Ease of maintenance.
Development
and
standards.

design

Weakness of SDLC
Increased development time.
Increased development cost.
Systems must be defined up front.
Hard to estimate costs & project

overruns.
User input is sometimes limited.

Waterfall Model
The

waterfall model is a sequential

software development process, in which
progress is seen as flowing steadily
downwards (like a waterfall) through the
phases of Initiation, Analysis, Design
(validation),
Construction,
Testing
and
maintenance

The first formal description of the waterfall

model is often cited to be an article published

in 1970 by Winston W. Royce (19291995).

Maintenance

Waterfall Model

Waterfall Model
Progresses through the orderly sequence of

steps
It assumes that each subsequent phase will

begin when activities in the current phase

have been completed.

Each phase has defined entry and exit

criteria
Transition from one phase to the next is

accomplished by passing a formal review,

21

Strengths
The model is well known by non-software customers and

end users

It tackles complexity in an orderly way, working well for

projects that are well understood but still complex.

It is easy to use as development proceeds one phase after

another

It provides structures to a technically weak or inexperienced

staf

It works well when quality requirements dominate costs and

schedule requirements

It defines quality control procedures. Each deliverable is

reviewed as it is completed

It is easy to track the progress of the project using a Gantt

Chart
22

Waterfall Model Weaknesses

It has an inherently linear sequential nature - any

attempt to go back two or more phases to correct a

problem or deficiency results in major increases in
cost and schedule
It

can present a false impression of status and

progress - 35 percent done is a meaningless metric for
the project manager
Integration happens in one big bang at the end. With a

single pass through the process, integration problems

usually surface too late.

Tight Mgt. & control is needed because there is no

provision for revising the requirements

Insufficient opportunity for a customer to preview the

system until very late in the life cycle

23

When to use
Waterfall Model
The Waterfall model performs well for

product cycle with a stable product

definition
and
well-understood
technical methodologies.
If

a company has experience in

building a certain type of system like
accounting, payroll, compilers etc.,
then a project to build another of the
same type of product, perhaps even
based on existing designs, could make
efficient use of the waterfall model.
24

Newer Adaptive
Approaches to the SDLC
Iteration Work activities are repeated
Each iteration refines previous result
Approach assumes no one gets it right the first

time
There are a series of mini projects for each

iteration
Based on spiral model
Project cycles through development activities

over and over until project is complete

Prototype created by end of each cycle
25 Focuses on mitigating risk

Model
Incremental model is an evolution

of waterfall model.

Theincrementalbuild modelis a

method of
where the
implemented
incrementally
each time)
finished.
26

software development
model is designed,
and
tested
(a little more is added
until the product is

Contd..

Incremental

software
development model may be
applicable to projects where:
Software Requirements are well

defined, but realization may be

delayed.

The basic software functionality

are required early

Iteration of System
Development Activities

28

The Incremental Model

increment #n
Communic at ion
Planning
Modeling
analys is
des ign

C o n s t ru c t i o n
c ode
t es t

De p l o y m e n t
d e l i v e ry
fe e dba c k

delivery of
nt h increment

increment # 2
Communic at ion
Planning
M odeling
analys is
des ign

C o n s t ru c t i o n
c ode

De p l o y m e n t

t es t

d e l i v e ry
fe e dba c k

increment # 1
Communic at ion
Pl anning
Modeling
analys is
des ign

C o n s t ru c t i o n
c ode

De p l o y m e n t

t es t

d e l i v e ry
fe e dba c k

delivery of
1st increment

project calendar time

29

delivery of
2nd increment

The Incremental
Model
The incremental development is

the process of constructing a partial

implementation of a total system
and
slowly
adding
increased
functionality or performance.
Incremental model describes the

process of prioritizing requirements

of
the
system
and
then
implementing them in groups.
Each subsequent release of the
30

Contd..
The product is decomposed into a

number of components, each of

which are designed and built
separately (termed as builds).
Each component is delivered to

the client when it is complete. This

allows partial utilization of product
and avoids a long development
time.

Model
Approach..
The early phases of the life cycle (Planning,
Analysis & Design) consider the entire system to be
developed.
During these phase, the increments and the

functions within them are defined for development.

Each

increment then proceeds through the

remaining phases of the life cycle code, test and
delivery.
A set of functions that are the core, or highest

priority requirements critical to the success of the

project, or that will reduce risks is constructed,
tested and implemented first.
32

Strengths-The
Incremental Model
Funds for a total product development need not

be expended up-front because a major function or

high-risk function is developed and delivered first.
An operational product is delivered with each
increment.
Lessons learned at the end of each incremental
delivery can result in positive revisions for the
next; the customer has an opportunity to respond
to each build
The divide and conquer rule allows the
problem to be broken down into manageable
pieces.
Limited staf can be used, with the same team
working sequentially to deliver each increment.
Risk is spread across several smaller increments
instead of concentrating in one large development
33

Incremental Model
The

definition of a complete, fully functional

system must be done early in the life cycle to allow
for the definition of the increments
Well-defined interfaces are required because some

modules will be completed long before others

Formal reviews and audits are more difficult to

implement on increments than on a complete system

The customer must realize that the total cost will

not be lower

It requires good planning and design; Management

must take care to distribute the work; the technical

staf must watch dependencies
34

Incremental Model
When most of the requirements are

understood up-front but are expected to

evolve over time;
On

projects
that
have
lengthy
development schedules, usually over one
year
On low-to-medium-risk programs
On

a project with new technology,

allowing the user to adjust to the system
in smaller incremental steps rather than
leaping to a major new product
35

The RAD Model

Rapid Application Development (RAD) is an

incremental software development process

model that emphasizes a very short
development cycle [typically 60-90 days].
If requirements are well understood and

project scope is constrained, the RAD process

enables a development team to create a
fully functional system within very short
time period
The RAD model is a high-speed adaptation

of the waterfall model, where the result of

each cycle a fully functional system.
36

Model
Business Modeling: The information

flow among business functions is defined

by answering questions like what
information drives the business process,
what information is generated, who
generates it, where does the information
go, who process it and so on.
Data

Modeling:The
information
collected from business modeling is
refined into a set of data objects
(entities) that are needed to support the
business. The attributes (character of
37

Model
Process Modeling:The data object defined

in the data modeling phase are transformed to

achieve the information flow necessary to
implement a business function. Processing
descriptions are created for adding, modifying,
deleting or retrieving a data object.
Application Generation:Automated tools

are used to facilitate construction of the

software; even they use the 4th GL techniques.
Testing

and Turn over:Many of the

programming
components have already been
38

The RAD Model

Team # n
Mo d e lin g
business modeling
data modeling
process modeling

Co n st ru ct io n
component reuse
automatic code
generation
testing

Team # 2

Communication

Modeling
business modeling
dat a modeling
process modeling

Planning
Construction

Team # 1

component reuse
aut omat ic code
generat ion
t est ing

Modeling
business modeling
dat a modeling
process modeling

Construction

component reuse
aut omat ic code
generat ion
t est ing

60 - 90 days

39

Deployment
int egrat ion
delivery
feedback

Strengths of The
RAD Model
Cycle time for the full product can be reduced

due to the use of powerful development tools

Fewer Developers are required because the

system is developed
by a project team
familiar with the problem

Quick initial view of the product are possible

Ongoing customer involvement minimizes the

risk of not achieving customer satisfaction

and ensures that the systems meets the
business needs and that the operational
utility of the product is sound

40

Weaknesses of The RAD

Model
If the users cannot be involved consistently

throughout the life cycle, the final product

will be adversely affected

This model requires highly skilled and well-

trained developers in the use of the chosen

development tools to achieve the rapid
turnaround time

It can fail if reusable components

available

are not

It requires developers and customers who

are committed to rapid-fire activities in an

abbreviated time-frame

41

RAD Model
On

Systems
that
may
be
modularized and that are scalable

On systems with reasonable well-

known requirements

When the end user can be heavily

involved throughout the life cycle

On

projects
requiring
short
development times, usually about 60
days

42

Prototyping Model
The Prototyping Model is a systems development
method (SDM) in which aprototype(an early
approximation of a final system or product) is built,
tested, and then reworked as necessary until an
acceptable prototype is finally achieved from which
the complete system or product can now be
developed.

This model works best in scenarios where not all of

the project requirements are known in detail ahead

of time.
It is an iterative, trial-and-error process that takes

place between the developers and the users.

Contd..
A prototype acts as a sample to test

the process. From this sample we learn

and try to build a better final product.
Please note that this prototype may or

may not be completely different from

the final system we are trying to
develop.

Need of Prototyping Model

This type of System Development Method is employed

when it is very difficult to obtain exact requirements

from the customer(unlike waterfall model, where
requirements are clear).

While making the model, user keeps giving feedbacks

from time to time and based on it, a prototype is made.

Completely built sample model is shown to user and based on

his
feedback,
the
SRS(System
Requirements
Specifications) document is prepared. After completion of
this, a more accurate SRS is prepared, and now development
work
can
start
using
Waterfall
Model.

Steps in the Prototyping Model

There

are several steps in the Prototyping Model:

1. The new system requirements are defined in as
much detail as possible. This usually involves
interviewing a number of users representing all
the departments or aspects of the existing
system.
2. A preliminary design is created for the new
system.
3. A first prototype of the new system is
constructed from the preliminary design. This is
usually a scaled-down system, and represents
an approximation of the characteristics of the
final product.

Contd..
4. The users thoroughly evaluate the first
prototype, noting its strengths and weaknesses,
what needs to be added, and what should to be
removed. The developer collects and analyzes
the remarks from the users.
5. The first prototype is modified, based on the
comments supplied by the users, and a second
prototype of the new system is constructed.
6. The second prototype is evaluated in the same
manner as was the first prototype.

Contd..
7. The preceding steps are iterated as many
times as necessary, until the users are
satisfied that the prototype represents the
final product desired.
8. The final system is constructed, based on
the final prototype.
9. The final system is thoroughly evaluated
and tested. Routine maintenance is carried
out on a continuing basis to prevent large-

Prototyping Processing Model

Prototyping Model
1)When prototype is shown to the user, he gets a proper
clarity and 'feel' of thefunctionalityof the software and
he can suggest changes and modifications.
2)This type of approach of developing the software is
used for non-IT-literate people. They usually are not good
at specifying their requirements, nor can tell properly
about what they expect from the software.
3)When client is not confident about the developer's
capabilities, he asks for a small prototype to be built.
Based on this model, he judges capabilities of developer.

Contd..
4)Sometimes it helps to demonstrate the concept
to prospective investors to get funding for project.
5)It reduces risk of failure, as potential risks can be
identified early and mitigation steps can be taken.
6)Iteration between development team and client
provides a very good and conductive environment
during project.
7)Time required to complete the project after
getting final the SRS reduces, since the developer
has a better idea about how he should approach
the project.

Disadvantages of Prototyping
Model
1)Prototyping is usually done at the cost of the developer. So it should
be done using minimal resources. It can be done using Rapid Application
Development (RAD) tools. Please note sometimes the start-up cost of
building the development team, focused on making prototype, is high.

2)Once we get proper requirements from client after showing prototype

model, it may be of no use. That is why, sometimes we refer to the
prototype as "Throw-away" prototype.
3)It is a slow process.
4)Too much involvement of client, is not always preferred by the
developer.
5)Too many changes can disturb the rhythm of the development team.

Spiral Model
Originally proposed by Berry Boehm in 1988

Process is represented as a spiral rather

than as a sequence of activities with

backtracking
Each loop in the spiral represents a phase

in the process.
This

model of development combines the

features of the prototyping model and
thewaterfall model. The spiral model is
intended for large, expensive and complicated
projects.

53

The

iterations were
months to 2 years long.

Contd..
typically 6

Each

phase
starts
with
a
designgoaland
ends
with
the
client(who
may
be
internal)
reviewing the progress thus far.

Analysis

andengineering efforts
are applied at each phase of the

55

Steps in Spiral Model

The steps in the spiral model iteration can be

generalized as follows:The system requirements are defined in as

much detail as possible. This usually involves
interviewing a number of users representing
all the external or internal users and other
aspects of the existing system.
A preliminary design is created for the new

system. This phase is the most important part

of "Spiral Model". In this phase all possible
(and available) alternatives, which can help
in developing a cost effective project are
analyzed and strategies to use them are
decided.

Contd..
A firstprototypeof the new system is

constructed from the preliminary

design. This is usually a scaled-down
system,
and
represents
an
approximation of the characteristics of
the final product.
A second prototype is evolved by a

fourfold procedure:
evaluating the first prototype in
terms of its strengths, weaknesses,
and risks;

Spiral Model
Spiral Model is cyclic in nature
Each cycle of the spiral consists of four

stages, and each stage is represented by

one quadrant

58

software process
Commulative Cost
Progress
through
steps

Determine Objectives,
alternatives,
constraints

Risk
analys is
Risk
analys is
R isk
analys is

Commitment
Ratio

R EVIEW
Requi rement s pl an
Life-cycle plan

Develop ment
pl an

Plan next phases

59

Evaluate alternatives,
Identify, resolve risks

Integrati on
and t est p lan

Prototyp e

Prot otyp e
Risk
analysis Prototy pe

Operati onal
protoyp e

2
1 Sim
ul ati ons, m odels, b en ch marks

C oncept o f
Operati on

S/W
requi rements

Requi rement
valid ati on

Prod uct
desi gn

Detailed
desi gn

C ode
Uni t t es t
Desi gn
V&V
Integr ati on
test
Accep tance
test
Serv ice

Develop, verify nextlevel product

Spiral Model
Quadrant 1 : Determine Objectives,
alternatives and constraints
Objectives
such
as
performance,
functionality, ability to accommodate
change, hardware/software interface, and
critical success factors are identified.
Alternative means of implementing this

portion of the product are determined

constraints imposed on the application of
the alternatives (cost, schedule, interface,
environmental
limitations,
etc.)
are
60determined

Spiral Model
Quadrant 2 : Evaluate alternatives, and
identify and resolve risks
Alternatives relative to the objectives

and constraints are evaluated

The identification and resolution of risks

(risk
management,
cost-efective
strategy
for
resolving
sources,
evaluation of remaining risks where
money could be lost by continuing
system development etc. ) occurs
61

Spiral Model
Quadrant 3 : Develop Next Level Product
Typical activities in this quadrant could be
Creation of a design,
Review of Design
Development of code
Inspection of Code
Testing and packaging of the product.
The first build is the customers first look at

the system.

With each subsequent build, a better idea

of customer requirements is developed.

62

Spiral Model
Quadrant 4 : Plan Next Phase
Typical activities in this quadrant
could be
Development of the Project
Plan
Development
of
the
configuration Management plan
Development of the test plan
development of the installation
plan
63

Strengths
The spiral model allows users to see the

system early, through the use of rapid

prototyping in the development life cycle

It allows users to be closely tied to all

planning, risk analysis, development and

evaluation activities

It splits a potentially large development

efort into small chunks in which critical,

high-risk functions are implemented first,
allowing the continuation of the project
to
be
optional
Advantage
of
Incremental release

64

Strengths
It provides early and frequent feedback from

users to developers, ensuring a correct product

with high quality

Management control of quality, correctness, cost

schedule, and staffing is improved through

review at the conclusion of each iteration

It provides productivity improvement through

reuse capabilities

All money needed for the project need not be

allocated up-front

Cumulative costs may be assessed frequently

and a decrease in risk is associated with the cost

65

Weaknesses
If the project is low-risk or small, this

model can be an expensive one. The time

spent evaluating the risk after each spiral
is costly
The model is complex and developers,
managers and customers may find it too
complicated to use
Considerable risk assessment expertise is
required
The spiral may continue indefinitely,
generated by each of the customers
responses to the build initiating a new
cycle -closure may be difficult to achieve
The challenge for software teams and their
It can be hard to define objective,
managers
establish a that
proper balance
verifiable is to
milestones
indicate
readinessthe
to critical
proceed
through
next
between
project
and the
product
66 iteration
parameters and customer satisfaction

Model
For projects that represent a medium to high

risk

When it is unwise to commit to a long-term

project due to potential changes in economic

priorities and when these uncertainties may
limit the available time frame

When it is important to focus on stable or

known parts while gathering

about changing parts.

knowledge

When new technologies are being employed,

such
as
approaches

67

first-time

object

oriented

Tools and Techniques

Tools
Software support that helps create models or other

required project components

Range from simple drawing programs to complex
CASE (Computer Aided software Engineering) tools to
project management software
Techniques
Collection

of guidelines that help analysts

complete a system development activity or task
Can be step-by-step instructions or just general advice
68

Some Tools Used in

System Development

69

Some
Some Techniques
Techniques Used
Used in
in System
System Development
Development

70

END OF Chapter
SDLC