The Rational Unified Process

Related Sites

[...] Accordingly to The Unified Software Development Process by Jacobson et al., every 'software life cycle' is 'a cycle over four phases in the following order: inception, elaboration, construction, transition'. A 'phase' is 'the span of time between two major milestones in the software development process'. And 'major milestones' can be thought of '... as synchronization points where a well-defined set of objectives is met, artifacts are completed, decisions are met to move or not to into the next phase, and where the managerial and the technical realm conjuncts'. [...]

And the core of the [phases] is state-based, and the state is determined by what fundamental questions you are trying to answer:

• Inception - do you and the Customer have a shared understanding of the system?
• Elaboration - do you have an architecture to be able to build the system?
• Construction - are you developing product?
• Transition - are you trying to get the Customer to take ownership of the system?

[...]

The inception phase contains whatever workflows are necessary to get the stakeholders to agree (the keyword there is agree, and not "have sure knowledge") on the objectives, rough architecture, and rough schedule of the project. [...] If the stakeholders are extremely knowledgeable, then little analysis will be required. If they need to be severely educated, then lots of analysis will be required.

[...]

The essence of RUP is iteration. And the essence of iteration is that each iteration ends in a deliverable -- preferably one that executes. Even in inception, you are going to want a few iterations that show growing functionality. During inception you will gather a significant (a half? a third? it depends...) fraction of the use cases. You will focus on those that seem to be central or key. The iterations will be implementing some of these.

During elaboration you will tighten up your architecture and your plan. The nature of the iterations won't necessarily change much; but the longevity of the software produced will certainly increase. Early iterations (usually in the inception phase) have a tendency to get thrown out. During elaboration you will discover the rest of the use cases (or at least their first approximations) and will implement the minimal set.

During construction you will drive towards giving the customer the minimum system that they need. The nature of the iterations won't change much, but your focus will be on identifying the smallest possible deliverable that will still meet at least some of the customers needs. During construction, the use cases will change a bit as the customer sees the growing system and feeds changes back to you.

During transition, you will drive towards fleshing out the functionality of the system, and incorporating the mounds of customer feedback that you are surely to get. The nature of your iterations won't change much. During transition the use cases are likely to undergo drastic changes as the customers actually use the system and realize that it is not exactly what they needed.

Again, the essence of RUP is iteration, and the essence of iteration is the production of executable deliverables. You may also be producing UML diagrams, or some other form of model too. Such models take two forms. One is a model of the architecture which is seeded during inception and established during elaboration. This model is likely to be a permanent document. The other kind of model is created at the beginning of each iteration, as a way to plan what the structure of the iteration will look like. These models are most likely temporary documents. You might find a few that are essential and should be retained; but many will be discardable.

[...]

The transition from phase to phase is gradual. [...] Management is not done by placing dates upon the phase boundaries. Nor are there phase gate events that mark the transition from one to another. Rather, management is done based upon iterations of the development. The first iterations start in the inception phase.

[...]

The project plan is pretty straightforward. It contains a list of proposed iterations (which all parties agree is likely to change). Each proposed iteration has an estimate (which all parties agree are likely to change). The proposed iterations are not assigned dates. Rather decision points are identified. For example:

1. by week 6, if iteration 1 and 2 are not complete, then hire one additional person.
2. by week 10, if iterations 1-4 have not been accepted by the customer, then remove iteration 8 from the release.
3. by week 15, if iterations 1-4 have not been accepted by the customer, then cancel the project.

As the project proceeds, we will learn more about how quickly the iterations are developed. We'll learn about the iterations that we forgot when we made the project plan. The customer will see the developing project and will change the requirements.. Thus, the plan must be malleable, flexible, and responsive.

Rational, Rational Unified Process - Best Practices for Software Development Teams

Philippe Kruchten, The Rational Unified Process - An Introduction

Ivar Jacobson, Grady Booch, and Jim Rumbaugh, Unified Software Development Process