Acism's Offshore Outsourcing Guide > Waterfall Model

Waterfall looks at a software development project as a monolithic chunk of work, and adds rigor to
SDLC wisdom. It derives its name because of the strict sequence it imposes on the software development process, which cannot be reversed just like water can flow only downwards in a waterfall.

• At the end of every phase, a document is produced which is signed off by all concerned parties. That document becomes the input to the next phase, and cannot be changed once the next phase has started. Thus, once a requirements document is signed off then there is no room for anyone to come back and change anything in it.
• Imagine the rigor it adds to the development process. If you came up with a change – even a minor change – after the requirement document is signed off, it's too bad – it cannot be accepted now. Water doesn't flow upwards! It means that all concerned parties must think about every scenario, every minute detail about user interaction in the requirement phase as there is no chance of going back on it later.
• Client visibility on project progress is limited to documentation. The product is ready when the whole thing is ready. On large projects it could mean months or years of wait without seeing anything useful.

Waterfall is great for the software development teams, because:

• Designers have the entire scope of requirements in front of them while designing. They can make use of the various commonalities between the entities and arrive at an optimum design. These designs would be most robust, and minimize the development effort when done correctly.
• The development team can work without any background noise. They have everything they need at every step. For example, when they are in the coding step, they already have a clear design document ready which leaves no ambiguities. There is no constant pressure of deadlines.

Obviously, this model is too rigid for the clients to work in practice. Imagining everything at once –especially for large projects-- is quite tough. Requirements keep evolving over time, and reasonable course correction mechanisms are needed in practice. A big risk in waterfall is software projects producing something which is not useful although it is built to specs.

We have seen that waterfall also has an adverse impact on developer productivity, especially on big projects. Supposing that the coding phase is planned for three months, the amount of work that gets done in the first two months is quite low. Most of us crammed for our exams on the last night, right?

Further, too much time of important people is wasted. We have seen 10-15 managers doing meetings after meetings over a UI prototype, discussing things like the exact location of a button.

As a result, Acism never recommends waterfall approach for any project –although perhaps it's the easiest for the development team. It is, however, a good extreme to keep in mind while deciding the rigor on a project. There was a time not too long ago when waterfall was the only alternative to chaotic development process and was practised widely over the planet.