| For many years, and even today, many projects have used a traditional process commonly called the Waterfall lifecycle process, shown in Figure 2-1. Even if you are unfamiliar with this term, you have probably used this lifecycle before without knowing it. The basic tenets of the Waterfall lifecycle are as follows: You cannot effectively create or build anything until you know the requirements. Development should not begin until the requirements have been completely collected and frozen, because you don't want to have to redo work that has been completed. You cannot begin work on a subsequent phase of the project until the preceding phase is complete.
Figure 2-1. Phases of the Waterfall lifecycle model 
In addition to the preceding basic tenets, some practices are commonly associated with use of the Waterfall process: Requirements and design are extensively documented. Reviews of documentation are conducted at significant project milestones: Preliminary Design Review (PDR) Critical Design Review (CDR) Test Readiness Review (TRR)
Detailed project planning and scheduling for the entire project are performed at the beginning of the project. Success is measured by adherence to the milestones and dates in the original detailed project plan.
Advantages of the Waterfall Process The Waterfall process has been around for many years. It began long before large software development projects were common. The Waterfall process originated in the manufacturing sector. It has been practiced in the manufacturing and building construction industries for many years and is well understood through years of application. Given that the main topic of this book is applying the RUP, you might expect to see the horrors of the Waterfall process revealed here. Although this process certainly has some disadvantages, it also has many advantages. It is still commonly used, and it will continue to be used. The key is applying the right process to the situation at hand. Let's start by listing the advantages of the Waterfall process: It's intuitively obvious what activities should be conducted at a given point in time. As a result, it's an easy process to learn. It's easy to determine staffing needs, because each phase requires a specific skill set during a specific time period. It's easy to schedule. It's easy to gauge apparent progress by comparing work completed with the expected completion of work according to the schedule.
Based on these advantages, the Waterfall lifecycle is well suited for projects that have the following characteristics: The requirements are known completely at the beginning of the project and do not change significantly for the duration of the project. The requirements are understood completely at the beginning of the project. The risks are identified and understood at the beginning of the project. It is known that the requirements can be implemented utilizing the technologies to be used for the project. The technologies employed on the project do not change for the duration of the project. The team assembled for the project is experienced and familiar with the problem domain and the technologies applied on the project.
A project exhibiting these characteristics is an excellent candidate for the Waterfall process. Disadvantages of the Waterfall Process The Waterfall process actually has few disadvantages per se. The problems with using the Waterfall process stem from applying it to projects with the wrong characteristics. Let's revisit the list of characteristics of projects that are well suited for the Waterfall process. This provides a convenient way to discuss the problems created by the mismatch of situation and process. The requirements are known completely at the beginning of the project and do not change significantly for the duration of the project. This is not the situation for most software projects of significant size today. With many projects, the stakeholders must be carefully guided through a requirements elicitation process. In most cases, users are unable to articulate what they truly want or need, but they know what they like when they see it. This is related to requirements changing. As stakeholders learn, they become better able to articulate their needs. Significant changes are the bane of the Waterfall process. Why? The Waterfall process is strictly sequential. After you have completed the Requirements and Design phases, the process dictates that you work on implementation. A contractor will strongly resist new or changed requirements at this point, because it means going backwardrevisiting existing work and modifying it to accommodate the changes and additions. This results in delays and increased expenditure of resources. The requirements are understood completely at the beginning of the project. For a system to meet the needs of its stakeholders, the requirements articulated by those stakeholders must be completely understood by the system's creators and builders. This takes much more than simply reading documents provided by stakeholders at the beginning of the project. It involves working closely with the stakeholders over a period of time. Furthermore, the burden is on the contractor to convince the stakeholders that this understanding has been achieved. This can be difficult to do with a Waterfall lifecycle. Typical lifecycle milestones in the Waterfall process, such as Preliminary Design Review and Critical Design Review, assess status and understanding through documentation of design, snapshots of screen prototypes, and other "static" artifacts. Seldom are there any interactive, executable implementations, or partial implementations. Nothing is coded or implemented until the Implementation phase, which occurs after the Critical Design Review. Therefore, understanding of requirements is based on assessment of documentation. Furthermore, some of the documentation consists of design diagrams that the stakeholders might not understand. Overall, extensive documentation is not a reliable predictor of ultimate project success. The risks are identified and understood at the beginning of the project. There is no way to completely discover and eliminate all risks on a software project of significant size, regardless of the process used. The phrase "You don't know what you don't know" comes to mind. The best you can do is engage in activities that allow you to discover the risks early enough to be able to take action to mitigate them. In the Waterfall process, each phase is conducted once. Let's examine examples of risk discovery in a typical project using the Waterfall process. Figure 2-2 shows three unexpected risks that were discovered at different points in the project lifecycle. Figure 2-2. Risk discovery in the Waterfall lifecycle process  Risk 1 was discovered during the Requirements Elicitation and Analysis phase. Because it was discovered fairly early in the lifecycle, it may be possible to take corrective action without much difficulty. Risk 2 was experienced during the Implementation phase, roughly halfway through the project schedule, after approximately one-half of the project resources had been expended. Depending on the nature of the risk, it may be possible to recover, but not without some heroic action on the part of the project staff. Risk 3, on the other hand, is discovered late in the project lifecycle, not far from project delivery, after most of the project funds are exhausted. Chances are if this risk has a serious impact, this project will not be delivered on time. Given that Risks 2 and 3 were disruptive because they were encountered near the middle and end of the project lifecycle, how can you discover them earlier so that they won't be so disruptive? The answer is that you can't if you are using a Waterfall lifecycle. The section "Practice 4: Demonstrate Value Iteratively" explains how iterative development, one of the six best practices emphasized by the RUP, helps with this situation. It is known that the requirements can be implemented utilizing the technologies to be used for the project. In many cases, the technologies already have been selected for implementation of the project requirements by the time Requirements Elicitation and Analysis takes place. Furthermore, requirements are elicited strictly from the user's perspective, without regard for the implementation technology (as it should be!). Occasionally, a situation occurs in which implementation of some requirements may not be possible, or perhaps it is unusually difficult, with the technologies chosen. With the Waterfall process, Implementation does not begin until the Requirements and Design phases are complete. This means that discovery of problems is likely to be delayed. In addition, when the problem is discovered, you must spend time re-eliciting the requirements and altering the design to accommodate the changed requirements, increasing the delay. The technologies employed on the project do not change for the duration of the project. Given the rate at which new developments in hardware and software are being introduced to the marketplace, any project lasting longer than a year or so is likely to experience this situation. The question is whether the customer wants to incorporate the new technology into the product being built. In the Waterfall lifecycle process, introducing new technologies during the Implementation or Integration and Test phases is both risky and disruptive. Depending on the nature of the changes, close examination (and possibly significant rework) from the artifacts produced in the first two phases must be performed. If significant rework is required, forward progress slows or even stops as this examination takes place. In some cases, project managers, under schedule and budget pressure, try to skip this examination and incorporate the technologies by shear brute force, without determining whether the changes are compatible with the work done so far. The risks of this approach tend to surface during Integration and Test. At that point, correcting the problems guarantees that the project will be late. The team assembled for the project is experienced and familiar with the problem domain and the technologies applied on the project. This issue relates to risks and understanding requirements. Clearly, if the project team has built similar systems, they will have encountered and mitigated the risks that are likely to occur on the current project. In addition, because the team is already familiar with similar systems, they will be better able to guide the users during requirements elicitation. This also means the team can incorporate lessons learned from their earlier experiences and thus are less likely to repeat mistakes. Because the Waterfall lifecycle does not easily allow for correction of mistakes made in earlier phases, having an experienced team is a key advantage for Waterfall-based projects. Unfortunately, turnover within the software development industry tends to be fairly high. Software developers also like new challenges and may be unlikely to sign on for a project similar to one they have done previously. Finally, even if the developers have completed similar projects, the technologies may not be the same as those employed on the earlier project, negating the applicability of some of the lessons learned on earlier projects.
The development of new software systems more closely resembles the invention of a new product. Each project typically involves new stakeholders, technologies, project personnel, tools, risks, and environments for both the creation and operation of the project. As a consequence, these projects cannot be easily planned or predicted months in advance. A more flexible approach that is resilient to change and discovery is needed. The Waterfall approach generally involves detailed planning for the entire project before the project even begins. The nature of software development makes this impractical and unreliable. It is clear that many software development situations call for approaches other than the Waterfall process. One such approach is the RUP. |
