The Rational Unified Process: An Introduction (3rd Edition)

PHASES REVISITED

This section examines in more detail the purpose of each phase and the evaluation criteria used at each major milestone. ^[8]

^[8] The phases were developed in cooperation with Walker Royce, and this section is adapted from Chapter 6 of his book Software Project Management: A Unified Framework . Reading, MA: Addison Wesley Longman, 1998.

THE INCEPTION PHASE

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 following:

• Establish the project's software scope and boundary conditions, including an operational concept, acceptance criteria, and descriptions of what is and is not intended to be in the product.

• Discriminate the critical use cases of the system, that is, the primary scenarios of behavior that will drive the system's functionality and will shape the major design trade-offs.

• Exhibit, and perhaps demonstrate , at least one candidate architecture against some of the primary scenarios.

• Estimate the overall cost and schedule for the entire project and provide detailed estimates for the elaboration phase that will immediately follow.

• Estimate risks (the sources of unpredictability ).

The essential activities of the inception phase are as follows :

• Formulate the scope of the project, that is, capture the context and the most important requirements and constraints so that you can derive acceptance criteria for the end product.

• Plan and prepare a business case and evaluate alternatives for risk management, staffing, project plan, and trade-offs between cost, schedule, and profitability.

• Synthesize a candidate architecture, evaluate trade-offs in design, and assess make/buy/reuse decisions so that cost, schedule, and resources can be estimated.

The outcome of the inception phase is creation of these -artifacts:

• A vision document, that is, a general vision of the core project's requirements, key features, and main constraints

• The use-case model survey, which lists all use cases and actors that can be identified at this early stage

• An initial project glossary

• An initial business case, which includes

  • Business context

  • Success criteria (revenue projection, market recognition, and so on)

  • Financial forecast

• An initial risk assessment

• A project plan, which shows the phases and iterations

For a commercial software product, the business case should include a set of assumptions about the project and the order of magnitude of the return on investment (ROI) if these assumptions are true. For example, the ROI will be a magnitude of five if the project is completed in one year, two if it is 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 to delivery or only the resources needed for 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 during each phase and each iteration and becomes more accurate with each iteration.

The inception phase may also produce the following artifacts:

• An initial use-case model (10% to 20% complete) when dealing with an initial development cycle

• A domain model, which is more sophisticated than a glossary (see Chapter 9)

• A business model if necessary (see Chapter 8)

• A preliminary development case description to specify the process used (see Chapter 17)

• One or several prototypes (see Chapter 11)

Milestone: Lifecycle Objective

At the end of the inception phase is the first major project milestone: the lifecycle objective milestone. The evaluation criteria for the inception phase are as follows:

• Stakeholder concurrence on scope definition and cost and schedule estimates

• Requirements understanding as evidenced by the fidelity of the primary use cases

• Credibility of the cost and schedule estimates, priorities, risks, and development process

• Depth and breadth of any architectural prototype that was developed

• Actual expenditures versus planned expenditures

If the project fails to pass this milestone, it may be canceled or considerably rethought.

The Elaboration Phase

The purpose of the elaboration phase is to analyze the problem domain, establish a sound architectural foundation, develop the project plan, and eliminate the project's highest-risk elements. To accomplish these objectives, you must have a "mile wide and inch deep" view of the system. Architectural decisions must 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 of whether to commit to the construction and transition phases.

For most projects, this phase corresponds to the transition from a mobile, nimble , low-risk operation to a high-cost, high-risk operation that has substantial inertia. Although the process must always accommodate changes, the elaboration-phase activities ensure that the architecture, requirements, and plans are stable enough, and the risks are sufficiently mitigated, that you can predictably determine the cost and schedule for the completion of the development. Conceptually, this level of fidelity corresponds to the level 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. At minimum, this effort should address the critical use cases identified in the inception phase, which typically expose the project's major technical risks. Although an evolutionary prototype of a production-quality component is always the goal, this does not exclude the development of one or more throw-away prototypes to mitigate a given risk or explore some trade-offs between design and requirements. Nor does it rule out a feasibility study or demonstrations to investors, customers, and end users.

The primary objectives of the elaboration phase include the following:

• Define, validate, and baseline ^[9] the architecture as rapidly as practical.

  ^[9] To baseline is to create a baseline, a reference; that is, to put a validated release under configuration control so that it can serve as the starting point and reference for further development.

• Baseline the vision.

• Baseline a high-fidelity plan for the construction phase.

• Demonstrate that the baseline architecture will support this vision for a reasonable cost in a reasonable time.

The essential activities of the elaboration phase are as follows:

• The vision is elaborated, and a solid understanding is established of the most critical use cases that drive the architectural and planning decisions.

• The process, the infrastructure, and the development environment are elaborated, and the process, tools, and automation support are put into place.

• The architecture is elaborated and the components are selected. Potential components are evaluated, and the make/buy/reuse decisions are sufficiently understood to determine the construction-phase cost and schedule with confidence. The selected architectural components are integrated and assessed against the primary scenarios. Lessons learned from these activities may result in a redesign of the architecture, taking into consideration alternative designs or reconsideration of the requirements.

