Trouble understanding the COCOMO model

Question

In the basic COCOMO Model which is used to estimate the development time of software

Effort : a * KLOC^b = X person months

Development time : c * Effort^d = Y months

where a , b , c , d are constants derived from the table below depending on the type of your software project

Question 1

Assuming X = 10 , Effort will be equal to 10 person months.

Does 10 person months mean that the effort required to complete this project will be 1 month if we have 10 people working on it

OR

Does 10 person month mean that the effort required to complete the project will be 10 months if we have 10 people working on it.

Question 2

Do the constants have any SI units like the SI unit of Effort is person months

I am confused by the terminology

Answer 1

Before going too far two books that you really should read:

• The Mythical Man Month
• Software Estimation: Demystifying the Black Art: Demystifying the Black Art

The basic COCOMO model has some issues with it that were outdated and addressed in the COCOMO II model. From the cited wikipedia page:

COCOMO II is the successor of COCOMO 81 and is better suited for estimating modern software development projects. It provides more support for modern software development processes and an updated project database. The need for the new model came as software development technology moved from mainframe and overnight batch processing to desktop development, code reusability, and the use of off-the-shelf software components.

While the effort of "10 man months" is an estimation of effort it assumes the perfectly divisible task. If you are digging 10 holes in the ground, you can have one person dig 10 holes or 10 people dig one hole - and the 10 people will do it about 10 times faster. As has often been noted, this doesn't work well with software programming.

Of particular interest in this is the paper "Effect of Schedule Compression on Project Effort" [link] which looks into the relative cost of the percent of the most efficient schedule.

Another thing to read is How Software Estimation Tools Work written by one of the people who is often cited the algorithms for software estimation tools.

Effort / staff = time period

As you note, that doesn't work well for programming.

From something I wrote a long time back and didn't cite well I had the following table to tack on to the end of the estimated effort (digging a bit more, it looks a bit like something from the COCOMO II Schedule Equation). Take a default schedule multiplier (3.67) multiply the cube root of the time estimation (your case 10 months).

3.67 * 10^1/3 = 7.9

This represents the best case for a software development project timeline.

Where do these numbers come from? Fitting 20k projects to a curve.

From this 7.9 we've got a few things we can get from it:

• Least effort = 2x optimal delivery time (15.8 months)
• Region of impossibility = < 75% of best case delivery time (5.9 months)

There's a lot going on behind the COCOMO and COCOMO II model. These numbers are fits to a sampling of huge numbers of software projects and unless you understand what you are feeding into the model (to match what the model expects) the numbers you get out won't match anything even vaguely resembling reality.

Realize also that you've gotten about 2/3 of the way through the estimation process. It doesn't end with the estimated effort (10 man months) and continues on with the scheduling. That last bit of the Duration is often dropped or forgotten when the estimate of 10 man moths comes out and they'll just toss 3 people on it and have it done in 3 months (and then it fails because its in region of impossibility)

Further reading:

• An Empirical Validation of Software Cost Estimation Models
• COCOMO II Model Definition Manual
• Effect of Schedule Compression on Project Effort

Answer 2

Ten person months means that one person can do the job in ten months, but also that ten people can do the job in one month. This is pure fiction. The following canonical example is politically incorrect, but is illustrative. It takes a woman nine months to have a baby. Nine women will not reduce this nine month interval one iota. Read The Mythical Man Month. You need to read this alongside of Boehm.

Cost estimation, done right, accounts for constraints such as that nine month interval between conception and birth. Done even better, you need to account for the random events that inevitably raise their ugly heads in a large software project. The state of the practice (not state of the art) in software project management is to account for known constraints and for the random nonsense that inevitably slows things down. Another name for this: Monte Carlo software cost estimation.

Addendum
Think of person months as the software equivalent of the kilowatt-hours that your electric company uses as the basis for your electric bill.

Suppose you land a contract to build ten widgets. Suppose this task is fully automated. Throw a switch on a one kilowatt appliance and one hour later, voila, you have a widget. The total effort for this job is ten kilowatt-hours (ten widgets times one kilowatt-hour per widget). You can get the job done in ten hours if you use one appliance, five hours if you use two appliances. Can you get the job done in one hour with ten appliances? Theoretically, yes. In practice, no. First you have to procure those extra appliances, and then you'll blow fuses when you turn all ten on at the same time. To make matter when you go to the local hardware store will be out of the size you need. You'll end up spending hours searching for that size fuse. You would have been better off using the two appliances you already have on hand.

Answer 3

Team size is one of the inputs to the model; you only get to use the good coefficients if you have an existing, small and experienced team. Which means a team experienced at working together, with each other, on this general class of problem.

You can perhaps add 1 or 2 members, but anything more and you have invalidated the model assumptions. Go back and recalculate with the new coefficients and it will generally provide an estimate of just how much you would delay the project by adding more people.

For the example of a woman having a baby, doing so would move the project from 'routine, within personell capabilities' to 'WWII-scale open-ended genetics research effort that may or may not be physically possible'.

There isn't a line in the chart for that, but you can extrapolate...

Answer 4

The object of the exercise with COCOMO, as with any other software estimating methodology, is to answer two questions: How much will it cost and how long will it take?

What the COCOMO man-months of effort and months of duration results mean is that, when the project is over, it is estimated that you will have paid out the equivalent of that many man-months in salary, and so many months will have gone by on the calendar.

It does NOT mean that one man can do it in that many months, and it does NOT mean that that many men can do it in one month.

COCOMO estimates are based on deliverable source lines of code estimates, and yield results in man-months, because both deliverable source lines of code and expended man-months are easy to measure after-the-fact. One of them comes directly from the delivered code, and the other comes directly from the payroll data for the project. The magic numbers in COCOMO were developed by doing postmortem measurements on timecard data and line count for a large number of projects.

This allows you to calibrate the estimator to your particular organization, and improve the overall quality of your particular organization's estimates. Boehm et al strongly recommend every organization do this. The numbers they give are good starting points for an individual organization, but they are not engraved in stone tablets and they are not the Final Answer.

Basic COCOMO gives you BOTH the nominal total effort, in man-months, AND the nominal project duration, in months. To get the nominal number of people required over that duration, you divide effort by duration.

That's nominal. Basic COCOMO DOES NOT ADDRESS off-nominal schedules, either compressed or stretched out. To account for the effect of management monkey-wrenching the schedule, you must use Intermediate COCOMO or Detailed COCOMO.

To answer your second question: It is not possible to assign units to the individual magic numbers of Basic COCOMO, because the system is formally underspecified. You have no way to decide which units go with which magic number, and which units get cancelled in the dimensional (factor label) analysis.