[ - Waterfall - ]
Requirement Analysis and Definition
System and Software Design
Advantages
Implementation and Unit Testing
Disadvantages
Integration and System Testing
Limitations
-) Easy to Explain to the user
-) Adjusting scope during the life cycle can kill a project
-) Assumes the requirements will not change
-) Simple and Easy to use
-) No working software is produced until late during the life
cycle
-) This is not applicable for the development of new
systems, where there will be hidden or unknown
requirements
-) Verification at each stage ensures early detection of
errors or misunderstanding as each phase is processed and
completed one at a time
-) Easy to manage due ot the rigidity of the model each
phase has specific deliverables and a review process
-) Works well for smaller projects where requirements are
very well understood
-) High amounts of risk and uncertainty
-) Very rigid
-) Does not reflect the iterative nature of software
development
Simple, Easy explain and made for simple things. Just like a waterfall.
But like a waterfall, its rigid, risky, and if adjusted, can kill a project.
-) Stipulates that all requirements must be completely
specified before development can begin.
Operation a
[ - Fountain - ]
Requirements
Analysis
Design
Implementation
Testing an
-) User needs are gathered
-) Requirements are analysed and refined
-) System architecture is planned
-) Code is written based on design
-) System is te
-) Overlapping with design is allowed
from the start
-) Can revisit earlier phases at any time
-) Phases flow into each other with no
strict boundary
-) Progress can fall back to earlier
phases if needed
-) Ongoing mainte
earli
Advantages
-) Allows overlapping of phases so teams can work in
parallel
-) More flexible than Waterfall as phases can be revisited
-) Faster development due to concurrent activities
-) Defects found late can be corrected by revisiting earlier
phases
Disadvantages
Limitations
-) Harder to manage due to overlapping phases
-) Not ideal for very large or complex projects
-) Difficult to track progress since phases are not strictly
sequential
-) Lacks the rigid checkpoints of Waterfall making it harder
to verify completion
-) Can be confusing for teams not experienced with the
model
-) Assumes team members can handle multiple concurrent
responsibilities
-) Requires strong communication between overlapping
teams
Like a fountain, phases flow upward and then fall back down.
Flexible and overlapping, but hard to track and manage.
[ - Spiral - ]
Planning
Risk Analysis
Engineering
Evaluation
-) Objectives and constraints are defined
-) Risks are assessed and alternatives are
considered
-) Software is developed and tested for
this iteration
-) Customer reviews the current iteration
-) Prototype may be built to better
understand risks
-) A working version is produced at the
end of each spiral
-) Risks are identified before moving
forward
-) Feedback is used to plan the next
spiral
(Repea
-) Each loop throug
fe
-) Continues unt
complete
Advantages
Disadvantages
Limitations
-) Risk analysis at every stage reduces the chance of project
failure
-) Can be very expensive due to the repeated risk analysis
-) Number of spirals is not fixed, making it hard to estimate
total cost
-) Works well for large and high-risk projects
-) Time consuming as each spiral requires planning and
evaluation
-) Customer is involved throughout the development process -) Requires expertise in risk assessment which not all teams
have
-) Easy to add extra features in later spirals
-) Difficult to manage for smaller or simpler projects
-) Produces working software at the end of each cycle
Like a spiral, it loops through planning, risk, building, and review.
Great for risky big projects, but expensive and slow.
-) Relies heavily on accurate risk identification, if risks are
missed the model fails
-) Not suitable for projects with fixed budgets or tight
deadlines
[ - Rapid Prototyping - ]
Requirements Gathering
Quick Design
Build Prototype
Customer Evaluation
-) Basic requirements are collected
quickly
-) A rough design is created based on
requirements
-) A working model of the system is built
rapidly
-) User tests the prototype and gives
feedback
-) Focus is on identifying what the user
wants visually
-) Speed is prioritised over completeness
-) The prototype shows the look and feel
of the final system
-) Requirements are updated based on
what is seen
Advantages
-) User gets to see and interact with the system early on
-) Misunderstandings in requirements are caught quickly
-) Reduces the risk of building the wrong system
-) Encourages active user involvement throughout
development
Disadvantages
-) Users may confuse the prototype with the finished
product
Refine
-) Prototype is refi
-) Process repeats
then final
Limitations
-) Not suitable if user is unavailable for regular feedback
sessions
-) Can lead to scope creep as users keep requesting changes -) The prototype may set unrealistic expectations for
performance
-) Prototype code is often thrown away, which wastes effort
-) Works best for UI-heavy systems, less useful for back-end
-) Poorly managed prototyping can cause indefinite looping heavy systems
-) Useful when requirements are unclear or likely to change
Build a rough version fast, show it to the user, fix it, repeat.
Great for unclear requirements, but scope creep is a real risk.
[ - Agile - ]
Planning
Requirements
Design and Build
Testing
-) Project is broken into small iterations
called sprints
-) Requirements are gathered for the
current sprint only
-) Features are designed and coded
within the sprint
-) Testing is done continuously
throughout the sprint
-) Working softwa
the c
-) Team decides what features to build in
each sprint
-) User stories are used to define what is
needed
-) Usually lasts 1-4 weeks per sprint
-) Any defects found are fixed before the
sprint ends
-) Feedback is coll
nex
Advantages
-) Delivers working software frequently rather than all at
once
Disadvantages
-) Difficult to predict total cost and time upfront
-) Highly flexible and adapts well to changing requirements
-) Requires constant customer involvement which may not
always be possible
-) Customer is involved at every stage and sees progress
regularly
-) Can lack documentation since the focus is on working
software
-) Problems are identified and fixed quickly within each
sprint
-) Scope can change so frequently that the final product
differs from the original vision
-) Promotes teamwork and communication within the
development team
Work in short sprints, deliver often, adapt constantly.
Best for changing requirements but hard to plan total cost upfront.
Review a
Limitations
-) Not ideal for projects with fixed requirements that will
not change
-) Requires experienced and self-managing teams to be
effective
-) Difficult to scale to very large teams or projects
[ - Incremental - ]
Requirements
Design
Implement Increment
Integration
-) All requirements are defined but split
into groups
-) Overall architecture is designed at the
start
-) Each increment is built and tested
individually
-) Each new increment is integrated into
the existing system
-) Each group represents one increment
of the system
-) Detailed design is done increment by
increment
-) Earlier increments are delivered while
later ones are still being built
-) The system grows with each completed
increment
Advantages
Delivery a
-) Core functiona
-) Later incremen
based o
Disadvantages
Limitations
-) Working software is delivered early with core features
available first
-) Requires careful planning to define increments and their
dependencies
-) Not suitable if all requirements must be delivered at the
same time
-) Lower initial cost as the full system is not needed straight
away
-) Later increments may require changes to earlier ones if
requirements shift
-) Increments must be carefully sized, too large defeats the
purpose
-) Easier to test and debug individual increments than the
whole system at once
-) System architecture must be well defined from the start
or integration becomes difficult
-) Requires the customer to understand that the system will
not be complete at first delivery
-) Customer can use the early increments while later ones
are still in development
-) Managing multiple increments in parallel can be complex
-) Reduces risk as each increment is validated before the
next begins
Build and deliver the system piece by piece, core features first.
Lower risk and early delivery, but needs careful planning from the start.