“The greatest danger in times of turbulence is not the turbulence; it is to act with yesterday’s logic.” — Peter Drucker
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
Key Takeaways
Here are key takeaways:
- 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.
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.”
You Might Also Like
Waterfall, In the Large, and In the Small
Four Reasons Why Defining Effective Software Process is Tough
J.D.,
Since Waterfall has been “under attack” for many years, what brings you to the topic now?
– “the big bang feel”; doing big bang is a choice, not a requirement. It is better to break up the scope into many cascades that feed into the pool that is the finished system.
– “firm walls”; you can think any way you want, the issue is what are you delivering in each phase. Software development has such a bad history that auditors of companies are now demanding clear process and defined intermediate deliverables like Requirements to show that the right software will be delivered. I have prototyped and done proof of concepts as part of doing Requirements, but the Requirements had to be done. The prototype then may or may not have been used as the basis for full development.
– “clean sheet” – most development methodologies do focus on new development as opposed to maintenance, but the cycle still works for maintenance and enhancements, as my own expereince has shown. COTS can also use the cycle, the only differences bing an additional selection step, and the removal of the development phase.
– “integration”: again, the cycle does not imply use of technique, specific methodologies do. Prototyping for Requirements is a long used technique.
-“Phasing of deliverables and incremental build-up of functionality ” is not a life-cycle issue, it is a scoping, planning and architecture issue. Do your Enterprise Analysis before you start requirements for software (see the BABOK at http://www.iiba.com.)
-“omits project aspects”; any company using an SDLC as its Project Management Methodology deserves the problems that creates. A PMM should be used to manage any project, software or not. Over this should be a Gating process that does examine large efforts at certain points, mainly to ensure that a project is still valuable before adding more and more resources to it. If a Mangement Review kills a project before it wastes resources, that is not meaningless.
-kudos on references to engineering; software is a product, not an art form. Engineers have a process, we should emulate them.
Hey David —
You’re right, it might not be timely, but I think it’s timeless.
> break up the scope into many cascades that feed into the pool that is the finished system
I think this has a few benefits. For example, it’s easier to finish your plate if you pile less on it. It’s also less risk. Delivering incremental value also helps keep stakeholders on board. It can also help with absorption (absorb the chunks vs. swallow the whole solution at once) … and doing over chunks is more appetizing than doing over large solutions (nobody wants a downstream do-over 😉
> The prototype then may or may not have been used as the basis for full development.
I’ve throw away lots of prototypes and never considered it wastefull, as long as I carry the learnings forward. The key is to abtract the “experiences” or solution patterns from the implementation, then it’s easy to carry forward the learnings, if you don’t like the implementation.
> any company using an SDLC as its Project Management Methodology deserves the problems that creates
You might be surprised how many people don’t distinguish between product cycles and project cycles, and you’re right, it causes problems. I won’t hop on my soapbox, but suffice it to say, I’m a fan of project management, product-line engineering, software methodologies, and managing in terms of portfolios. I think having the right mental frame here goes a long way — it’s let’s you draw from a variety of works and use the best tool for the job.
Tahnks for posting