The name for the traditional process that is used in software development that is very similar to system engineering. It takes a step by step approach, starting with fixing all the requirements.
History of the Waterfall Method
Even though he did not use the term, Dr. Winston W. Royce, at the time a project manager in the aerospace division of TRW, is often cited as giving the first formal description of the waterfall model. This was in a 1970 article, “Managing the Development of Large Software Systems”, first published in Proc. IEEE WESTCON, Los Angeles (August 1970) and reprinted in the Proceedings of the Ninth International Conference on Software Engineering, March 1987, pp.~328–338.
However, Herbert D. Benington had made a presentation about the development of software for SAGE (Semi-Automatic Ground Environment) using similar phases at a Symposium on advanced programming methods for digital computers on 29 June 1956.
The waterfall development model probably has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.
In fact Royce presented several versions of a waterfall model; a simple one that had 7 steps and no feedback.
and then 2 others showing iterations between the steps,
plus a final version of which involved a complete preliminary iteration – his ‘Do It Twice’ model.
Neither of these authors had used the term “waterfall”, and the credit for giving this process its name is usually given to Bell and Thayer in their 1976 paper, “Software requirements: Are they really a problem?”.
There are now numerous versions of the Waterfall model. Here is the one shown on the Wikipedia page.
Comments on the Waterfall Method
These days the Waterfall model has fallen out of fashion in some quarters and been heavily criticised by some software engineers, as being to rigid, bureaucratic and expensive. However this may be partly because they take Royce’s simple representation as the model, not realising what mechanical engineers have known for 200 years, that testing can always lead to the design having to be modified, but these iterations are not necessarily shown in the plan, in order to keep the message simple. The fact that this is the case, as realised by Royce, does not invalidate the underlying method.
Systems engineers are probably more in tune with the waterfall method, because it could be said to be similar to the first half of the System ‘Vee’, and like in system engineering there is an emphasis on setting requirements up front.
However, the insistence on nailing down requirements before moving on is fine when it is relatively straightforward to do so, but causes problems when this is not the case, e.g. when the customer does not really know what he wants, and this is what the authors of the Agile Manifesto were probably referring to when they proposed ‘Working software over documentation’.
Also the amount of rework due to failures in testing is likely to be small if the problem is easily solved, but if what is needed is the solution to a complex problem, then it is unlikely this will be found first time round.
Thus Waterfall methodology has its place, as does Agile, but the ideal is probably a marriage between the two.
If you would like to discuss these ideas with us, then please get in contact.