Down the Waterfall

Borrowed from the manufacturing and construction industry, the Waterfall Model of software development was described in 1970 by Winston Royce^[3] as a series of stages for building software—but on the next page he said it wouldn’t work. Apparently, no one ever read that far.

Once the dominant methodology for building software, the Waterfall Model is simple in concept, providing these seven distinct steps to be followed in this order:

Requirements

Information is gathered from subject matter experts and prospective users to create a requirements document. This is a written set of instructions that tells us what features we’re supposed to be building in the current release. Features are things that the software does.

Design

Software is then designed to fulfill the written requirements. The design is usually in the form of design diagrams and other artifacts that describe the design. This is not the code itself, but rather another document: diagrams and descriptions of how the software will be built. Unlike a blueprint, which specifies everything needed to build a building, software architecture isn’t nearly as precise or complete.

Implementation

Following design is the implementation phase, where code is written to conform to the design. Coding is simply a matter of fulfilling the design as detailed in the design artifacts.

Integration

After all the code is written the integration phase begins. During integration, all the code each team member wrote is put together. This is typically the first time all the code is assembled into a single computer program.

Testing

Once the software is integrated the testing phase begins, verifying that the software behaves as intended. This involves running a series of tests that exercise the software to prove it works.

Installation

In the installation phase the software is released to the user. This may involve distributing the program on CD and mailing it to the customer or making the software available online for download.

Maintenance

Finally, we have the ongoing maintenance of the software, in which problems are fixed, new features are added, and updates are made.

The Waterfall Model makes complete sense for building bridges or manufacturing widgets because it’s more efficient to group feature requests into releases. But software development is not a manufacturing process. Software developers don’t assemble programs from prebuilt parts. Sure, some parts can be prebuilt, but most of the parts we need we have to build or modify—even invent—ourselves. And we rarely know for sure what we’ll have to build, modify, or invent until we get there, however robust our architecture.