Having spent a decade or two looking at methodologies of all kinds, I note two things: that waterfall models are still pretty prevalent, and that they are generally not very clearly thought through. In particular, they tend to lack a logical model. Instead, there is a strong tendency to leap straight to a list of things for the project manager to do.
Partly in response to this and partly out of simple intellectual curiosity, I have drafted what is, I think, a completely generic model of waterfall development. Or rather, of how each stage in any waterfall method should work. I don’t worry too much about identifying the stages themselves – Requirements, Analyse, Design, Built, Test, Accept, Deploy are pretty much universal now.
Anyway, here is the generic stage model, followed by an example of how it might be made more concrete for a design stage. (As always, click to expand the images.)
How would you use this model? Just string together as many instances as you need – one for each development stage. Then add a project management and governance layer, preferably from a stage-based approach such as PRINCE2. Then make sure that you have something in each box – or if you haven’t, that you can explain why not.
Here’s a high-level implementation for a design stage:
As you can see, there is a doubling-up of tasks, and things can be defined and redefined to many more levels. but the general logic remains visible.
‘It’s not realistic’ and ‘we don’t do things like that around here’ are not valid reasons for rejecting an underlying logical model. Being ‘realistic’ means ‘I have given up trying to make things work properly’, and ‘around here’ means ‘in this god-forsaken hole where nothing makes any sense’ – neither a suitable reason for making an exception.