From a management perspective, the software lifecycle of the Rational Unified Process is decomposed over time in four sequential phases, concluded by a major milestone.
To conclude a phase requires an assessment of whether:
A satisfactory assessment will allow the project to move to the next phase, should the Project Manager so decide. Each phase is essentially a span of time between two major milestones. Click in the figure for more information on a phase or a milestone.
One pass through the four phases is a development cycle; each pass through the four phases produces a generation of the software. Unless the product "dies," it will evolve into its next generation by repeating the same sequence of inception, elaboration, construction and transition phases, but this time with a different emphasis on the various phases. These subsequent cycles are called evolution cycles. As the product goes through several cycles, new generations are produced.
Evolution cycles may be triggered by user-suggested enhancements, changes in the user context, changes in the underlying technology, reaction to the competition, and so on.
The overriding goal of the inception phase is to achieve concurrence among all stakeholders on the lifecycle objectives for the project. The primary objectives of the inception phase include
The essential activities of the inception phase are:
The outcome of the inception phase is:
For a commercial software product, the business case should include a set of assumptions about the project and the order of magnitude return on investment (ROI) if those assumptions are true. For example, the ROI will be a magnitude of five if completed in one year, two if completed in two years, and a negative number after that. These assumptions are checked again at the end of the elaboration phase when the scope and plan are defined with more accuracy.
The resource estimate might encompass either the entire project through delivery, or only an estimate of resources needed to go through the elaboration phase. Estimates of the resources required for the entire project should be viewed as very rough, a "guesstimate" at this point. This estimate is updated in each phase and each iteration, and becomes more accurate with each iteration.
The inception phase may also produce:
At the end of the inception phase is the first major project milestone or Lifecycle Objectives Milestone. At this point, you examine the lifecycle objectives of the project, and decide either to proceed with the project or to cancel it.
The evaluation criteria for the inception phase are:
The project may be aborted or considerably re-thought if it fails to reach this milestone.
The purpose of the elaboration phase is to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the highest risk elements of the project. To accomplish these objectives, you must have the "mile wide and inch deep" view of the system. Architectural decisions have to be made with an understanding of the whole system: its scope, major functionality and nonfunctional requirements, such as performance requirements. It is easy to argue that the elaboration phase is the most critical of the four phases. At the end of this phase, the hard "engineering" is considered complete and the project undergoes its most important day of reckoning, the decision on whether or not to commit to the production phases. For most projects, this also corresponds to the transition from a mobile, low-risk operation to a high cost, high risk operation with substantial inertia.While the process must always accommodate changes, the elaboration phase activities must ensure that the architecture, requirements and plans are stable enough, and the risks sufficiently mitigated to be able to predictably determine the cost and schedule for the completion of the development. Conceptually, this level of fidelity would correspond to that necessary for an organization to commit to a fixed price construction phase.
In the elaboration phase an executable architecture prototype is built in one or more iterations, depending on the scope, size, risk, and novelty of the project. This effort addresses at least the critical use cases identified in the inception phase, which typically expose the top technical risks of the project. While an evolutionary prototype of production-quality components is always a goal, this does not exclude the development of one or more exploratory, throw-away prototypes to mitigate specific risks such as design/requirements trade-offs, component feasibility study, or demonstrations to investors, customers, and end-users. (See Concepts: Prototypes).
The primary objectives of the elaboration phase include:
The essential activities of the elaboration phase are:
The outcome of the elaboration phase is:
At the end of the elaboration phase is the second important project milestone, the Lifecycle Architecture Milestone. At this point, you examine the detailed system objectives and scope, the choice of architecture, and the resolution of the major risks.
The main evaluation criteria for the elaboration phase involve the answers to these questions:
The project may be aborted or considerably re-thought if it fails to reach this milestone.
During the construction phase, all remaining components and application features are developed and integrated into the product, and all features are thoroughly tested. The construction phase is in some sense a manufacturing process, where emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and quality. In this sense the management mindset undergoes a transition from the development of intellectual property during inception and elaboration, to the development of deployable products during construction and transition.
Many projects are large enough that parallel construction increments can be spawned. These parallel activities can accelerate the availability of deployable releases significantly; they can also increase the complexity of resource management and workflow synchronization. A robust architecture and an understandable plan are highly correlated. In other words, one of the critical qualities of the architecture is its ease of construction. This is one reason why the balanced development of the architecture and the plan is stressed during the elaboration phase.
The primary objectives of the construction phase include:
The essential activities of the construction phase are:
The outcome of the construction phase is a product ready to put in the hands of its end-users. At minimum, it consists of:
At the end of the construction phase is the third major project milestone (Initial Operational Capability Milestone). At this point, you decide if the software, the sites, and the users are ready to go operational, without exposing the project to high risks. This release is often called a "beta" release.
The evaluation criteria for the construction phase involve the answers to these questions:
Transition may have to be postponed by one release if the project fails to reach this milestone.
The purpose of the transition phase is to transition the software product into the user community. Once the product has been given to the end user, issues usually arise that require you to develop new releases, correct some problems, or finish some of the features that may have been postponed.
The transition phase is entered when a baseline is mature enough to be deployed in the end-user domain. This typically requires that some usable subset of the system has been completed with acceptable quality level and user documentation so that transition to the user will provide positive results for all parties. This includes: 1) "beta testing" to validate the new system against user expectations, 2) beta testing and parallel operation relative to a legacy system that it is replacing, 3) conversion of operational databases, 4) training of users and maintainers, 5) roll-out to the marketing, distribution and sales forces. The transition phase concludes when the deployment baseline has achieved the completed vision. For some projects this lifecycle end point may coincide with the lifecycle starting point of the next cycle, leading to the next generation or version of the product. For other projects it may coincide with a complete delivery of the artifacts to a third party responsible for operations, maintenance and enhancements of the delivered system.
The transition focuses on the activities required to place the software into the hands of the users. Typically this phase includes several iterations, including beta releases, general availability releases, and bug-fix and enhancement releases. Considerable effort is expended in developing user-oriented documentation, training users, supporting users in their initial product use, and reacting to user feedback. At this point in the lifecycle, however, user feedback should be confined mostly to product tuning, configuring, installing and usability issues.
The primary objectives of the transition phase include:
The essential activities of the transition phase are:
In the transition phase, the activities performed during an iteration depends on the goal: for fixing bugs, implementation and test are usually enough. If new features have to be added, the iteration is similar to the construction phase.
This phase can range from very simple to extremely complex, depending on the kind of product. A new release of an existing desktop product may be very simple, whereas the replacement of a nation's air-traffic control system may be very complex.
At the end of the transition phase is the fourth important project milestone, the Product Release Milestone. At this point, you decide if the objectives were met, and if you should start another development cycle. In some cases this milestone may coincide with the end of the inception phase for the next cycle.
The primary evaluation criteria for the transition phase involve the answers to these questions: