Task: Plan Phases and Iterations









var backPath = './../../';
var imgPath = './../../images/';
var nodeInfo=[{view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_4U33kAILEdq-_NKqZM1EhA", "_qIh6UABuEdqrKcHWz1HoWw", "{EE97A8CD-66CA-4A9B-9871-E3B94CCED528}", "{43005DA9-D75E-464D-8AFC-AB9CACD92626}"]}, {view: "view:_LVCagP5WEdmAzesbYywanQ", path: ["_LVCagP5WEdmAzesbYywanQ", "_4U33kAILEdq-_NKqZM1EhA", "_nB0hwAITEdqu-LkyOdB8SQ", "_yeA1y9nmEdmO6L4XMImrsA", "{43005DA9-D75E-464D-8AFC-AB9CACD92626}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_f6_YwN7DEdmsEI4YDGX2ag", "_qIh6UABuEdqrKcHWz1HoWw", "{EE97A8CD-66CA-4A9B-9871-E3B94CCED528}", "{43005DA9-D75E-464D-8AFC-AB9CACD92626}"]}, {view: "view:_FCx1oN7CEdmsEI4YDGX2ag", path: ["_FCx1oN7CEdmsEI4YDGX2ag", "_kC0pcN7GEdm8G6yT7-Wdqw", "_yeA1y9nmEdmO6L4XMImrsA", "{43005DA9-D75E-464D-8AFC-AB9CACD92626}"]}];
contentPage.preload(imgPath, backPath, nodeInfo, '', true, false, 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.


Disciplines: Project Management






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



RolesPrimary Performer:



Project Manager


Additional Performers:



InputsMandatory:



Business Case


Development Process


Risk List



Optional:


None




Outputs


Software Development Plan






Process Usage


Project Management
 > 
Plan the Project
 > 
Plan Phases and Iterations


Project Management
 > 
Refine the Development Plan
 > 
Plan Phases and Iterations






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.







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








©  Copyright IBM Corp. 1987, 2006.  All Rights Reserved.







contentPage.onload();