This section begins the discussion of the different major software development process models. It reviews the basic life-cycle models that first introduced structured planning and development and that applied basic engineering principles to the development of software.
The Waterfall Model
The Waterfall Model was one of the first and most influential of the process models. Originating about 1970, it has had a significant historical influence in the evolution of subsequent models and has become the basis for most software acquisition standards (Boehm,_ .1988). is model was an improved version of an earlier process model called the Nine-Phase, Stage-Wise Model (see Bennington 1956 or 1983 and Madhavji et al. 1994). The Nine-Phase Model was cone-directional, sequential modes, that was enhanced by .the waterfall model through the introduction of bidirectional relations between the successive model stages, corresponding to feedback elements in the development process.
The Waterfall and the Stage-Wise models addressed problems that had been recognized in the most primitive method, the so-called code-and-fix approach, which merely iterated through a series of write-code and fix-code steps. The problem with this rudimentary tactic was that after 'a few iterations, the code would tend to become increasingly poorly structured and consequently increasingly expensive to fix. Furthermore, the implemented products were often poorly matched to the user requirements. These problems led to the recognition of the need for explicit model development phases as was done in the,Nine-Phase Model.
Although the Waterfall Model emphasized the need for feedback between stages, it used a relatively local type of feedback, confining "the feedback to successive stages to minimize the expensive rework involved in feedback across many stages" (Boehm 1988). The Waterfall Model also introduced the notion of prototyping. The partitioning of problems into manageable pieces was a significant methodological advance, especially for the design of large or complex systems, as was the recognition of the need for feedback loops and the use of basic prototyping in the software life cycle.
The different phases in the Waterfall Model incorporate the critical best practice of separation of concerns mentioned previously. In this case, that practice localizes a given class of problem solving issues to a particular phase of the development life cycle. Each phase produces a document as its product. The document summarizes the project work done up to that point so that, after that phase, it is the document "consulted without rethinking any of the decisions that went into it" (Hamlet & Maybe 2001), This is the characteristic of the principle of separation of concerns. It helps the software developer maintain "intellectual control of process" (Hamlet Maybe 2001). Indeed, the motivation underlying the problem partitioning provided by the life cycle is to reduce the complexity of the problem sufficiently so that the developer can gain a measure of intellectual control of the problem. Of course, this also demands intellectual discipline of the developers. They must resist the temptation to address issues outside the current area of concern. For example, when addressing database requirements with an end user, the developer must ignore such out-of-phase issues as data storage representation.
The Waterfall Model was widely used because it formalized certain elementary process control requirements. It provided an explicit schedule that included quality-control steps at each process completion (Yamamichi et al. 1996). Significantly, this model became "the basis for most software acquisition standards in government and industry" (Boehm 1976, 1981, 1988). Later, in a related vein, the German defense organization introduced development experience was gained and learning occurred. The simple, bidirectional relationship between successive Waterfall phases was insufficient to capture the learning that results from user feedback and involvement.
Another concern was that the model's mandated, document-driven standards often compelled developers to produce "elaborate specifications of poorly understood user interfaces and design-support functions," which was then too often followed by the "design and development of large quantities of unusable code" (Boehm 1988). Boehm (1996) formulated some of these criticisms in a particularly compelling manner. Concerning the inadequacy of written specifications for characterizing the look and feel of a user interface, he equipped that one "prototype is worth 100,000 words." He also observed that the fixed requirements encouraged by the document-driven character of the model tended to lead to so-called gold-plating, which refers to inclusion in the system design of overly elaborate or inessential functions. The fixed requirements also inclined towards rigid point solutions, which are "optimized around the original problem statement." Boehm (1996) critically observed that the Waterfall's milestones were a misfit to an increasing number of project situations.
Humphrey and Kellner (1989) criticized the model's failure to address the pervasiveness of change in software development; its unrealistically linear and orderly sequence of software activities; its inability to accommodate developments like rapid prototyping or language advances smoothly; and for providing "insufficient detail to support process optimization." The Waterfall documents used at the earlier specification and design stages frequently lack a level of clarity sufficient to allow effective fault discovery or ensure quality; the result is that errors may be overlooked until final testing. At that late point, correction becomes much more difficult with attendant complex revisions that tend to affect quality adversely (Yamamichi et al. 1996). Despite its drawbacks, the Waterfall Model remains the super class of many process-modeling approaches in software engineering. Its fundamental notions of problem and solution decomposition and a sequential step-by-step approach with feedback can be improved, but remain essential to managing the complexity of software development.
Lott (1997) describes an interesting variant on the Waterfall, which applies to situations for which the project is contracted incrementally. An initial stage of the development scopes the work, identifies the so-called thin requirements, and possibly develops a basic interface prototype using a rapid development tool such as Visual Basic, or even a model on paper. The completion of this work constitutes the completion of the contract up to that juncture. At this point, the developer or contractor relationship can be terminated by either party. This strategy represents a software development The i version of due diligence under which, prior to committing to an entire project, each side spends the requisite "time to fully understand the people and the business" (Lott 1997).
Lott's 'staged approach' to waterfall-style development allows either party to but ( opt out of the arrangement at preidentified stages, a strategy somewhat reminiscent of the risk-reduction approach used in the Spiral Model. In term contrast, in the conventional Waterfall Model, the contractors and developers are essentially compelled "to estimate cost based on limited information". This constraint can put either party at a disadvantage. In a fixed-price contract situation, the software developer assumes most of the of risk because underestimating cost may lead to a substantial loss. In a time-and-materials contract, the customer for whom the software is developed assumes most of the risk because he or she may pay considerably more than expected if the estimated development costs are exceeded. Risks associated with this approach include unstable budgets and theft of car intellectual property. Another risk is what some call (facetiously) "stealth us( technology transfer" in which the customer uses the product and knowledge acquired in the first stage to acquire the developer's expertise (Lott 1997),