Constructive Criticism of the Waterfall Model
If you build software, you’ve most likely heard of the Waterfall model and the problems associated with it. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle, Ian F. Alexander and Neil Maiden provide constructive criticism of the Waterfall model.
Waterfall Model Elements
Alexander and Maiden outline the key sequence of stages in the waterfall model based on Royce (1970).
- Requirements Discovery
- Requirements Validation
- System Specification
- System Design
- Coding, First of Class
- Integration & Testing
- Operations & Maintenance
The Pros of the Waterfall Model
Alexander and Maiden write the following about the waterfall model:
To be sure, each of the stages in the ‘waterfall’ is necessary. Omit any one of them, and you have a distinctly dysfunctional project. Broadly, the sequencing is correct. It would be absurd to code the system before you have discovered what the requirements are (although there have been plenty of projects in which people have tried to do precisely that!). Furthermore, the approach, as introduced by Royce (1970) (who appreciated that iteration was necessary), and defined in popular standards such as Mazza et al. (1994), was certainly an improvement over unstructured development.
The Cons of the Waterfall Model
Alexander and Maiden provide the following downsides of the waterfall model:
- There is a distinctly left to right, single-pass, do-it-all-in-one-go, ‘big bang’ feel about it. How do notions such as ‘concept exploration,’ ‘proof of concept’, and ‘phases’ fit in?
- There seem to be firm walls between each stage stating which mode your brain is supposed to be in at any one time. Experience tells us that in practice, the engineer’s mind jumps about from thinking about requirements, to thinking about solutions and how they might be implemented, and back again. This is not reflected in the model.
- There is the strong implication that we are starting with a clean sheet of paper (the ‘green field’ situation). What about ‘brown field’ situations in which we have to add some functionality to an existing system, or modify it in some way while it continues to service? How could it apply to the use of Commercial Off-The-Shelf (COTS) components and software?
- Integration is not reflected at all. There is no sense of building prototypes and trying them out, feeding lessons learned back into the development process.
- Phasing of deliverables and incremental build-up of functionality and/or deployment is not represented. System upgrades and improvements are not dealt with.
A Disconnect Between Organizational Process Mechanisms and Realities of the Project
Alexander and Maiden write that a project life cycle needs to reflect the realities of the project:
So, although the story told by the model is in some senses correct, it also omits many project aspects that we all know to be a necessary part of project life. In fact, it is rather simplistic and inflexible. As a result, it may not be appropriate for many practical project situations. Yet many organizations mandate exactly this sort of life cycle in their project standards, with high-level Gate or Phase Reviews punctuating the life-cycle stages. If a project’s life-cycle itself fails to reflect the realities of the project’s situation, a disconnect develops between organizational process mechanisms and the realities of the project. Management reviews can become meaningless.
An Imposed Process Model is Just Another Management Fad
Alexander and Maiden write that cultural factors can inhibit addressing the disconnect between the organizational process mechanisms and the realities of the project:
Cultural factors within the organization often inhibit resolution of this problem. From Management’s point of view: developers and engineers need to be controlled and do what they are told. Many developers on the other hand, feel that the process constrains creative and intellectual freedom and is imposed without consultation. In a business world characterized by ‘initiative fatigue’, an imposed process model is just another management fad du jour, and as a result, many of the people involved just go through the motions. In this situation, the benefits of all the cumulative experience of systems engineering fail to accrue and projects start out at a disadvantage.
Key Take Aways
Here’s my key take aways:
- The waterfall model is not appropriate for many practical project situations.
- Software development is less linear than the waterfall model suggests.
- There’s can be a disconnect between organizational process mechanisms and the reality of the project.
- Cultural factors within the organization can inhibit resolving the disconnect between the organizational process mechanisms and the realities of the project.
- An imposed process model can start your project out at a disadvantage.