Source: http://crmsearch.eu/agile-versus-waterfall-crm.php
The waterfall model was originally defined by Winston W. Royce in the1970s. attempts to complete each phase before moving to the next but has built-in feedback loops which allow you to return to a previous phase if you discover problems. The phases contain progress flows similar to a waterfall cascading down a hill, hence the name.
- Requirements Analysis
- Design
- Implementation
- Testing
- Maintenance
- Design errors are identified and captured early
- Measuring progress is easy due to well-defined milestones
- Accurate cost estimates can be provided, even for large projects.
- Considerable administrative overhead for changes
- Unrealistic assumption regarding no future possibility of requirement changes
- Unmet deadlines due to many unknowns during the project timeline
The waterfall model was originally defined by Winston W. Royce in the1970s. attempts to complete each phase before moving to the next but has built-in feedback loops which allow you to return to a previous phase if you discover problems. The phases contain progress flows similar to a waterfall cascading down a hill, hence the name.
- Requirements Analysis
- Design
- Implementation
- Testing
- Maintenance
- Design errors are identified and captured early
- Measuring progress is easy due to well-defined milestones
- Accurate cost estimates can be provided, even for large projects.
- Considerable administrative overhead for changes
- Unrealistic assumption regarding no future possibility of requirement changes
- Unmet deadlines due to many unknowns during the project timeline
The waterfall model was originally defined by Winston W. Royce in the1970s. attempts to complete each phase before moving to the next but has built-in feedback loops which allow you to return to a previous phase if you discover problems. The phases contain progress flows similar to a waterfall cascading down a hill, hence the name.
- Requirements Analysis
- Design
- Implementation
- Testing
- Maintenance
- Design errors are identified and captured early
- Measuring progress is easy due to well-defined milestones
- Accurate cost estimates can be provided, even for large projects.
- Considerable administrative overhead for changes
- Unrealistic assumption regarding no future possibility of requirement changes
- Unmet deadlines due to many unknowns during the project timeline
In the 1990's, to cope with the requirement changes in dynamic scenario, a new form of software development called Iterative Development came to prominence. In contrast to one delivery approach taken by the then traditional waterfall model, the iterative approach would have several cycles. At the end of each cycle, something of value would be delivered to the client.
- Flexibility to take feedbacks in to accounts after each iteration
- Handle change of context & resolve conflicts at each iteration, not affecting the entire software/product development cycle
- Learn from each iteration and take that learning to the next
The popularity of iterative software/product development in the 1990's, in turn, motivated a new set of methodologies such as Extreme Programming (XP), SCRUM, and Kanban.
In 2002, some visionaries in the field of software development condensed what they had learned into a set of principles called the Agile Manifesto, which crystallized the arrival of Agile development practices into the world