COCOMO II Productivity Ranges and Project Cost
Estimation
Motivation
Productivity Ranges are defined for the
COCOMO II (COnstructive COst MOdel) and they are mathematical coefficients
associated with each of the cost drivers in the model. Assume you have
a new project that is similar to previous projects, and further assume
that the previous projects monitored and recorded all necessary project
data so that the state of the cost drivers as they applied to those previous
projects were known. For example, for the cost driver Platform Experience,
you know that all of previous projects used main frames (extensive staff
experience) and that the new project will use PCs (little staff experience)
and not main frames.
The coefficients quantify the impact on the effort
required for the project that could be expected if the state of the coefficients
for the new project would be different.
Productivity Ranges
In the article "Safe and Simple Software Cost Analysis"
(September/October 2000 issue of IEEE Software), Barry Boehm
defines a cost driver's productivity range as "... the ratio of the
project's productivity for the best possible factor rating to its worst
possible factor rating, assuming that the ratings for all other factors
remain constant" where "productivity" is measured in relative source
lines of code or relative function points per person-month from worst
rating to the best rating.
Identified
The cost drivers identified in COCOMO II are provided
in the following table along with the productivity factors in ascending
order of impact, least to most, as published by Boehm.
| Driver |
Productivity Range |
Varies by Size? |
| Development flexibility |
1.26 |
Yes |
| Team cohesion |
1.29 |
Yes |
| Developed for reuse |
1.31 |
No |
| Precedentedness |
1.33 |
Yes |
| Architecture and risk resolution |
1.39 |
Yes |
| Platform experience |
1.40 |
No |
| Data base size |
1.42 |
No |
| Required development schedule |
1.43 |
No |
| Language and tools experience |
1.43 |
No |
| Process maturity |
1.43 |
Yes |
| Storage constraint |
1.46 |
No |
| Platform volatility |
1.49 |
No |
| Use of software tools |
1.50 |
No |
| Applications experience |
1.51 |
No |
| Personnel continuity |
1.51 |
No |
| Documentation match to life cycle needs |
1.52 |
No |
| Multisite development |
1.53 |
No |
| Required software reliability |
1.54 |
No |
| Time constraint |
1.63 |
No |
| Product complexity |
2.38 |
No |
| Personnel/team capability |
3.53 |
No |
Size Dependence
Some drivers and productivity ranges depend on
the size of the project, as presented in the following table, where ranges
are provided for three project sizes: 10 KSLOC, 100 KSLOC, and 100 KSLOC.
| Factor |
10 |
100 |
1,000 |
| Development flexibility |
1.12 |
1.26 |
1.42 |
| Team cohesion |
1.13 |
1.29 |
1.46 |
| Precedentedness |
1.15 |
1.33 |
1.53 |
| Architecture and risk resolution |
1.18 |
1.39 |
1.63 |
| Process maturity |
1.20 |
1.43 |
1.71 |
Experience Multipliers
Boehm also defines effort multipliers for experience
factors so that their productivity ranges can be further refined according
to the average length of staff experience. These multipliers are presented
in the following table for five values of average staff experience and
with the productivity range that the extremes of these values represent.
| Type of experience |
< 2 mo |
6 mo |
1 yr |
3 yrs |
> 6 yrs |
PR |
| with platform |
1.19 |
1.09 |
1.00 |
0.91 |
0.85 |
1.40 |
| with languages and tools |
1.20 |
1.09 |
1.00 |
0.91 |
0.84 |
1.43 |
| with application area |
1.22 |
1.10 |
1.00 |
0.88 |
0.81 |
1.51 |
For example, platform experience multipliers range
from 1.19 (least experience) to 0.85 (most experience), so that 1.19/0.85
= 1.40.
Estimating Cost
The novelty in Boehm's approach is not to use COCOMO
II in the standard way: selecting values for cost drivers and cranking
through the formulas. Instead, he assumes an existing historical project
with known cost data and the identification of cost drivers that will
have different values in the new project than they did in the historical
project. Once these cost drivers are identified, their estimated productivity
ranges are used to predict the additions or subtractions to the known
costs for the historical project.
For example, using the mainframe example mentioned
earlier, first determine an estimated cost of the new project by using
an estimate of its size and the productivity observed in the historical
mainframe project:
| New project size |
20 KSLOC |
| Productivity on Mainframe project |
500 LOC/Person-Months |
| New project estimate of effort |
40 PM |
Now determine the cost drivers that will be different
for the new project. Assume for this example that the Platform Experience
cost driver will be different for the new project as follows: the new
project will use PCs and not mainframes, and the development team has
very little experience (< 2 months) with PCs while it had significant
experience (> 6 years) with mainframes. From the Experience Multiplier
table above, this changes the productivity range from 0.85 to 1.19, a
1.40 factor increase leading to a revised estimate of 40 PM times (1.40)
= 56 PM.
Trade-offs
Boehm suggests that this approach to estimating
effort and cost can be very useful for evaluating alternative solutions.
For example, one option for reducing the impact of the Platform Experience
cost driver might be to use some moderately experienced PC developers
with good applications experience, while another option might be to use
some very experience PC developers who, unfortunately, have very little
applications experience. Boehm shows the alternative calculations for
these options (and the resulting changes in predicted effort) in the article.
