1. Review of Project Management
Methodologies
for
Software Development Life
Circles
(SDLC)
Maksym Dovgopolyi, PMP
2012
2. Waterfall 1956
Incremental
1960
Prototyping
1970
Adaptive
Software
1974
Spiral 1986
Dynamic
Software
Development
1994 Scrum 1995
RUP, Extreme
Programming Feature Driven
1996 Development
methodologies
1997
Crystal clear
2003
RAD 2004
Timeline of Project management
3. Waterfall
Principles:
● Set of phases that are strictly one by one
Requirements
Design
Implementation
Test
Installation
Maintenance
4. 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
5. Waterfall
Weaknesses:
● 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
6. 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
7. Incremental
Principles:
● A series of mini-waterfall development
● By module implementation of total System
First 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
8. 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
9. 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
10. 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
11. Agile
Some of the most common methods among
others:
● Adaptive Software Development (ASD)
● Feature Driven Development (FDD)
● Crystal Clear
● Rapid Application Development (RAD)
● Scrum
● Extreme Programming (XP)
● Lean Software Development
12. 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
13. 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
14. 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
15. 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
19. 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
20. 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
21. 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
22. 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
24. 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
25. 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
26. 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
27. Prototyping
Where 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