SOFTWARE DEVELOPMENT LIFE

CYCLE (SDLC) MODELS

SDLC MODEL
A framework that describes the activities performed at
each stage of a software development project.
A software lifecycle model is a standardised format for
planning
organising, and
running
a new development project.
WHAT IS A LIFECYCLE MODEL?
Definition.
A (software/system) lifecycle model is a
description of the sequence of activities
carried out in an SE project, and the relative
order of these activities.
Normally, a lifecycle model covers the entire
lifetime of a product.

From birth of a commercial idea

to final de-installation of last release
Hundreds of different kinds of models are known
and used.

Many are minor variations on just a small number of

basic models. In this section we:
survey the main types of models, and
consider how to choose between them.
PLANNING WITH MODELS
SE projects usually live with a fixed financial
budget. (An exception is maintainance?)

Additionally, time-to-market places a strong

time constraint.

There will be other project constraints such

as staff.
Examples of Project Constraints
designers
programmers managers

money staff

Project constraints

Computing
resources time
By changing the lifecycle model, we can
improve and/or tradeoff:

Development speed (time to market)

Product quality
Project visibility(documentation)
Administrative overhead
Risk exposure
Customer relations, etc, etc.
There are hundreds of different lifecycle models
to choose from, e.g:
waterfall,
code-and-fix
spiral
rapid prototyping
agile methods, extreme programming (XP)
but many are minor variations on a smaller
number of basic models.
Note that we can sometimes combine
lifecycle models,
e.g. waterfall inside evolutionary
We can also change lifecycle model between
releases as a product matures,
e.g. rapid prototyping  waterfall
 1. The Waterfall Model
• The waterfall model is the classic lifecycle
model – it is widely known, understood
and (commonly?) used.
• In some respect, waterfall is the ”common
sense” approach.
• Introduced by Royce 1970.
 phase
User Requirements output User Requirements Document

Software Requirements Software Requirements

Document

Architecture Design Architectural Design

Document

”Swimming Detailed design & Coding Detailed

upstream” Design
The Waterfall & Code
Testing
Lifecycle Workflow
Delivery
Time
ADVANTAGES
1. Easy to understand and implement.
2. Widely used and known (in theory!)
3. Reinforces good habits: define-before- design, design-before-
code
4. Identifies deliverables and milestones which are well
understood.
5. Document driven, URD, SRD, … etc. Published documentation
standards,
6. Works well on mature products and weak teams.
7. Good for management control. (plan, staff, track)
8. Applicable where requirements are well understood.
9. Works well when quality is more important than cost or
schedule
DISADVANTAGES I
1. Idealised, doesn’t match reality well. Can give a
false impression of progress
2. Doesn’t reflect iterative nature of exploratory
development. Does not reflect problem-solving
nature of software development – iterations of
phases
3. Unrealistic to expect accurate requirements so
early in project. All requirements must be known
upfront
DISADVANTAGES II
5. Difficult to integrate risk management
6. Difficult and expensive to make changes
to documents, ”swimming upstream”.
7. Significant administrative overhead,
costly for small teams and projects.
8. Deliverables created for each phase are
considered frozen – inhibits flexibility
9. Integration is one big bang at the end
 DISADVANTAGES III
10. Software is delivered late in project, delays
discovery of serious errors.
11. Little opportunity for customer to preview
the system (until it may be too late)
WHEN TO USE THE WATERFALL
MODEL
Requirements are very well known
Product definition is stable
Technology is understood
New version of an existing product
Porting an existing product to a new platform.
 2. CODE-AND-FIX

This model starts with an informal general

product idea and just develops code until a
product is ”ready” (or money or time runs
out). Work is in random order.

Corresponds with no plan!

ADVANTAGES

1. No administrative overhead
2. Signs of progress (code) early.
3. Low expertise, anyone can use it!
4. Useful for small “proof of concept” projects, e.g.
as part of risk reduction.
DISADVANTAGES

1. Dangerous!
 No visibility/control
 No resource planning
 No deadlines
 Mistakes hard to detect/correct
2. Impossible for large projects,
communication breakdown, chaos.
 3. SPIRAL MODEL

- It was first propagated by Boehm

Since end-user requirements are hard to
obtain/define, it is natural to develop software
in an experimental way: e.g.
1. Build some software
2. See if it meets customer requirements
3. If no goto 1 else stop.
This loop approach gives rise to structured iterative
lifecycle models.

In 1988 Boehm developed the spiral model as

an iterative model which includes risk analysis and risk
management.

Key idea: on each iteration identify and solve

the sub-problems with the highest risk.
 Cumulative cost Evaluate alternatives,
Determine objectives, Identify & resolve risks
alternatives & constraints

