1.3 The Waterfall Model

The old paradigm of treating the software development process as an assembly line is no longer valid. Consider the traditional waterfall model of software development (see Figure 1.1). In this model, analysis, design, coding, testing, and maintenance form five discrete steps, each having a well-defined input and a well-defined output. At each transition the outputs become deliverables that allow managers to assess the project's progress. It became apparent rather quickly that software wasn't exactly an assembly-line process. Consider the best course of action on an assembly line if one link in the chain is slowing down the rest of the assembly line. For example, what should we do if our assembly line is constructing dolls and the person putting on the arms is slowing down the line? Obviously, we should put another person on the line to help with the arms. This will eliminate the bottleneck. Try this technique with software engineering, and the results are often disastrous. If coding is running late, a project manager cannot simply add a few members to the development team. The current members of the team will see a decrease in productivity as they take the time necessary to train the newcomers. Nevertheless, many companies have continued to use the waterfall model for project development.

Figure 1.1. The waterfall model of software development.

The waterfall model may be understandable, traceable , and desirable to managers, since they can easily track progress with a set of well-defined deliverables. However, it does not work well for developers of large systems. In fact, I doubt that developers have ever really used the model. It works great when designing your fifteenth mailing list program. You have already built 14 of them. Now you need only tweak the analysis and design models you already have, implement the new one (which looks an awful lot like the other 14), and test it. I cannot imagine taking the same mailing list developers, giving them a requirements specification for creating a real-time process control system to fold men's suit sleeves with a robot, and watching them use a waterfall process to get a good application. I have too many developer friends who, when asked how they cope with the waterfall model on unfamiliar domains, answer, "Oh, I write specs to keep managers happy and then code the thing the way I want." Of course, having the wrong specifications is worse than having no specification at all. Why not create a process for software development which maps to the real world, including the need to go back and modify design, add new requirements, test new ideas, etc.? Such a process is called the iterative model of software development.