The Gateway to RUP

We like symbols, icons, and logos, and the first RUP icon that comes to mind is the "Hump Chart" (see Figure A.1). The "Hump Chart" is a gateway into RUP and the generic disciplines that describe best practices for object-oriented software engineering.

Figure A.1. The RUP "hump" chart ^[*]

^[*] 2003 Rational Software Corporation. All rights reserved. This graphic is used with permission of IBM Corporation.

Disciplines, listed to the left of the chart, group related activities pertaining to major areas of concern within the context of a software development project. If you read down from Business Modeling to Environment, you might get the impression that RUP is a traditional "waterfall" development methodology. This isn't the case.

Most software development projects aren't clearly defined at the beginning of the project, and require several cycles to arrive at the ultimate solution. So RUP is an iterative and incremental software development process.

RUP suggests that software is developed over a number of phases, each of which consists of one or more iterations. The humps suggest the level of effort required over time for each of the disciplines. ^[2]

^[2] These are examples of the effort you might expend on a project. Every project is different. People have told us that their projects had different effort profiles and they wondered what they were doing wrong. We gently told them to use the humps on the chart as guidelines, not as rigid prescriptions for every project.

For example, the Requirements discipline requires much effort in the Inception and early Elaboration phases, but dwindles in the later phases as build targets are set and requirements are frozen. However, RUP doesn't close the door on Requirements activities in the later phases when change requests , or real changes to the customer needs and business conditions, happen. The amount of effort you put into managing requirements should decrease as the project proceeds, but not always. A spike in Requirements activities towards the end of the project may mean that the real customer requirements weren't understood until late, when it may be expensive to make structural changes. To draw on a house-building analogy, it's much better to decide where to locate kitchens and bathrooms early in a construction project; it can be devastating (to schedules and budgets , at least) to make this decision late in the project. But, in software projects, it's quite possible that the changes are necessary and your process must be configured to adequately deal with them.

Phases

RUP describes four phases (Inception, Elaboration, Construction and Transition) that a project goes through. The Inception phase is about creating a vision, developing a business case, and assembling a software prototype ”or partial solution ”so that the endeavor gets support and funding. The Elaboration phase ends with an executable architecture where the key architectural decisions have been made and risks have been mitigated. The executable architecture is working software that exhibits an implementation of the key architectural decisions. The Construction phase is about filling out the functionality identified in the architecture, and the Transition phase focuses on delivering the software to its users.

Phases are divided into iterations. Iterations are " time-boxed " and have specific goals. The iterations are kept as short as possible, but long enough for you to implement complete use cases or use-case scenarios that provide real value to the user . At the end of each iteration, you hold an assessment where you adjust plans for future iterations, based on the results of the current iteration. During the assessment, your team also reflects on the efficacy of the process and adjusts it as necessary. RUP is all about creating a vision of what you want, creating a framework for getting there, and assessing at given points whether you are headed where you intend to go.