Prototypes Operational
Review & Start P1 P2 P3 Prototype
commitment Requirements Concept
Design, Detailed design
plan Of Operation Validation
Development & Verification
plan Requirements
validation Coding
Integration &
Test plan Unit & Integration
Testing
End Acceptance Develop & verify
Plan next phase Testing
next-level product
 SPIRAL QUADRANT
DETERMINE OBJECTIVES, ALTERNATIVES AND
CONSTRAINTS

 Objectives: functionality, performance, hardware/software

interface, critical success factors, etc.
 Alternatives: build, reuse, buy, sub-contract, etc.
 Constraints: cost, schedule, interface, etc.
SPIRAL QUADRANT
EVALUATE ALTERNATIVES, IDENTIFY AND
RESOLVE RISKS
 Study alternatives relative to objectives and constraints
 Identify risks (lack of experience, new technology, tight
schedules, poor process, etc.
 Resolve risks (evaluate if money could be lost by continuing
system development
SPIRAL QUADRANT
DEVELOP NEXT-LEVEL PRODUCT

 Typical activities:
 Create a design
 Review design
 Develop code
 Inspect code
 Test product
Spiral Quadrant
PLAN NEXT PHASE

 Typical activities
 Develop project plan
 Develop configuration management plan
 Develop a test plan
 Develop an installation plan
ADVANTAGES

1. Realism: the model accurately reflects the

iterative nature of software development
on projects with unclear requirements
2. Flexible: incoporates the advantages of the
waterfall and rapid prototyping methods
3. Comprehensive model decreases risk
4. Good project visibility.
DISADVANTAGES

Needs technical expertise in risk analysis to

really work
Model is poorly understood by non-
technical management, hence not so widely
used
Complicated model, needs competent
professional management. High
administrative overhead.
 4.PROTOTYPING

A prototype is an original type,

form, or instance of something
serving as a typical example, basis, or
standard for other things of the same
category
FORMS OF PROTOTYPING
 There are main forms in which prototyping is used:
 Throw-away prototyping and evolutionary prototyping or
exploratory programming
 They work from an outline of the requirements.
 Exploratory programming aims to develop the final software
bit-by-bit. The end result is usually poorly structured
 Evolutionary prototyping: used to develop a working system,
piece by piece
 Throw-away prototyping: the prototype is used solely to
determine what the system requirements should be and then
discarded.
ADVANTAGES OF PROTOTYPING:

 Identifies problems (communication) between users and

developers
 Helps detects missing services
 Identifies hard to use services and interfaces
 Demonstrates the system feasibility to management
 Can serve as the ground rules for a specification
 May be used for user training
 May be used for testing
DISADVANTAGES OF PROTOTYPING:

prototyping is expensive and time

consuming
a slow/inefficient prototype might
actually discourage system use rather
than encouraging it
(A) EVOLUTIONARY PROTOTYPING

Developers build a prototype during the

requirements phase
Prototype is evaluated by end users
Users give corrective feedback
Developers further refine the prototype
When the user is satisfied, the prototype code is
brought up to the standards needed for a final
product.
Requirements Capture Establish objectives thru’ user comm.

Iterate
Quick Design

Build Prototype

Customer Evaluation of
Prototype
The Rapid
Prototype Workflow Engineer Final
Product
ADVANTAGES OF EVOLUTIONARY
PROTOTYPING
1. Reduces risk of incorrect user requirements. A
more accurate end product. Unexpected
requirements accommodated
2. Good where requirements are
changing/uncommitted. Allows for flexible design
and development
3. Regular visible progress aids management.
Customers can “see” the system requirements as
they are being gathered
4. Supports early product marketing
5. Developers learn from customers
DISADVANTAGES OF
EVOLUTIONARY PROTOTYPING
1. An unstable/badly implemented prototype often
becomes the final product.
2. Requires extensive customer collaboration
 Costs customers money
 Needs committed customers
 Difficult to finish if customer withdraws
 May be too customer specific, no broad
market
DISADVANTAGES OF
EVOLUTIONARY PROTOTYPING
3. Difficult to know how long project will last
4. Easy to fall back into code-and-fix without
proper requirements analysis, design,
customer evaluation and feedback.
5. The customer may want the prototype
delivered.
(B)THROAWAY PROTOTYPING

Throw-away prototyping results in an executable

prototype but this is not intended to be the final
system. Rather it is used to firm up the
requirements that are used for development of the
actual software
WHEN TO USE PROTOTYPING
Requirements are unstable or have to be clarified
As the requirements clarification stage of a
waterfall model
Develop user interfaces
Short-lived demonstrations
New, original development
5. NEWER MODELS: RAPID
APPLICATION DEVELOPMENT(RAD)

Key idea: Customers are non-technical and

usually don’t know what they want/can have.

Rapid prototyping emphasises requirements

analysis and validation, also called:
 customer oriented development,
 evolutionary prototyping
Requirements planning phase (a workshop utilizing
structured discussion of business problems)
User description phase – automated tools capture
information from users
Construction phase – CASE tools used:-
productivity tools, such as code generators, screen
generators, etc. inside a time-box. (“Do until
done”)
Cutover phase -- installation of the system, user
acceptance testing and user training
RAD STRENGTHS
Reduced cycle time and improved productivity with
fewer people means lower costs
Time-box approach mitigates cost and schedule
risk
Customer involved throughout the complete cycle
minimizes risk of not achieving customer
satisfaction and business needs
Focus moves from documentation to code
(WYSIWYG).
Uses modeling concepts to capture information
about business, data, and processes.
RAD WEAKNESSES

Accelerated development process must give quick

responses to the user
Risk of never achieving closure
Hard to use with legacy systems
Requires a system that can be modularized
Developers and customers must be committed to
rapid-fire activities in an abbreviated time frame.
WHEN TO USE RAD
Reasonably well-known requirements
User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments
High performance not required
Low technical risks
System can be modularized
6.V-SHAPED SDLC MODEL
 A variant of the Waterfall that
emphasizes the verification
and validation of the product.
 Testing of the product is
planned in parallel with a
corresponding phase of
development
 V-SHAPED STEPS
 Project and Requirements Planning –
allocate resources
 Product Requirements and Specification
Analysis – complete specification of the
software system
 Architecture or High-Level Design –
defines how software functions fulfill
the design
 Detailed Design – develop algorithms
for each architectural component
 Production, operation and maintenance
– provide for enhancement and
corrections
 System and acceptance testing – check
the entire software system in its
environment
 Integration and Testing – check that
modules interconnect correctly
 Unit testing – check that each module
acts as expected
 Coding – transform algorithms into
software
V-SHAPED STRENGTHS

Emphasize planning for verification and

validation of the product in early stages of
product development
Each deliverable must be testable
Project management can track progress by
milestones
Easy to use
V-SHAPED WEAKNESSES

Does not easily handle concurrent events

Does not handle iterations or phases
Does not easily handle dynamic changes in
requirements
Does not contain risk analysis activities
WHEN TO USE THE V-SHAPED MODEL

Excellent choice for systems requiring high

reliability – hospital patient control
applications
All requirements are known up-front
Solution and technology are known
7.INCREMENTAL SDLC MODEL
 Construct a partial implementation
of a total system
 Then slowly add increased
functionality
 The incremental model prioritizes
requirements of the system and then
implements them in groups.
 Each subsequent release of the
system adds function to the previous
release, until all designed
functionality has been implemented.
INCREMENTAL MODEL STRENGTHS
 Develop high-risk or major functions first
 Each release delivers an operational product
 Customer can respond to each build
 Uses “divide and conquer” breakdown of tasks
 Lowers initial delivery cost
 Initial product delivery is faster
 Customers get important functionality early
 Risk of changing requirements is reduced
INCREMENTAL MODEL WEAKNESSES

Requires good planning and design

Requires early definition of a complete and
fully functional system to allow for the
definition of increments
Well-defined module interfaces are required
(some will be developed long before others)
Total cost of the complete system is not
lower
 WHEN TO USE THE INCREMENTAL
MODEL
Risk, funding, schedule, program complexity, or need
for early realization of benefits.
Most of the requirements are known up-front but are
expected to evolve over time
A need to get basic functionality to the market
early(Competition)
On projects which have lengthy development
schedules
On a project with new technology
 8.AGILE (XP) MODEL
XP = Extreme Programming emphasizes:
Extreme Programming (XP) is a software
development methodology which is intended to
improve software quality and responsiveness to
changing customer requirements. As a type of agile
software development, it advocates frequent
"releases" in short development cycles (time
boxing), which is intended to improve productivity
and introduce checkpoints where new customer
requirements can be adopted.
 XP PRINCIPLES
 Programming in pairs or doing extensive code review, unit
testing of all code,
 Avoiding programming of features until they are actually needed,
 A flat management structure,
 Simplicity and clarity in code,
 Expecting changes in the customer's requirements as time
passes and the problem is better understood, and frequent
communication with the customer and among programmers.
Extreme Programming is successful because it
stresses customer satisfaction. Instead of delivering
everything you could possibly want on some date
far in the future this process delivers the software
you need as you need it. Extreme Programming
empowers your developers to confidently respond
to changing customer requirements, even late in
the life cycle.
ADVANTAGES

Lightweight methods suit small-medium size

projects
Produces good team cohesion
Emphasises final product
Iterative
Test based approach to requirements and quality
assurance
DISADVANTAGES

Difficult to scale up to large projects where

documentation is essential
Needs experience and skill if not to degenerate
into code-and-fix
Programming pairs is costly (2 programmers)
Test case construction is a difficult and specialised
skill.