Maestro Development Blog

Davis, A.M., Bersoff, H. & Comer, E.R., 1988. A Strategy for Comparing Alternative Software Development Life Cycle Models. IEEE Transactions on Software Engineering, 14(10), 1453-1461.

THE classic waterfall model (see Fig. 1) was defined as early as 1970 by Royce [ 1] and later refined by Boehm [2] in 1976 to help cope with the growing complexity of the software projects being tackled. The use of such a model

• encourages one to specify what the system is supposed to do (i.e., to define the requirements) before building the system (i.e., designing);
• encourages one to plan how components are going to interact (i.e., designing) before building the components (i.e., coding);
• enables project managers to track progress more accurately and to uncover possible slippages early;
• demands that the development process generate a series of documents which can later be utilized to test and maintain the system;
• reduces development and maintenance costs due to all of the above reasons; and
• enables the organization that will develop the system to be more structured and manageable.

Boehm, B.W., 1988. A Spiral Model of Software Development and Enhancement. Computer, 21(5), 61-72.

The stagewise and waterfall models. As early as 1956, experience on large software systems such as the Semi-Automated Ground Environment (SAGE) had led to the recognition of these problems and to the development of a stagewise model’ to address them. This model stipulated that software be developed in successive stages (operational plan, operational specifications, coding specifications, coding, parameter testing, assembly testing, shakedown, system evaluation). The waterfall model,3 illustrated in Figure 1, was a highly influential 1970 refinement of the stagewise model. It provided two primary enhancements to the stagewise model:

1. Recognition of the feedback loops between stages, and a guideline to confine the feedback loops to SUCcessive
   stages to minimize the expensive rework involved in feedback across many stages.
2. An initial incorporation of prototyping in the software life cycle, via a “build it twice” step running in parallel with requirements analysis and design.

The waterfall model’s approach helped eliminate many difficulties previously encountered on software projects. The
waterfall model has become the basis for most software acquisition standards in government and industry. Some of its initial difficulties have been addressed by adding extensions to cover incremental development, parallel developments, program families, accommodation of evolutionary changes, formal software development and verification, and stagewise validation and risk analysis.

However, even with extensive revisions and refinements, the waterfall model’s basic scheme has encountered some more
fundamental difficulties, and these have led to the formulation of alternative process models.

A primary source of difficulty with the waterfall model has been its emphasis on fully elaborated documents as completion criteria for early requirements and design phases. For some classes of software, such as compilers or secure operating systems, this is the most effective way to proceed.

However, it does not work well for many classes of software, particularly interactive end-user applications. Document-driven standards have pushed many projects to write elaborate specifications of poorly understood user interfaces and decisionsupport functions, followed by the design and development of large quantities of unusable code.

These projects are examples of how waterfall-model projects have come to grief by pursuing stages in the wrong
order. Furthermore, in areas supported by fourth-generation languages (spreadsheet or small business applications), it is clearly unnecessary to write elaborate specifications for one’s application before implementing it.