Waterfall model

Figure 5.1 illustrates the waterfall process. Most software development projects deal with moving targets—changing business, changing requirements, and changing priorities. The waterfall model is not suited for this type of software development. 

The development methodology establishes detailed discrete work products, by phases and events, and by associated activities. The computer systems development approach must be consistent with the selected SLC the most common development methodologies are the Waterfall Model, the Incremental Development Model, the Evolutionary Model, the Object Oriented approach, and the Spiral Model. Sample SLC activities and work products are detailed in Appendix E. 

The validation activities presented in this book can be implemented in accordance with a number of life-cycle methodologies. The waterfall model hfe cycle is the most rudimentary approach and basically cascades the activities presented in Chapter 6 through Chapter 12 inclusive. The ordered sequence of the waterfall life cycle works well with tightly defined and understood requirements. Unfortunately, in the real world, although we might like to think otherwise, most projects are not tightly defined and understood. 

The most common development methodologies are the Waterfall Model, Incremental Development, Evolutionary Model, Object Oriented, and Spiral Model. 

Waterfall model decomposes the development/production cycle of a complex project in four phases (Figure 1.6) ... 

The above description of a waterfall model seems simplistic, but in fact expresses deliberately the key features of a systemic approach of a complex problem. The phases must be clearly defined such as the output of one falls cleanly into the input of the next. 

Waterfall model indicates that the project sequencing should be organised such to avoid feedback between phases, particularly to review the architectural design. This important drawback regarding the flexibility and uncertainty the can be better treated by V-cycle or spiral models explained later. 

The phase concept does not imply that there is a rigid sequence in the development process, as in the waterfall model. Rather, the phase concept also includes an evolutionary prototyping procedure. However, even in evolutionary software development, the following description levels are generally used. Phase models are primarily used because they offer a variety of description objects and methods. 

It is important to stress that the waterfall model does not imply that it is either possible or desirable to attempt to plan every stage of a project in detail at the outset. An obvious example of the difficulties that this would entail is... 

This development model is based on the idea that when risks are prominent, the prudent way to proceed is by a series of iterations where each cycle involves carrying out activities that explore the problem domain and or develop potential solutions in more detail. Each iteration is completed by a control process where the desirability of the next iteration is considered. Each iteration is more detailed and involves a bigger commitment of resources, but should have an increased probability of a successful overall outcome. This model is compatible with a waterfall model if provision is made at the end of each step in the waterfall for the consideration of the advisability of either continuing the project or abandoning it. 

The classic and traditional process model is the waterfall model. This model assumes a sequential order of the phases and the completion of one phase before the next phase starts. 

FIGURE 1 The waterfall model of the software life cycle. 

A common shortcoming of the waterfall model is that it requires a phase to be completed before the next one starts. While feedback loops allow the results of one phase to affect an earlier phase, they still do not allow the overlapping of phases. In practice, a common technique to shorten development times is to carry out activities in parallel. The strict sequential nature of the waterfall model is one of its most severe drawbacks. Other process models try to alleviate this problem. 

The waterfall model defines the requirements at the beginning and delivers the product at the end. During the whole development time, the customer is not involved and does not gain any visibility into the state of the product. Some models try to remedy this problem by introducing different stages in which partial deliveries of the product are made to the customer. 

The spiral model focuses on identifying and eliminating high-risk problems by careful process design, rather than treating both trivial and severe problems uniformly. The spiral model is cyclic rather than linear like the waterfall model. Each cycle of the spiral consists of four stages. 

Waterfall ModeL The waterfall model of software development is characterized hy a sequential software development life cycle. The key characteristic of the waterfall model is that each step of the software development life cycle is completed before going to the next step. The first step is to perform an initial study of the problem to be sure it is feasible. In the second step, a detailed analysis of what the project entails is completed. This is one of the most important components of the waterfall model and often uses a specialist called a systems analyst. In the third step, the information contained in the systems analyst s report... 

Iterated Waterfall and Spiral Model. The iterated waterfall model is, as its name indicates, a modification of the waterfall model that allows programmers to redo a step of the waterfall model. When personal computers became a mainstay in the business world, programmers often had to return to earher steps in the waterfall model and could not finish each step completely. 

The spiral model of software development, introduced by Barry Boehm in 1987, yms the next modification of the waterfall model. Boehm observed that rather than iterating the steps of the waterfidl model, it made more sense to view the process of software development as a spiral of steps, many of which were the steps of the waterfall model. By placing the steps in a spiral, Boehm was able to select subsets of the waterfall model to repeat that more closely followed the actual software development process. 

The principal components of this software development process are presented in Fig. 21.25. Together they form the waterfall life cycle model (Royce, 1970,1987). In actual implementations of the waterfall model variations in the number of phases may exist, naming of phases may differ, and who is responsible for what phase may change. 

In software development, one of the oldest and most well known life cycles is the waterfall model (Royce 1970), which has its most useful incarnation as the V-model and, arguably, this became the de facto standard that is still widely used today (Tschtirtz and Schedl 2010). 

Having reached this point, you may be wondering why all this discussion on life cycles. Well, project managers are simple folk and one thing we know for certain is that life cycles are usefiil management tools, but they are also defect generating processes. To be strictly accurate, the people we let loose on the life cycles are the defect generators, such as Subject Matter Experts (SMEs) like software developers. It s just that some life cycles make it easier than others. The reason the classic waterfall model was replaced by the V-model was to stress the relationship between the early phases of product development and the later phases, and hopefully reduce the introduction of defects in the product. 

---