The outcomes of the elaboration phase are as follows:

• A use-case model (at least 80% complete) in which all use cases have been identified in the use-case model survey, all actors have been identified, and most use-case descriptions have been developed

• Supplementary requirements that capture the nonfunctional requirements and any requirements that are not associated with a specific use case

• A software architecture description

• An executable architectural prototype

• A revised risk list and a revised business case

• A development plan for the overall project, including the coarse-grained project plan, which shows iterations and evaluation criteria for each iteration

• An updated development case that specifies the process to be used

• A preliminary user manual (optional)

Milestone: Lifecycle Architecture

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 the following questions:

• Is the vision of the product stable?

• Is the architecture stable?

• Does the executable demonstration show that the major risk elements have been addressed and credibly resolved?

• Is the construction phase plan sufficiently detailed and accurate? Is it backed up with a credible basis for the estimates?

• Do all stakeholders agree that the current vision can be achieved if the current plan is executed to develop the complete system, in the context of the current architecture?

• Is the actual resource expenditure versus planned expenditure acceptable?

If the project fails to pass this milestone, it may be aborted or considerably rethought.

The Construction Phase

During the construction phase, all remaining components and application features are developed and integrated into the product, and all features are tested thoroughly. The construction phase is, in one sense, a manufacturing process in which emphasis is placed on managing resources and controlling operations to optimize costs, schedules, and quality. In this sense, the management mind-set 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 significantly accelerate the availability of deployable releases; 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 that the balanced development of the architecture and the plan is stressed during the elaboration phase.

Primary construction phase objectives include the following:

• Minimize development costs by optimizing resources and avoiding unnecessary scrap and rework .

• Achieve adequate quality as rapidly as practical.

• Achieve useful versions (alpha, beta, and other test releases) as rapidly as practical.

The essential activities of the construction phase are as follows:

• Resource management, resource control, and process optimization

• Complete component development and testing against the defined evaluation criteria

• Assessment of product releases against acceptance criteria for the vision

The outcome of the construction phase is a product ready to put in the hands of its end users. At minimum, it consists of the following:

• The software product integrated on the adequate platforms

• The user manuals

• A description of the current release

Milestone: Initial Operational Capability

At the end of the construction phase is the third major project milestone: initial operational capability. At this point, you are to decide whether the software, the sites, and the users are ready to become operational without exposing the project to high risks. This release is often called a beta release.

The evaluation criteria for the construction phase involve answering the following questions:

• Is this product release stable and mature enough to be deployed in the user community?

• Are all stakeholders ready for the transition into the user community?

• Are the actual resource expenditures versus planned expenditures still acceptable?

Transition may have to be postponed by one release if the project fails to reach this milestone.

The Transition Phase

The purpose of the transition phase is to move the software product to the user community. After the product has been given to the end user, issues usually arise that require you to develop new releases, correct some problems, or the finish features that were postponed.

The transition phase is entered when a baseline is mature enough to be deployed in the end-user domain. Typically, this means that some usable subset of the system has been completed to an acceptable level of quality and that user documentation is available so that the transition to the user will provide positive results for all parties. This phase includes the following:

• Beta testing to validate the new system against user expectations

• Parallel operation with the legacy system that the project is replacing

• Conversion of operational databases

• Training of users and maintainers

• Rollout of the product to the marketing, distribution, and sales teams

The transition phase concludes when the deployment baseline has achieved the completed vision. For some projects, this lifecycle endpoint may coincide with the starting point of the next cycle, leading to the next generation or version of the product. For other projects, it may coincide with a delivery of the artifacts to a third party responsible for operation, maintenance, and enhancements of the delivered system.

The transition phase focuses on the activities required to place the software into the hands of the users. Typically, this phase comprises 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 the initial use of the product, and reacting to user feedback. At this point in the lifecycle, however, user feedback should be confined primarily to product tuning, configuring, installation, and usability issues.

The primary objectives of the transition phase include the following:

• Achieve user self-supportability.

• Achieve stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision.

• Achieve final product baseline as rapidly and cost-effectively as practical.

The essential activities of the transition phase are as follows:

• Deployment-specific engineering, that is, cutover, commercial packaging and production, sales rollout, and field personnel training

• Tuning activities, including bug fixing and enhancement for performance and usability

• Assessing the deployment baselines against the vision and the acceptance criteria for the product

In the transition phase, the activities performed during an iteration depend on the goal; for fixing bugs , implementation and testing are usually enough. If new features must be added, the iteration is similar to those of the construction phase.

Depending on the type of product, this phase can range from simple to extremely complex. For example, a new release of an existing desktop product may be simple, whereas replacing a nation's air-traffic control system would be complex.

Milestone: Product Release

At the end of the transition phase is the fourth important project milestone: the product release milestone. At this point, you decide whether the objectives were met and whether 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 the following questions:

• Is the user satisfied?

• Are the actual resources expenditures versus planned expenditures still acceptable?