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:

1. Estimate product size.
2. Estimate total project effort and cost
3. Apply constraints and priorities (for example, number of staff, delivery date, budget)
4. 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.

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.

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

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.

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