var defaultQueryStr = '?proc={EA0C1D32-E39A-4D96-B956-E178DB776A96}&path={EA0C1D32-E39A-4D96-B956-E178DB776A96},_Dt0jMBsuEdqXHNTdjKtnvA,_crrh8EogEdqrjq4i3fchvA'; var backPath = './../../'; var imgPath = './../../images/'; var nodeInfo=null; contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, true, true, false);
Task: Plan Phases and Iterations
This task describes how to plan the project phases and iterations: what are the objectives, what is the duration, how many iterations, etc.
Purpose
The purpose of this task is to:
Estimate the total scope, effort, and cost for the project.
Develop a coarse-grained plan for the project, focusing on major milestones and key deliverables in the product
lifecycle.
Define a set of iterations within the project phases, and identify the objectives for each of these iterations.
Develop the schedule and budget for the project.
Develop a resource plan for the project.
Define the tasks for the orderly completion of the project.
Relationships
RolesMain:
Project Manager
Additional: Assisting:
InputsMandatory:
Business Case
Development Process
Risk List
Optional:
None
External:
None
Outputs
Software Development Plan
Steps
Estimate Project
Purpose
To estimate the magnitude of work required to deliver the project.
To select the optimal schedule that satisfies project constraints.
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.
Estimate total project effort and cost
Apply constraints and priorities (for example, number of staff, delivery date, budget)
Select optimum schedule, effort, and cost estimate
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.
Sizing by Analogy
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.
Sizing by Analysis
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 IBM Web site, 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.
Estimate Total Project Effort and Costs
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.
Apply Constraints and Priorities
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.
Select Optimum Schedule, Effort and Cost Estimate
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 Phase Milestones
Purpose
To define the points at which project progress is formally assessed.
To allocate estimated effort and costs to each phase.
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:
Experience with projects similar in nature and domain.
The degree of novelty.
Specific environment constraints such as response-time, distribution, and safety.
The maturity of the organization.
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.
For more information on how to define the length of iterations and the number of iterations, see Guideline: Software Development Plan.
Define Milestone Goals
Purpose
To define the criteria by which phases are assessed.
Each milestone is focused on a specific deliverable; each provides a well-defined transition point into the next phase.
Phase
Milestone
Purpose
Inception
Lifecycle Objectives Milestone
To commit resources to the project
Elaboration
Lifecycle Architecture Milestone
To stabilize the product's architecture
Construction
Initial Operational Capability Milestone
To complete product development
Transition
Product Release Milestone
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
Purpose
To determine how many iterations will be planned for each project phase.
To determine the relative allocation of work across iterations.
To determine the objectives for each iteration.
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 Guideline: Software Development 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 Concept: 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
Purpose
To refine the estimates based on the information available at the end of the inception phase
Towards the end of the inception phase, phases can be planned more accurately by taking into account the:
Number of use cases identified.
Complexity of the use cases already studied.
Risks identified, both technical and business.
Function-point, or use-case metrics.
Result of any prototyping.
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
Purpose
To define the numbers and types of resources required for this project, allocated by phase/iteration.
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
Purpose
To develop the plan for an orderly termination of the project.
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 tasks that are carried out to bring an orderly closure to the project, ensuring that any
metrics and lessons learned are captured for future reference.
The close-out process begins when the following conditions have been met:
All project deliverables have been completed and stored under configuration control
Acceptance testing has been completed and the product has been formally accepted by the customer
The product has been formally delivered to the customer
Define Close-Out Tasks
Firstly, list in your plan the tasks you will perform during project close-out. Typically these will include the
following:
A project post-mortem meeting
Development of a project post mortem report
End of project personnel reviews
Archival of project work products
Re-assignment of project staff
Addition of project metrics to your organizations historical metrics database for future project estimation.
Identify Participants for Close-Out Tasks
Next, identify in your plan which individuals will be involved in each of the close-out tasks.
Define Schedule for Close-Out Tasks
Then, define the schedule for the close-out tasks. Usually, this detail is added to the Software Development Plan
towards the end of the project.
Properties
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable
Key Considerations
Project planning is where the project manager instantiates (and subsequently manages the execution of) a specific
delivery process (see Artifact: Development Process) for the project. This is often called
process enactment.
An "Instantiated" process is an enactable project/iteration/activity plan (it includes actual activities and work
products for an actual project. A delivery process can be instantiated by importing a Delivery Process from Rational Method Composer into Rational Portfolio Manager (RPM) and then doing
instantiation work by duplicating activities and tasks that are set to isRepeatable or hasMultipleOccurences, creating
real work products, assign real resources to roles, etc.
More Information
Tool Mentors
Exporting Processes to a Planning Tool Using Rational Method Composer