Chapter 2 - The waterfall

The Waterfall

One of the earliest attempts at creating a software development process was the waterfall method. The name implies software development begins at the top and somehow reaches the bottom. The top is the project sponsor wanting something, and the bottom is the project sponsor receiving something.

The waterfall itself is not one of those plunging torrents seen in Tarzan films or Yosemite photographs. It is more stepped and serene, with a series of easy falls where the water splashes gracefully from one level to the next.

The four steps of the basic waterfall are requirements gathering, development, testing and release.

Figure 2.1 The waterfall model for software development

As we’re on the architect road, I should point out the nature of the waterfall: it's not really there. We are using something with which people are familiar to make an unrelated point. This technique is called abstraction; we take a common object and place it in another setting. Doing so helps both ourselves and others to understand the unfamiliar by comparing it to something familiar.

Using the waterfall is creating a model, or an overview of the process. This is the basic skill an architect requires. You must be able to model, to abstract. You must be able to build high level models and detailed models, and then models of the same thing from different perspectives. Imagine a bridge designer having two models, one made from cardboard and cotton shows the form, or shape, of the bridge. The other is a mathematical model of nodes, connections, strengths and degrees of freedom used to calculate the bridge's static and dynamic strength. Similarly in software, you may model a view of the user interface and a view of the class structure supporting it. You may create views of the instantiated classes at runtime, and examples of the data contained, then a project view of what will be delivered to the customer, and when.

Figure 2.1 is an example of a high level model. It does not tell you how to gather requirements or test something, but it does tell you it happens.

The waterfall is being used as a metaphor, an abstraction or a model of what we are really discussing. You will use the same method to discuss your intended software products with your sponsors and peers.

The amount of detail you need to put into each model depends on its intended audience. The sponsor may need only the highest overview. A developer will need far more detailed information. The more detail you put in, the less the model is abstracted.

Figure 2.2 Level of abstraction versus intended audience

The waterfall model can be further detailed in a number of ways. Some show a falling then rising waterfall, commonly known as a V model, with testing activities to match each of the development activities. Others show a many stepped linear waterfall or a linear waterfall with feedback for an iterative process. The wealth of different versions of the waterfall show the strength of the analogy to software development. It is very useful as everyone can understand it. We shall return to our waterfall model many times, turning it into an incremental, iterative software development process, rather than this rather worn and slippery linear one.

The waterfall has been around for a long time, and there are some wonderful varieties to be found. Later on we shall look at other attempts to model the development process with spirals and words like inception, elaboration, transition, risk confronting, and other such lengthy words. If you learn them all, you will be able to confuse almost anyone. Unfortunately, many such etyma have been given a place in visions of the software development process. By the end of this book you will hearken back to the simple waterfall with fond memories.

How to apply the waterfall to software development

Although the waterfall has been supplanted in many development environments by methods enabling their proponents to be paid more money, it is still the foundation of all the superior processes.

Simply put, software development begins, travels through a number of phases, and in the final phase a software product is delivered to the project sponsor.

Our rather simple four stage waterfall shows that first we must gather requirements. We must interview our sponsor and find out what the software must do. We then go ahead and write the software. When the software is complete, it is tested. If we followed our model rigorously, the next step would be to release the results of our project.

As we are all painfully aware, this never happens. The testers always find something wrong, or create mountainous disagreements on font colour, size etc. To and fro the product goes between development and test until all of the disagreements have been argued away, and some of the obscure bugs have been found and possibly fixed.

Finally, after much agitation and argument, the product goes out to the users for its real testing. You call it user acceptance testing, a beta release or a release candidate. They think it’s finished, get on with their job, and complain when it doesn’t work properly. They may even say something like: “That’s not what we wanted.”

These are the problems inherent in the waterfall model.

The waterfall should show a little turbulence between test and development, and then slightly larger amounts of turbulence once it hits the users.

Figure 2.3 The reality of the waterfall process

Software development is an inherently complex process. When it is simplified down to the waterfall model, it begins to look easy. When things look easy, people assume that they are. Assumptions of ease lead to disappointment.

To overcome such disappointment, we have created more complex models. The waterfall has been supplanted by more rigorous statements of how we are meant to go about what we do.