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
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
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
• Adaptive Software Development (ASD)
• Feature Driven Development (FDD)
• Crystal Clear
• Dynamic Software Development Method
• Rapid Application Development (RAD)
• Scrum
• Extreme Programming (XP)
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
