The RUP ”The Approach In this section we discuss the essential principles the RUP uses to facilitate successful software development, as well as the keystone iterative approach to applying those principles. Underlying Principles of the RUP Approach At the core of the Rational Unified Process lie several fundamental principles that support successful iterative development and that represent the essential "Spirit of the RUP" (which is discussed in Chapter 2). These principles were gleaned from a huge number of successful projects and distilled into a few simple guidelines. These principles are listed here: -
Attack major risks early and continuously. . . or they will attack you. [1] Rather than addressing business risks, technical risks, or other risks later in a project, identify and attack major risks as early as possible. [1] See Gilb 1988. -
Ensure that you deliver value to your customer. Document the requirements in a form that is easily understood by customers, but work closely to the requirements through design, implementation, and testing phases to ensure that you also deliver the requirements. The Spirit of the RUP Essential Principles -
Attack major risks early and continuously or they will attack you. -
Ensure that you deliver value to your customer. -
Stay focused on executable software. -
Accommodate change early in the project. -
Baseline an executable architecture early on. -
Build your system with components . -
Work together as one team. -
Make quality a way of life, not an afterthought. | -
Stay focused on executable software. Documents, designs, and plans are all good, but they are a poor indication of true progress because their evaluation is subjective and their importance is secondary compared to the code itself. Executable code that compiles and successfully passes tests is the best indication of progress. -
Accommodate change early in the project. Today's applications are too complex to enable us to get the requirements, design, and implementation correct the first time. This means that to develop a good enough system, we need to allow and adapt to change. -
Baseline an executable architecture early on. Many project risks can be mitigated by designing, implementing, and testing the architecture early in the project. Establishing a stable architecture early on also facilitates communication and localizes the impact of changes. -
Build your system with components. Applications built with components are more resilient to change and can have radically reduced system maintenance cost. Components facilitate reuse, allowing you to build higher quality applications faster than using functional decomposition. -
Work together as one team. Software development has become a team sport, [2] and an iterative approach emphasizes the importance of good team communications and a team spirit where each team member feels responsible for the completed end product. [2] See Booch 2001. -
Make quality a way of life, not an afterthought. Ensuring high quality involves more than just the testing team. It involves all team members and all parts of the lifecycle. An iterative approach focuses on early testing and test automation for more effective regression testing, thus reducing the number of defects. These principles are covered in more detail in Chapter 2. The RUP and Iterative Development Most software teams still use a waterfall process for development projects, where they complete each phase in a strict sequence of requirements, then analysis and design, then implementation/integration, and then testing. Or, more commonly, a modified waterfall approach with feedback loops added to the basic overall flow just describ7ed. Such approaches leave key team members idle for extended periods of time and defer testing until the end of the project lifecycle, when problems tend to be tough and expensive to resolve, and pose serious threats to release deadlines. By contrast, the RUP uses an iterative approach (iterate = repeat), that is, a sequence of incremental steps or iterations. Each iteration includes some, or most, of the development disciplines (requirements, analysis, design, implementation, and so on), as you can see in Figure 1.1. Each iteration has a well-defined set of objectives and produces a partial working implementation of the final system. Each successive iteration builds on the work of previous iterations to evolve and refine the system until the final product is complete. Figure 1.1. Iterative Development in the RUP. The Rational Unified Process promotes an iterative approach ”in each iteration you do a little requirements, analysis, design, implementation, and testing. Each iteration builds on the work of the previous iterations to produce an executable that is one step closer to the final product.  Early iterations will have a greater emphasis on requirements and analysis and design; later iterations will have a greater emphasis on implementation and testing. The iterative approach has proven itself superior to the waterfall approach for a number of reasons: -
It accommodates changing requirements. Requirements change and "feature creep" ”the addition of features that are technology or customer-driven ”have always been primary sources of project trouble, leading to late delivery, missed schedules, dissatisfied customers, and frustrated developers. Instead, iterative development focuses the team on producing and demonstrating executable software in the next few weeks, which forces a focus on the most essential requirements. -
Integration is not one " big bang " at the end of a project. Leaving integration to the end results in time-consuming rework ”sometimes up to 40 percent of the total project effort. To avoid this, an iterative approach breaks a project down into smaller iterations, each ending with an integration in which building blocks are integrated progressively and continuously, minimizing later rework . -
Risks are usually discovered or addressed during early integrations. The RUP's integrated approach mitigates risks in early iterations, where all process components are tested . Since each iteration exercises many aspects of the project, such as tools, off-the-shelf software, and team members' skills, you can quickly discover whether perceived risks prove to be real and also uncover new, unsuspected risks at a time when they are easier and less costly to address. -
Management has a means of making tactical changes to the product ” to compete with existing products, for example. Iterative development quickly produces an executable architecture (albeit of limited functionality), which can be used for quick release of a product with a reduced scope to counter a competitor's move. -
Reuse is facilitated. It is easier to identify common parts as they are being partially designed or implemented in iterations, than to recognize them during planning. Design reviews in early iterations allow architects to spot potential opportunities for reuse and then develop and mature common code for these opportunities in subsequent iterations. -
Defects can be found and corrected over several iterations, resulting in a robust architecture and a high-quality application. Flaws are detected even in early iterations rather than during a massive testing phase at the end. Performance bottlenecks are discovered at a time when they can still be addressed, instead of creating panic on the eve of delivery. -
It is a better use of project personnel. Many organizations match their use of a waterfall approach with a pipeline organization: The analysts send the completed requirements to designers, who send a completed design to programmers, who send components to integrators, who send a system to testers. These many handoffs are sources of errors and misunderstandings and make people feel less responsible for the final product. An iterative process widens the scope of expertise of the team members, allowing them to play many roles and enabling a project manager to use the available staff better, while simultaneously removing harmful handoffs. -
Team members learn along the way. The project members have several opportunities along a development cycle to learn from their mistakes and to improve their skills from one iteration to another. More training opportunities can be discovered as the result of assessing the earlier iterations. In contrast, in a waterfall approach, you have only one shot at design or coding or testing. -
The development process itself is improved and refined along the way. The assessment at the end of an iteration not only looks at the status of the project from a product or scheduling perspective, but also analyzes what, in both the organization and the process, can be improved in the next iteration. Some project managers resist the integrated approach, seeing it as a kind of endless and uncontrolled hacking. In the Rational Unified Process, the integrated approach is very controlled: The number, duration, and objectives of iterations are carefully planned, and the tasks and responsibilities of participants are well defined. Additionally, objective measures of progress are captured. Some reworking takes place from one iteration to the next, but this, too, is carefully controlled. |
