A Summary of the Waterfall Paper
In 1970, Dr. Winston Royce presented a paper, Managing the Development of Large Software Systems, sharing his thoughts about leading successful software projects based on his experience building aerospace systems.
I first learned of this paper during my first job as a consultant in the mid-90’s. I was still learning about software development then, so I gave it a quick glance and moved on with the project I was working on.
This weekend, I decided to understand the main points Dr. Royce made in his famous paper. This articles summarizes the main points I extracted from the paper.
The context for Royce’s paper comes from nine years of developing software packages for mission planning, commanding, and post-flight analysis.
Royce defines success as when the system is in “an operational state, on time, and within costs.”
No matter what size or complicated software system you have in mind, there are two minimum steps required to develop software: Analysis and Coding.
These steps apply when the same person builds and operates the software. A more extensive system is “doomed to failure” if built using just these two steps.
For larger projects to succeed, the required steps are: 1) System Requirements, 2) Software Requirements, 3) Analysis, 4) Program Design, 5) Coding, 6) Testing, and 7) Operations. Unfortunately, the paper does not define the specifics of any of these steps.
Customers do not see value in steps other than Coding. In addition, programmers do not want to do the extra work. So, according to Royce, management’s main job is to sell the ideas of a more thorough development model to customers and developers.
There is an iterative interaction between the steps. For example, testing can influence Program Design. Likewise, Program Design can influence Software Requirements. These feedback loops could lead to a complete redesign of the entire system and a 100% over-run in time and budget.
To prevent a redesign, Royce introduces an additional step, Preliminary Program Design, before Analysis. The program designer then works with the analysts to sense any consequence from the program design choices.
An overview document is written, providing “tangible evidence of completion.” This step forces designers to have a deep understanding of the system. The document also demands the designers to take a position on areas of the design.
For systems that represent something novel, Royce suggests to “attempt to do the job twice.” Programmers build this miniature system using all of the steps used for the overall effort. The personnel building what Royce calls a simulation “must have an intuitive feel for analysis, coding, and program design.” They choose the challenging and novel parts of the system to build and measure, leaving as little as possible to human judgment. Royce recommends using a quarter to a third of the timeline for this initial system build.
Programmers could and should remove obvious errors by code review or “inspection.” Logic paths through the code should run “at least once” using numerical checks. After the simpler errors are removed, which should account for most errors in the system, hand over the system to an area of test specialists who did not participate in the design.
Royce’s experience has shown that the simple method does not work for larger projects. Furthermore, he contends that the added efforts he proposes are less than the costs of fixing the system afterward during a redesign.
👏🏻 Give me a clap and “follow” if you enjoyed this article.
📋 About Milo
I am a tech executive, writer, speaker, entrepreneur, and inventor. I’ve been developing software since 1995 and developing teams for over a decade. 🚀
I write articles about software, engineering, management, and leadership.
You can also follow me on Twitter. 🐦
