Concepts: Project Lifecycle, Phases and Major Milestones

Topics

• Explanation
• The Inception Phase
• The Elaboration Phase
• The Construction Phase
• The Transition Phase

Explanation

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.

• The inception phase:
  where we define a 'vision' of the end-product and the associated business case, defining the overall scope of the project.
  
• The elaboration phase:
  where we refine the definition of the product, define and baseline an architecture, and develop a more precise plan for its development and deployment.
   
• The construction phase:
  where the product is built, up to the point where it can be put in the hands of its end-users for the first time.
  
• The transition phase:
  where the product is transitioned to the user community; this includes manufacturing, delivering, training, supporting and maintaining the product.

To conclude a phase requires an assessment of whether:

• the defined objective have been met;
• the defined artifacts have been completed;
• the various models have been updated.

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

• Establishing the project's software scope and boundary conditions, including an operational concept, acceptance criteria and what is intended to be in the product and what is not.
• Discriminating the critical use cases of the system, the primary scenarios of operation that will drive the major design trade-offs.
• Exhibiting, and maybe demonstrating, at least one candidate architecture against some of the primary scenarios
• Estimating the overall cost and schedule for the entire project (and more detailed estimates for the elaboration phase that will immediately follow)
• Estimating potential risks (the sources of unpredictability) (See Concepts: Risk)

The essential activities of the inception phase are:

• Formulating the scope of the project. This involves capturing the context and the most important requirements and constraints to such an extent that you can derive acceptance criteria for the end product.
• Planning and preparing a business case. Evaluating alternatives for risk management, staffing, project plan, and cost/schedule/profitability trade-offs.
• Synthesizing a candidate architecture, evaluating trade-offs in design, and in make/buy/reuse, so that cost, schedule and resources can be estimated.

The outcome of the inception phase is:

• A vision document: a general vision of the core project's requirements, key features, main constraints.
• The use-case model survey (identifying all use cases that can be identified at this early stage).
• An initial 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, showing 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 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:

• An initial use-case model, and domain model (10%-20%), when dealing with an initial development cycle.
• A domain model
• A business model
• A preliminary development case description, see the Introduction to Environment.
• One or several prototypes (see Concepts: Prototypes).

Milestone 

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:

• Stakeholder concurrence on scope definition and cost/schedule estimates
• Requirements understanding as evidenced by the fidelity of the primary use cases
• Credibility of the cost/schedule estimates, priorities, risks, and development process
• Depth and breadth of any architectural prototype
• Actual expenditures versus planned expenditures.

The project may be aborted or considerably re-thought if it fails to reach this milestone.

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

• Defining, validating and baselining the architecture as rapidly as practical
• Baselining the vision
• Baselining a high-fidelity plan for the construction phase
• Demonstrating that the baseline architecture will support this vision for reasonable cost in a reasonable time.

The essential activities of the elaboration phase are:

• Elaborating the vision establishing a solid understanding of the most critical use cases that drive the architectural and planning decisions.
• Elaborating the process and the infrastructure, the development environment. Putting in place the process, tools and automation support.
• Elaborating the architecture and selecting components. Potential components are evaluated and the make/buy/reuse decisions 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 well result in a redesign of the architecture, taking into consideration alternative designs or reconsideration of the requirements.

The outcome of the elaboration phase is:

• A use-case model (80% complete) - all use cases having been identified in the use-case model survey, all actors having been identified, and most use-case descriptions (requirements capture) having been developed.
• Supplementary requirements capturing the non functional requirements and any requirements that are not associated with a specific use case.
• An executable architecture and accompanying documentation -the Software Architecture Document, including use-case descriptions (design) for a subset of use cases (use-case view), and an updated glossary.
• A revised business case.
• A revised risk list.
• A development plan for the overall project, including the coarse-grained project plan, showing iterations  and evaluation criteria for each iteration.
• A preliminary user manual (optional).

Milestone 

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:

• 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 plan for the construction of sufficient detail and fidelity, and is it backed up with a credible basis of estimates?
• Do all stakeholders agree that the current vision can be met if the current plan is executed to develop the complete system, in the context of the current architecture?
• Are actual resource expenditure versus planned expenditure acceptable?

The project may be aborted or considerably re-thought if it fails to reach this milestone.

The Construction Phase

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:

• Minimizing development costs by optimizing resources and avoiding unnecessary scrap and rework.
• Achieving adequate quality as rapidly as practical
• Achieving useful versions (alpha, beta, and other test releases) as rapidly as practical

The essential activities of the construction phase are:

• Resource management, 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 software product, integrated on the adequate platform.
• Any user manual.
• A description of the current release.

Milestone

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:

• Is this product release stable and mature enough to be deployed in the user community?
• Are all the stakeholders ready for the transition into the user community?
• Are actual resource expenditures versus planned 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 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:

• Achieving user self-supportability
• Achieving stakeholder concurrence that deployment baselines are complete and consistent with the evaluation criteria of the vision.
• Achieving final product baseline as rapidly and cost effectively as practical

The essential activities of the transition phase are:

• Deployment-specific engineering: cutover, commercial packaging and production, sales roll-out, field personnel training.
• Tuning activities: bug fixing, enhancement for performance and usability.
• Assessment of the deployment baselines against the complete vision and the acceptance criteria for the product.

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.

Milestone 

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:

• Is the user satisfied?
• Are actual resource expenditures versus planned expenditures acceptable?