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 bottomup 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 realtime systems) and Predictive Object Points (a measure
for objectoriented 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 nonlinearly 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.
