The Waterfall Model is the classic software life cycle model. According to Schach , this model was the only widely accepted life cycle model until the early 1980s. This model represents the software life cycle using processes and products. Each process transforms a product to produce a new product as output. Then the new product becomes the input of the next process. The table below lists the processes and products of the Waterfall Model.
Input Product Process Output Product
Design Design Specification
Programming Executable Software
Integration Integrated Software
Delivery Delivered Software
Notice that the output product on the right becomes the input product on the left of the process at the next lowest level. The general formula for describing the transformation of products by processes can be written as follows:
Each product is represented by a gray box and each process is represented by a solid arrow connecting the boxes. To learn more about these processes and products, view the Waterfall Model animation below.
In addition to the six processes and seven products that make up the Waterfall Model, several other important development activities and characteristics are represented in the model. One of these activities is testing. According to Schach, "inherent in every phase of the Waterfall Model is testing. Testing is not a separate phase to be performed only after the product has been constructed; it is not to be performed only at the end of each phase. Instead...testing should proceed continuously throughout the software process." [Schach 1999]
Testing actually involves two steps: verification and validation. Verification is substantiating that the software has been transformed from one form into another as intended with sufficient accuracy. For example, the design process transforms the design specification document into the executable software modules. Verification in this case is determining that the software modules really are the entities that the design document describes. Verification answers the question "Are we building the software right?". Validation is substantiating that the software functions with sufficient accuracy with respect to its requirements specification. Using the same example as before, validating the executable software modules is determining that they behave as described in the requirements specification. Validation answers the question "Are we building the right software?" [Balci 1998]. Testing involving verification and validation should be conducted in parallel with the development of the software product. In order to represent the testing activity as an ongoing process, the V&V boxes appear under each product of the Waterfall Model.
Verification deals with building the software right. Validation deals with building the right software.
V&V of testing
One important characteristic of the Waterfall Model is the iteration arrows that join the processes together. These arrows show how the development of one product can influence the development of previous products. A good example of this is the programming process loop. In the diagram below, notice how the programming process and the accompanying iteration arrow form a loop between the design specification document and the executable software modules.
It is possible that design flaws will be revealed during the programming of the software. When this happens, the design specification must be changed to reflect the correction, these changes must be tested, and finally the new design must be entered into the programming process again. This loop is repeated for all the design flaws that are discovered during programming. Notice that in the complete Waterfall Model diagram (see animation above), the iteration arrows connect all the processes with the exception of the delivery process. Like the programming process, requirements engineering, design, and integration are all iterative processes that involve progressive refinement of the resulting product.
Another important characteristic of the Waterfall Model is the maintenance arrows which connect the delivered software product to the various other products in the life cycle. Remember that any changes made to the software product after delivery are considered maintenance. A small change such as the correction of a programming error may only require a change in the code of the software. These types of changes are represented by the arrow connecting the delivered software product with the executable software modules. Other changes such as the addition of new functionality require a change in the requirements specification of the software. These types of changes are represented by the arrow going to the Changed Requirements product. Notice that a change in the requirements affects almost the entire life cycle since these requirements become input to the design process and so on.
Use the animation below to test your knowledge of the Waterfall Model. Using the mouse, drag each label from the "Next Label" box to the appropriate place in the model.
[View in New Window]
- Balci, O. (1998), Software Engineering Lecture Notes, Department of Computer Science, Virginia Tech, Blacksburg, VA, p. 24.
- Schach, R. (1999), Software Engineering, Fourth Edition, McGraw-Hill, Boston, MA.