Activity: Plan Phases and Iterations

Purpose To estimate the total scope, effort, and cost for the project. To develop a coarse-grained plan for the project, focusing on major milestones and key deliverables in the product life cycle. To define a set of iterations within the project phases, and identify the objectives for each of these iterations. To develop the schedule and budget for the project. To develop a resource plan for the project. To define the activities for the orderly completion of the project.
Steps Estimate Project Define Project Milestones Define Milestone Goals Define Number, Length, and Objectives of Iterations Within Phases Refine Milestones Dates and Scope Determine Project Resourcing Requirements Develop Project Close-Out Plan
Input Artifacts: Risk List Business Case	Resulting Artifacts: Software Development Plan
Frequency: Once per project.
Role: Project Manager

Workflow Details:

Project Management

Develop Software Development Plan

Estimate Project

During the Inception phase, you should prepare estimates for the work proposed in the project (for a general discussion of software project estimation see [BOE81], [PUT92], and [MCO96]). Software project estimation is based on some complex mathematics, so detailed technical background is not discussed here. Estimation follows a four step process:

Estimate Product Size

This is the key input to the estimation process. If you can't estimate the magnitude of work to be done, any project schedule you create is likely to be far from reality. There are two approaches to estimating the size of the software product that can be used early in the project: Sizing by Analogy, and Sizing by Analysis. Of course, later in the project (during the Elaboration phase) you can prepare more rigorous bottom-up estimates based on a detailed project Work Breakdown Structure.

When you estimate the project scope using the Sizing by Analogy approach you compare the new product you will be developing with products (of known size) developed in previous projects. You should compare various characteristics of the products being compared, such as number of business use cases, number of actors, database size/complexity, and likely numbers of online and batch programs.

By comparing these characteristics you can estimate the relative size of the new product compared to the old ones, then you use the known size of the old product to calculate the estimated size for the new one. Bear in mind that it is important to compare products of similar complexity, developed using similar approaches as variances in such things as the level of detail in use case descriptions can invalidate your comparisons.

Later on in the Inception phase, it is likely that you will have gathered enough information about the new product to use analytical techniques to estimate the product size. These techniques rely upon a functional description of the software product being available (for example, Software Requirements Specification, Software Architecture Document) and apply standard counting rules to determine a size measure from these descriptions. Probably the most well known of these techniques is Function Point Counting, although a number of other measures have been developed including Feature Points (a modification of Function Points for application to real-time systems) and Predictive Object Points (a measure for object-oriented systems based on an analysis of class complexities and hierarchies).

There are also white papers available from the RUP Resource Center which describe methods for size estimation based on Use Cases. When using these papers, you should be aware that to make initial size estimations based on Use Cases, you must calibrate to suit your organization's Use Case style, because Use Cases can vary greatly in level of abstraction and manner of expression between organizations, and even within an organization. Once calibrated, it is important to keep to the selected standard style for writing Use Cases, otherwise the size estimates can be wildly erroneous.

The total staff effort and schedule for a project can be calculated from the product size estimate using established scientific models. The two prominent models in use today are the COnstructive COst MOdel (COCOMO) developed by Barry Boehm, and Larry Putnam's Putnam Methodology. Both models have been validated against industry data. For more information on latest version of COCOMO, see the COCOMOII web site.

Aside from the size input, the other key input is a measure of the team productivity. This value determines the overall project effort. The total project schedule is related non-linearly to the total effort. Unfortunately the models are mathematically complex, so it is best to make use of software tools to assist with the calculations.

Just about every project is subject to some constraints (for example, must ship be a certain date, or cost cannot exceed $850,000) or priorities (for example, product needed as soon as possible). Given a fixed product size, these are affected by adjustments to team size. It turns out that the relationship between team size and schedule is not linear, so you'll need to use the scientific models to generate a number of scenarios based on varying team sizes. Automated estimation software is very useful for this exercise.

Now that you have a range of scenarios for the project, you review and select the scenario that best fits your project's needs. This gives you an initial picture of the overall duration of the project as proposed, and indicates the necessary team size and budget.

Define Project Milestones

The Software Development Plan first defines the dates and nature of the major milestones (see Phases). This part of the Software Development Plan serves as the overall "road map" to the project and is created at the beginning of the project (inception phase).

To plan the phases for a project in the initial development cycle, you may have to make some educated guesses about milestones on the basis of:

Using estimates based on your own experiences in other projects of a similar nature, you create the initial project budget by allocating the appropriate portions of the total estimated effort and costs to each phase of the project.

In addition to that, the Project Manager should define the initial schedule for the Intermediate Milestones Review. The objective is to formally accept the work of a number of iterations. For more details, see Activity: Intermediate Milestone Review

Define Milestone Goals

Each milestone is focused on a specific deliverable; each provides a well-defined transition point into the next phase.

Phase	Milestone	Purpose
Inception	Lifecycle Objective	To commit resources to the project
Elaboration	Lifecycle Architecture	To stabilize the product's architecture
Construction	Initial Operational Capability	To complete product development
Transition	Product Release	To successfully deploy the product

Each milestone represents a critical hurdle that the project must clear; at each milestone the project faces a go/no-go decision.

Define Number, Length, and Objectives of Iterations Within Phases

Once the length of the project phases are determined, the number of iterations and their length need to be determined. For more information on how to define the length of iterations and the number of iterations, see Guidelines: Project Plan. There are a number of iteration patterns that can be applied, depending on the type of project, problem domain and novelty of the problem domain (see also Concepts: Iteration).

Each iteration produces a deliverable, a release which is an executable product that is used to assess progress and quality. Because each iteration has a different focus, the functionality and completeness of the iteration deliverable will vary. Iteration goals must be specific enough to assess, at the end of the iteration, whether the iteration goals have been met. In early iterations, goals are usually expressed in terms of risks mitigated; in later iterations goals are expressed in measures of functional completion and quality.

Refine Milestone Dates and Scope

Towards the end of the inception phase, phases can be planned more accurately by taking into account the:

This very rough plan is updated during the elaboration phase. It serves as the basis for building the rest of the project plan.

Determine Project Resourcing Requirements

Based on your effort estimates and the project schedule derived from them, you can now define the resources required to carry out the project. For each phase/iteration, identify which roles need to be involved, and how many of each.

Develop Project Close-Out Plan

The Project Close-Out Plan is documented in Section 5.6 Close-out Plan of the Software Development Plan. Project Close-Out is the series of activities that are carried out to bring an orderly closure to the project, ensuring that any metrics and lessons learned are captured for future reference.

Define Close-Out Activities

Firstly, list in your plan the activities you will perform during project close-out. Typically these will include the following:

Identify Participants for Close-Out Activities

Next, identify in your plan which individuals will be involved in each of the close-out activities.

Define Schedule for Close-Out Activities

Then, define the schedule for the close-out activities. Usually, this detail is added to the Software Development Plan towards the end of the project.