Software development life cycle

Software Development Life Cycle(SDLC)

HistoryW

ater

fall

195

6

Incr

emen

tal

1960

Prot

otyp

ing

1970

Adap

tive

Soft

war

e

19

74

Spira

l 19

86

Dyn

amic

So

ftw

are

Dev

elop

men

t 19

94Sc

rum

199

5

RUP,

Ext

rem

e

Prog

ram

min

g 19

96Fe

atur

e D

riven

D

evel

opm

ent

1997

Crys

tal c

lear

20

03

RAD

20

04

WaterfallRequirements

Design

Implementation

Test

Installation

Maintenance

Waterfall

Strengths:• Easy to understand and use • Provides structure to inexperienced staff• Sets requirements Stability• Good for control (plan, staff, track)• Quality more important than cost or schedule

Waterfall

Deficiencies:• All requirements must be known upfront • Inflexible, slow, costly• Little opportunity for customers• Difficult to respond to changes• Problems often are not discovered until system

testing• Written specs are often difficult for users to read

Waterfall

When to use:• Requirements are very well known• Product definition is stable • Technology is understood• New version of an existing product• Integration an existing product to the new

platform• Project is large, expensive, complicated

Incremental

Principles:• A series of mini-waterfall development • By module implementation of total SystemFirst prioritize requirements of the system and then implement them in group• Each release adds functionality to the previous

release, until all designed functionality has been implemented

Incremental

Strengths:• Risk of changes in requirements is reduced• Customer gets important functionality early• Initial product delivery is faster• Lowers initial delivery cost• Customer can respond to each build

Incremental

Weaknesses:• Requires good planning and design• Requires early definition of done and fully

functional system to allow for the definition of increments

• Total cost of the complete system is still high

Incremental

When to use:• Web Information Systems (WIS)• Leading-edge applications• Large projects where requirements are not well

understood• Project where budget and technical changes are

expected• A need to get basic functionality to the market

earlier

Agile

• Adaptive Software Development (ASD)• Feature Driven Development (FDD)• Crystal Clear• Dynamic Software Development Method• Rapid Application Development (RAD)• Scrum• Extreme Programming (XP)

Rapid Application Development (RAD)

Principles:• Fast development and delivery of high quality

system with low cost• Breaking the project into small segments • To produce high quality system quickly • Users closely involved in the system design• Uses “time boxes”• Iterative software product delivery

Rapid Application Development (RAD)

Strengths• The operational version of app is available

much earlier • Provides the ability to rapidly change system

design as demanded • Generally savings in time, money and human

effort• Time-box approach

Rapid Application Development (RAD)

Weaknesses:• May lead to lower overall system quality • Could be Gold-plating • Potential for design system lack of scalability• Risk of never achieving closure

Rapid Application Development (RAD)

Where to use:• Small or medium projects with short duration • Project scope is focused, business objectives are well defined• Functionality of the system is clearly visible in the user UI• End-users are involved • Team is stable and skilled• Input data for the project already exists• Technical architecture is defined • Tech requirements are reasonable and well within the

capabilities of the technology being used• Low technical risks • System can be modularized

Extreme Programming (XP)

Principles:• Coding is the key activity throughout the

project• Communication among teammates is done

with code

Extreme Programming (XP)

Practices/Strengths:• Planning game

(planning poker)• Small releases • Metaphor • Simple design • Testing• Refactoring

• Pair-programming • Collective ownership • Continuous

integration • 40 hours week• On-site customer• Coding standard • Code review

Spiral

Cycles

Spiral

Principles: • Identify and resolve risks by breaking a project

into small segments• Study alternatives • Begin each cycle with an identification of

stakeholders and End cycle with review and commitment

Spiral

Strengths:• Provides early indication of risks• User sees the system earlier because of rapid

prototyping tools • Critical high-risk functions are developed first• User can be closely tied to all life-cycle steps• Early and frequent feedback from user• Can incorporate Waterfall, Prototyping and

Incremental methodologies depending on which of these models best fits a given iteration

Spiral

Weaknesses:• Challenging to determine the exact composition of dev.

methodology to use for each iteration around the Spiral • Highly customized to each project • PM has to be skilled and experienced to determine how

to apply it • Each cycle may generate more work for the next cycle• Cycle continues with no clear termination condition;

there is risk of not meeting budget or schedule• May be hard to define objectives, milestones

Spiral

When to use:• Users/clients are unsure of their needs• Requirements are complex• Significant changes are expected• Real-time or safety-critical system• Risk avoidance is High priority • PM is highly skilled and experienced • Project might benefit from a mix of other

development methodologies

Prototyping

1. Requirements

2. Design

3. Coding

4. Testing Implementation,Delivering Maintenance

Cycles:

Prototyping

Principles:• User is involved throughout of process• The basic understanding of the business

problem is necessary to avoid solving the wrong problem

• Split the project into small segments to reduce risks

Prototyping

Strengths:• Provides quick implementation • Encourages innovation and flexible design • Helps to easily identify confusing or difficult or

missing functionality • Useful to resolve unclear objectives • Improves user and developer communication

with stakeholders

Prototyping

Weaknesses: • Approval process and control is not strict• Requirements may frequently change significantly • Identification of non-functional elements is

difficult to document• Can lead to poorly designed system (quick and

dirty)• Can lead to false expectations – customer

believes that system is “finished”. It looks good and has adequate user UI, but not truly functional

PrototypingWhere to use:• Online system requiring extensive user dialoging • Project is large with many users and functions, where project risks need

to be reduced • Project objectives are unclear• Pressure of immediate implementation of something• Functional requirements may change frequently and significantly • User is not fully knowledgeable • Team members are experienced • Team composition is stable • PM is experienced • Not strict requirements for approval at design milestones • Analysts assess business problems before the project start

Good Luck!