software development life cycle
DESCRIPTION
TRANSCRIPT
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!