Introducing XP—The Waterfall Methodology

Microsoft .NET Framework, ASP.NET, Visual C# (CSharp, C Sharp, C-Sharp) Developer Training, Visual Studio

The Waterfall Methodology

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. When a 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.