Going Over the Waterfall with the RUP by Philippe Kruchten (131 K) Rational FellowWhen discussing the software development lifecycle, there is a temptation to quickly label the waterfall model as "bad." Instead of making hasty conclusions, we should ask questions. What is the right development lifecycle for my project? Is the waterfall lifecycle bad for this project? Or what about aligning the waterfall lifecycle with the Rational Unified Process? This last idea may sound like an oxymoron, as the Rational Unified Process® (RUP®) is touted as an iterative development process, and it holds "develop iteratively" as its number one best practice1. However, as many organizations are using an overall waterfall approach to system development, it makes sense to try to see how the two apparently conflicting lifecycle models might pair up, and how the RUP can be effectively used within an encompassing waterfall framework. There are many reasons why you may need to insert the RUP into a waterfall lifecycle:● To match your software development approach to the development approach of a bigger system. ● To comply with externally imposed standards, especially in a bidding and contracting situation, where intermediate milestones are linked to the delivery of specific artifacts in sequential order. ● To deal with simple situations, like maintenance cycles, for which iterating might be overkill.● Or, more simply, to introduce the RUP into an organization in which the waterfall mindset is very entrenched, and to avoid making too many changes at once. First you introduce some aspect(s) of the RUP, and then gradually shift to iterative development. Copyright Rational Software 2001 http://www.therationaledge.com/content/sep_01/t_waterfall_pk.htmlAligning the Traditional Waterfall Review Sequence with the Iterative ApproachThe following text is extracted from the RUP8. It matches the RUP iterations with some typical reviews found in traditional waterfall processes, such as DOD-STD-2167A and MIL-STD-498. The default review sequence for a waterfall lifecycle project is a major review upon completion of each important artifact. For example: ● System Requirements Review (SRR), at the completion of the system specification. ● Software Specification Review (SSR), at the completion of the software requirements specification.● Preliminary Design Review (PDR), at the completion of the architectural design sections of the software design description.● Critical Design Review (CDR), at the completion of the detailed design sections of the software design description.Continued... Waterfall Lifecycle vs. Iterative LifecycleIn software engineering, we inherited the waterfall lifecycle from other engineering disciplines, where it has proven very effective. It was first formally described for software by Winston Royce in 19702, in rather cautious terms. Since then it has been a bit abused by organizations that used it blindly in circumstances for which it was not suitable. The waterfall lifecycle goes through a series of phases (see Figure 1): 1. requirements (system requirements, then software requirements)2. requirements analysis3. software design4. coding and unit testing5. integration6. system test7. operationsThere is minimal feedback from one phase to another. Also, there is often only a small set of artifacts (also called "workproducts," which can include documents, models, or code) that is produced in each phase, validated at the end of the phase, and then used as input for the next phase. These artifacts are considered complete, almost frozen, and revisited only to fix a major issue. Figure 1: A Waterfall LifecycleOf paramount importance for certain projects is the issue of freezing the requirements specifications (together with some high-level design) in a contractual arrangement very early in the lifecycle, prior to engaging in more thorough design and implementation work. This is the case when an organization has to bid a firm, fixed price for a project. In contrast, an iterative lifecycle exploits the "soft" nature of software, and proceeds by developing in iterations that encompass the activities of requirements analysis, design, implementation, integration, and test. One of the best descriptions is in Professor Barry Boehm's paper on the "spiral" model3. You can summarize it with the catch phrase, "Analyze a little, design a little, test a little, and loop back." See Figure 2. In the iterative lifecycle model, artifacts are in some ways "grown" or "refined," from one cycle of the spiral to another. They are not thrown away or frozen, but rather expanded. The early iterations produce a very small system, which gradually expands over a series of iterations to become the complete system. Feedback takes place from one iteration to the next. Figure 2: An Iterative Development LifecycleChapter 1 of Walker Royce's book on software project management4 has a longer discussion of the contrast between the two approaches. The Rational Unified ProcessThe RUP offers two major components to a software development organization: 1. A flexible, iterative lifecycle that must be tailored by the project manager to the exact project circumstances.2. A set of recipes: techniques, templates, "job" descriptions, and tools that will guide the software developers in their daily work.The iterative lifecycle is of importance mostly for the project manager in setting up the project plan. The rest of the process, which constitutes about 95 percent of the RUP guidance, is described in the form of: ● Roles: competencies and responsibilities.Examples: Designer, Tester● Activities: what people do (the recipe). These are associated withGuidelines, which describe techniques and heuristics; and with Tool Mentors, which explain how to use certain tools to perform the activity.Examples: Integrate Subsystem, Code a Class● Artifacts: things (documents, models, code, and so on) that are created or evolved, together with Templates for these artifacts, and Examples, for clarification and inspiration.Examples: Design Model, Test Plan The two major components of the RUP -- the lifecycle and the "how to" or guidance -- are not completely tied together. If you wish, you can adopt the RUP lifecycle and some of the techniques, or you can adopt most of the techniques but not the lifecycle. Iterative Lifecycle: Iterations, Builds, and PhasesWe saw in the first section what happens over time in a waterfall lifecycle.Let's