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.
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).
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 by 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.
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.
For more information on how to define the length of iterations and the number of iterations, see Guidelines: Software Development Plan.
Each milestone is focused on a specific deliverable; each provides a well-defined transition point into the next phase.
Each milestone represents a critical hurdle that the project must clear; at each milestone the project faces a go/no-go decision.
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.
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.
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.
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.
The close-out process begins when the following conditions have been met:
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.