9 terms

Waterfall Model

STUDY
PLAY
Requirement Gathering and analysis:
All possible requirements of the system to
be developed are captured in this phase and documented in a requirement
specification doc.
System Design
The requirement specifications from first phase are studied in this
phase and system design is prepared. System Design helps in specifying hardware
and system requirements and also helps in defining overall system architecture.
Implementation
: With inputs from system design, the system is first developed in
small programs called units, which are integrated in the next phase. Each unit is
developed and tested for its functionality which is referred to as Unit Testing.
Integration and Testing:
All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire
system is tested for any faults and failures.
Deployment of system
Once the functional and non functional testing is done,
the product is deployed in the customer environment or released into the market
Maintenance
There are some issues which come up in the client environment. To
fix those issues patches are released. Also to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the
customer environment
When to use
Requirements are very well documented, clear
and fixed.
• Product definition is stable.
• Technology is understood and is not dynamic.
• There are no ambiguous requirements.
• Ample resources with required expertise are
available to support the product.
• The project is short.
pros
Simple and easy to understand and use
• Easy to manage due to the rigidity of the model . each
phase has specific deliverables and a review process.
• Phases are processed and completed one at a time.
• Works well for smaller projects where requirements
are very well understood.
• Clearly defined stages.
• Well understood milestones.
• Easy to arrange tasks.
• Process and results are well documented.
Dr. Borowski - Intro to Project Management 9/23/
cons
No working software is produced until late during the life cycle.
• High amounts of risk and uncertainty.
• Not a good model for complex and object-oriented projects.
• Poor model for long and ongoing projects.
• Not suitable for the projects where requirements are at a moderate to
high risk of changing. So risk and uncertainty is high with this process
model.
• It is difficult to measure progress within stages.
• Cannot accommodate changing requirements.
• No working software is produced until late in the life cycle.
• Adjusting scope during the life cycle can end a project.
• Integration is done as a "big-bang. at the very end, which doesn't allow
identifying any technological or business bottleneck or challenges early