The Waterfall Model:

Abstract: *

Preface: *

Introduction: *

The Model: *

The Waterfall Model and Other Models: *

Conclusion: *

Literature: *

 

    The waterfall model was derived from engineering models to put some order in the development of large software products. It consists of different stages, which are processed, in a linear fashion. Compared to other software development models it is more rigid and better manageable. The waterfall model is an important model, which is the basis of many other models, however for many modern projects it has become a little outdated. It is still wildly used.

    This is intended to be a short essay on the Waterfall model. It will give the historical background of this model and explain what it is in detail. Then it will be compared with other similar models and conclusion on the performance of this model will be drawn from it and what its uses are.

    At first programming software were simple and often done by one person and for engineer or scientific purposes. However, as the use of computers got more widespread, software had to be written for other people than the writers themselves, people with little or no understanding in programming. The old idea of writing a program and then fixing the bugs was no longer sufficient. In 1970 Royce proposed a model for the development of software, derived from a similar model from engineering activities. The notion at the time was that software development was an engineering discipline and that, therefore it would follow a model. This model was warmly greeted and became known as the waterfall model. Later it was found that it only worked well for certain classes of software and new, more complex models were developed. The original model by Royce was also slightly improved and adjusted over time.

    The waterfall model, as stated in the introduction, is an engineering model designed to be applied to the development of software. The idea is the following: there are different stages to the development and the outputs of the first stage "flow" into the second stage and these outputs "flow" into the third stage and so on.

There are usually five stages in this model of software development:

1. Requirements analysis and definition. In this stage the requirements of the "to be developed software" are established. These are usually the services it will provide, its constraints and the goals of the software. Once these are established they have to be defined in such a way that they are usable in the next stage. This stage is often precluded by a feasibility study or a feasibility study is included in this stage. The feasibility study includes questions like: should we develop the software, what are the alternatives? It could be called the conception of a software product and might be seen as the very beginning of the life cycle.

2. System and software design. In this stage the established requirements, flowing from the first stage, are identified as software or hardware requirements. The software requirements are then translated in such a way that they can be readily transformed into computer programs.

3. Implementation and unit testing. This is the stage where the computer programs are created. Each program is called a unit, and unit testing is the verification that every unit meets its specification.

4. System testing. All the units are combined and now the whole is tested. When the combined programs are successfully tested the software product is finished.

5. Operation and maintenance. Most software products include this stage of the development. It involves correcting errors that have gone undetected before, improvement and other forms of support. This stage is part of the life cycle of a software product, and not of the strict development, although improvements and fixes can still be considered as "development".

    These steps are the main stages. There are also sub-stages, within each stage, but they differ from project to project. For example for management purposes the requirements stage is divided in a feasibility study, an outline requirements definition, a design study and a requirements specification stage.

    It is also possible that certain software projects require the adding of an extra stage all together, or the splitting of one in two stages. However all the different waterfall models have the same underlying idea; the idea that one stage provides outputs which can be used as the input for the next stage. There thus is a linear flow amongst the stages. The progress of the software development, using the waterfall model, is thus easy to find out. A common way to look at the outputs of a certain stage and see whether or not they are finished in time, thus seeing how far the overall progress is.

    There are also activities, which are performed at every stage of the software development. These are documentation, verification and management. Documentation is intrinsic to the Waterfall model for it is document driven, as most of the outputs are documents. Verification, not only is a part of implementation, unit testing and system testing, but it is also part of all the other stages in the form of walk throughs, reviews and the like. Management involves the tailoring of the waterfall model to fit individual processes, managing the human resources (i.e. the people) and managing the rules and the protocol on how the output is formalized, who accesses what and other managing tasks.

    Finally it has to be noted that the software development process is not as linear as it seems. When errors in later stages are found, they are often fed back to a previous stage and the development is set back to that stage again. Since this is a managing nightmare, it often occurs that problems are ignored, left for later or programmed around. This feed back makes for a waterfall with information flowing both ways: down through the stages when something is made, and up through the stages when something goes wrong, or feedback is given. Also many processes are frozen when it is not yet the time to deal with them. This has led to the development of other, more flexible models.

    There are several other models that arose from the fact that the waterfall model is not always best suited for every project. They will be discussed, in short, here.

