Waterfall model

The waterfall methodology is a software development process that is broken up into a series of distinct phases, with each phase existing as an autonomous phase with respect to all subsequent phases. In a waterfall project, all phases of the process have a distinct beginning and end. Whena phase is over, the subsequent phase begins. This stepped approach continues throughout the remaining phases of a project until it reaches completion. Several characteristics of the waterfall methodology often create some undesirable results:
• Each phase of a waterfall project must be complete prior to moving to the next phase.
This approach makes it difficult for you to learn and adjust to changes in the project
requirements.
• The waterfall methodology is very heavily focused on process. This approach often
causes the team to concentrate more on managing the waterfall processes, as opposed
to fulfilling the goals of the project.
• The waterfall methodology is focused on documentation as one of its primary forms of
communication. Unfortunately, software development is often a complicated matter
and is difficult to capture entirely on paper. Additionally, what is not said, or written in
this case, can be as powerful as what is said, but that type of information is not captured
in a document.
• Extensive documentation is also used as a means of trying to control scope. In the analysis
phase, requirements documents are used as contracts between software developers
and the project stakeholders. This requires the project stakeholders to know exactly what
they want and to have those needs and wants remain constant throughout the development
life cycle. This is rarely the case.
• The waterfall methodology assumes that a project can be managed by a predefined
project plan. Months are spent perfecting the plan before any work on the project really
begins. A lot of work is put into maintaining the plan throughout the project, and often
the plan is out of date with the current status of the project. The end result is the project
plan tends to be more of a historical document than a working guide to the development
team. Planning is not the problem; the problem is trying to predict and plan for
the future.

While the waterfall approach does have problems, it did start with the best intentions—
bringing order out of chaos. When waterfall methods were first employed, there was no
software process at all in place. Having some processes, documentation, and a plan is not a
bad thing. Unfortunately, the waterfall methodology swung the pendulum too far to the right.
Software projects need to be manageable, but without becoming too brittle or complicated to
implement—which is exactly what the first waterfall methods created. This swing resulted in
the development of another group of methodologies, known as Agile methods.