Abstract
Earlier, you were asked to discuss, in the Forum, what kinds of factors significantly complicate software development projects.
Not surprisingly, that’s a question of much interest to developers and their managers. There have been quite a few studies devoted to that subject.
One place where identifying complicating factors comes into play is in trying to estimate the cost of a project before it can begin.
One of the best known software development cost models is
The Intermediate Cocomo formula estimates effort ($E$) in person-months:
\[ E = a_{i} (\mbox{KLoC})^{b_i} \cdot \mbox{EAF} \]
KLoC stands for “Kilo (thousands) of Lines of Code”, and represents an estimate of how large a propsoed project is going to be.
The constants $a_{i}$ and $b_{i}$ describe the characteristics of the development team.
Suppose that in previous projects of various sizes, our company’s performance had fitted to $a=3.0$, $b=1.12$.
If we are looking at doing a 10 KLOC project that is very similar to past projects, the estimated effort would be
\[ E = a_i (\mbox{KLoC})^{b_i} \cdot \mbox{EAF} \]
\[ \; = 3.0 \cdot 10^{1.12} \cdot 1.0 \]
\[ \; = 40 \mbox{person-months} \]
If we are looking at doing a 20 KLOC project that is very similar to past projects, the estimated effort would be
\[ E = a_i (\mbox{KLoC})^{b_i} \cdot \mbox{EAF} \]
\[ \; = 3.0 \cdot 20^{1.12} \cdot 1.0 \]
\[ \; = 86 \mbox{person-months} \]
The most interesting part of the COCOMO formula is the EAF
, a multiplier computed from a checklist of project attributes.
Ratings | ||||||
---|---|---|---|---|---|---|
Cost Drivers | Very Low | Low | Nominal | High | Very High | Extra High |
Product attributes | ||||||
Required software reliability | 0.75 | 0.88 | 1.00 | 1.15 | 1.40 | |
Size of application database | 0.94 | 1.00 | 1.08 | 1.16 | ||
Complexity of the product | 0.70 | 0.85 | 1.00 | 1.15 | 1.30 | 1.65 |
Hardware attributes | ||||||
Run-time performance constraints | 1.00 | 1.11 | 1.30 | 1.66 | ||
Memory constraints | 1.00 | 1.06 | 1.21 | 1.56 | ||
Volatility of the target environment | 0.87 | 1.00 | 1.15 | 1.30 | ||
Required turnabout time | 0.87 | 1.00 | 1.07 | 1.15 | ||
Personnel attributes | ||||||
Analyst capability | 1.46 | 1.19 | 1.00 | 0.86 | 0.71 | |
Applications experience | 1.29 | 1.13 | 1.00 | 0.91 | 0.82 | |
Software engineer capability | 1.42 | 1.17 | 1.00 | 0.86 | 0.70 | |
Target environment experience | 1.21 | 1.10 | 1.00 | 0.90 | ||
Programming language experience | 1.14 | 1.07 | 1.00 | 0.95 | ||
Project attributes | ||||||
Application of software engineering methods | 1.24 | 1.10 | 1.00 | 0.91 | 0.82 | |
Use of software tools | 1.24 | 1.10 | 1.00 | 0.91 | 0.83 | |
Required development schedule | 1.23 | 1.08 | 1.00 | 1.04 | 1.10 |
Suppose that in previous projects of various sizes, our company’s performance had fitted to $a=3.0$, $b=1.12$.
If we are looking at doing a 10 KLOC project that is very similar to past projects, the estimated effort would be
\[ E = a_i (\mbox{KLoC})^{b_i} \cdot \mbox{EAF} \]
\[ \; = 3.0 \cdot 10^{1.12} \cdot 1.0 \]
\[ \; = 40 \, \mbox{person-months} \]
But suppose that we have decided to write this project in a programming language that is new to our team, and for which our preferred debugging tools are unavailable.
The EAF table says
Ratings | ||||||
---|---|---|---|---|---|---|
Cost Drivers | Very Low | Low | Nominal | High | Very High | Extra High |
Programming language experience | 1.14 | 1.07 | 1.00 | 0.95 | ||
Use of software tools | 1.24 | 1.10 | 1.00 | 0.91 | 0.83 |
So we might guess that our EAF $= 1.14 * 1.10$ = 1.254, so those two factors add an additional 25% to the effort estimate:
\[ E = a_i (\mbox{KLoC})^{b_i} \cdot \mbox{EAF} \]
\[ \; = 3.0 \cdot 10^{1.12} \cdot 1.25 \]
\[ \; = 50 \, \mbox{person-months} \]
Ratings | ||||||
---|---|---|---|---|---|---|
Cost Drivers | Very Low | Low | Nominal | High | Very High | Extra High |
Product attributes | ||||||
Required software reliability | 0.75 | 0.88 | 1.00 | 1.15 | 1.40 | |
Size of application database | 0.94 | 1.00 | 1.08 | 1.16 | ||
Complexity of the product | 0.70 | 0.85 | 1.00 | 1.15 | 1.30 | 1.65 |
Hardware attributes | ||||||
Run-time performance constraints | 1.00 | 1.11 | 1.30 | 1.66 | ||
Memory constraints | 1.00 | 1.06 | 1.21 | 1.56 | ||
Volatility of the target environment | 0.87 | 1.00 | 1.15 | 1.30 | ||
Required turnabout time | 0.87 | 1.00 | 1.07 | 1.15 | ||
Personnel attributes | ||||||
Analyst capability | 1.46 | 1.19 | 1.00 | 0.86 | 0.71 | |
Applications experience | 1.29 | 1.13 | 1.00 | 0.91 | 0.82 | |
Software engineer capability | 1.42 | 1.17 | 1.00 | 0.86 | 0.70 | |
Target environment experience | 1.21 | 1.10 | 1.00 | 0.90 | ||
Programming language experience | 1.14 | 1.07 | 1.00 | 0.95 | ||
Project attributes | ||||||
Application of software engineering methods | 1.24 | 1.10 | 1.00 | 0.91 | 0.82 | |
Use of software tools | 1.24 | 1.10 | 1.00 | 0.91 | 0.83 | |
Required development schedule | 1.23 | 1.08 | 1.00 | 1.04 | 1.10 |
Some of the trends are obvious.
Some of the trends are not monotonic.
How do the cost factors from the COCOMO table match up against your and your classmates’ answers in the opening discussion?
Consider a project with the following characteristics:
What do you think the EAC would be for this project?
Consider a typical open source project on SourceForge or similar sites. They can be staffed largely by volunteers, working remotely. The developers may not even live and work in the same timezone, so face-to-face meetings are unlikely and most communication will be asynchronous (e.g., e-mail).
The participants may range from seasoned veterans to near-novices.
By conventional thinking, it’s a wonder that such projects ever succeed!