1. Code and Fix model. This is not really a model as such. It is the original approach as how to develop software when software development was still done by one person and for a restricted public who were themselves able to develop software.

2. Exploratory programming. In this model the idea is to develop a working model as quickly as possible, which is then modified until it does what it's supposed to do. Exploratory programming is best suited for systems where it is very difficult to establish detailed system specifications. This is mostly used to develop AI systems. It requires the use of very high programming languages. Validation here does not exist and rather the programs which are created are checked for adequacy. This model has been little used in software development other than in AI. This is because the management techniques that currently exist are not adequate to manage this model, and the programs resulting from this tend not to be well structured. However since there are no clear specifications in developing AI systems -which imitates human behaviors- other models, including the Waterfall model are not adequate to handle this type of problems.

3. Evolutionary Model, or Prototyping. Like in exploratory programming the idea is to create a program as quickly as possible. This program is known as the throwaway prototype. This prototype is used to give the software engineer a way to find out what the exact requirements are. Then a second program is written using the waterfall model. Evolutionary prototyping consists of many such steps and is the same as exploratory programming. In the evolutionary model a program is build once and the program is gradually improved, and thus it is increment driven; unlike the Waterfall model which is document driven.

4. Transformation model, or Formal transformations. In this model, informal requirements are analyzed which are then formalized using formal methods. This may take several steps. Once the requirements are entirely formalized they are translated into a program. The fact that the formalization takes several steps makes it support program evolution, so that later changes are easier to make than with the Waterfall model. When an update or change has to be made, due to the formal nature of the process, you often don't need to go all the way back to beginning. In the Waterfall model you don't have to go back to the beginning either, but that results in some dodgy coding.

5. Spiral model. The spiral model is a metamodel, for it can incorporate any other model in it. Whether one or the other model is chosen depends on the level of risk. The spiral model focuses on parts of the software development that are more problematic, or have a higher risk factor, than others. Another important factor is that the model is non-linear. The model consists of four stages, which are continually passed through. They are a stage to plan the next stages and what model will be used in that cycle, a stage that deals with determining the objectives, alternatives and constraints, a stage to evaluate the alternatives, identify and resolve the risks and a stage to develop, verify a product. Every cycle of stages can be done with a different model, according to what is best. Also forgotten things can be included far easier than in the waterfall model.

    The Waterfall model is the most rigid model of the software development models. Since it is documentation driven it means that there is usually a lot of it, but because it is passive, changes are very hard to implement. However it is easier to manage than other models: it addresses product and process control better than the evolutionary model or prototyping model. However it addresses user interfaces less well then the latter two, due to the difficulty in adding changes. Also, though the waterfall is a slower development model, it has fewer problems with debugging and integration than the evolutionary model or prototype model. However, again, with the evolutionary model there is more interaction between software engineers and the end users. Another thing about the Waterfall model is that it is designed towards cost-effective development of single products, and not group or families of products. The waterfall model is for short-term projects. The spiral model uses the Waterfall model or aspects of it, as do other models, even to some degree the evolutionary model.

    It is clear that the Waterfall model is an important model and that though other models have been made which are more usable for many modern projects, they still use the Waterfall model as a part of the model. The Waterfall model itself can be used for single projects that are cost or time restricted because of the easy way to manage it and cost and time restrictions are often an important issue. Lastly it is important to note that there is not one single model better than another. They all have their strong points and weaknesses.

Carlo Ghezzi, Mehdi Jazayeri and Dino Mandrioli: Fundamentals of Software Engineering,

Prentice-Hall International Inc, 1991

Ian Sommerville: Software Engineering 3rd Edition, Addison-Wesley Publishers Ltd. 1989