Thought on COCOMO2 used for software development projects.

COCOMO (COnstructive COst MOdel) was developed by Barry Boehm in the early seventies by collecting data from many projects to gather an empirical database of development efforts for tasks included in these projects. Thus COCOMO provided the first solid data on the productivity of engineers in the workplace. In the nineties, Boehm launched the COCOMO II project, attempting to gather similar data on a much broader scale and to address some of the changes to software development processes and methodologies from the last two decades since COCOMO was first introduced (e.g. prototyping, incremental development, component reuse, CASE tool support, etc.). The COCOMO II equation embeds many project parameters and is defined
as follows:

Effort = A x Size^B x M,

where Effort refers to the person months needed to complete the project; A represents the type of project and there are three possible values for this parameter; Size is defined by using a SLOC estimate or function point count; B is a derived metric which includes the sum of five cost driver metrics and M is a metric for effort multiplier. The COCOMO II equation defines seven effort multipliers for early life cycle estimating. One of the main diffculties applying the COCOMO II technique is coping with the very broad solution
space. Trying to perform an effort estimation using the COCOMO II method at an early project stage, would mean that a product manager would have 3 options to choose a project type, 55 options for cost drivers, 57 options for effort multipliers and an effort value for the Size parameter or alltogether 730000000 different settings combinations, which is too much to review even for the eagerest manager. Another problem with the COCOMO II technique is that it requires, already in an very early project stage, a project size estimation, which however is kind of paradoxical, as if such estimation would exist - it would be fairly easy to formulate a reasonable effort estimation.