The COCOMO (COnstructive COst MOdel) Cost Estimation Model, developed by BarryBoehm at USC. Not to be confused with the place, or the song, or breed of Canadian snow monkey...

The COCOMO estimating equations follow the form:

	Effort = C1.EAF.(Size)^P1 
	Time = C2.(Effort)^P2
where

	* Effort = number of staff months
	* C1 = a constant scaling coefficient for effort
	* EAF = An effort adjustment factor that characterises the domain, personnel, environment and tools used to the produce the artifacts of the process.
	* Size = size of the end product (in human-generated source code), measured by the number of delivered source instructions (DSI) required to develop the required functionality.
	* P1 = an exponent that characterises the economies of scale inherent in the process used to produce the end product, in particular the ability of the process to avoid non-value-adding activities (rework, bureaucratic delays, communications overhead)
	* Time = total number of months
	* C2 = a contract scaling coefficient for schedule
	* P2 = an exponent that characterises the inherent inertia and parallelism in managing a software development effort.

This was followed later by Ada COCOMO and COCOMO II.

For more info, try http://sunset.usc.edu/research/COCOMOII/index.html, which has pointers to books, software and other resources.

----
Whew. Does anyone actually use this or any other sophisticated estimation technique with any success? Does COCOMO have value in ExtremeProgramming? Does it make a mean jerk chicken?

''Is it sophisticated? The whole method has been adequately described here in less than a browser page of text. -- ChrisSteinbach''

Applying the model requires very little sophistication. Working out the various constants in those two equations for ''this'' team, working on ''that'' problem in this environment ''here'', is something else again. A big part of the COCOMO literature exists to suggest ways to find good values for those constants without the use of a time machine.

Notice that even with those constants, COCOMO is of no use to you unless you also already know how many LinesOfCode you're going to have to write. The main input is not the size of the problem, it's the size of the solution (that you haven't started on yet).
----
To elaborate on the method further, COCOMO lumps a whole lot of stuff into the EAF parameter. It consists of the following parameters...

	* Required reliability
	* Database size
	* Product complexity
	* Execution time constraint
	* Main storage component
	* Virtual machine volatility
	* Computer turnaround time
	* Analyst capability
	* Applications experience
	* Applications experience
	* Programmer capability
	* Virtual machine experience
	* Language experience
	* Use of modern practices
	* Use of software tools
	* Required development schedule

Each of these parameters (don't ask me to explain what they all mean) is assigned a value, typically between 0.7 and 1.6, depending on the environment, tools, resources etc. The default is 1.0. These values are then multiplied together to give the value of EAF in the above equations. The problem then is to give them all an accurate value.

Accurate estimation by COCOMO then appears to rely on having a good knowledge of the workings of your software factory by analysing a sufficient number of previous projects. By which time you can probably estimate well enough without COCOMO anyway. But I'm open to persuasion otherwise. -- Andrew Joyner, Dennis Angle