The original COCOMO model [Boehm, 1981] was one of the minor breakthroughs in software engineering during the early 1980s. It was a breakthrough partly because of its inherent technology contribution but primarily because it provided a well-defined framework for communication of trade-offs and priorities associated with software cost and schedule management. As a naive graduate student at UCLA in 1980,1 first encountered the COCOMO model as the subject of a new graduate-level course taught by Boehm. At the same time, I was working at TRW as a lead designer on a software-intensive proposal for which we needed to plan and defend the software cost and schedule estimates. A huge benefit offered by the COCOMO model was the ability to make an estimate, reference a credible basis for it, reason about its strengths and weaknesses, and negotiate with stakeholders. Since then, I have used COCOMO to rationalize technology insertions, process improvements, project architecture changes, and new management approaches. In these activities, I became experienced with its strengths and weaknesses, as well as its use and misuse.

The original COCOMO model was based on a database of 56 projects. Its three modes reflected the differences in process across a range of software domains. These modes were identified as organic, semidetached, and embedded. Organic mode projects were characterized by in-house, less-complex developments that had flexible processes. Features, qualities, cost, and schedule could be freely changed with minimal overhead. Embedded mode systems represented typical defense community projects: Complexity, reliability, and real-time issues were dominant, and the contractual nature of the business resulted in a highly rigorous process. Features, qualities, costs, and schedules were tightly controlled, and changes required approvals by many stakeholders. Semidetached mode projects represented something in between.

Basic Effort and Schedule Estimating Formulas

These were the original COCOMO cost estimation relationships:

Organic mode Effort = 3.2 EAF (Size)105

Semidetached mode Effort = 3.0 EAF (Size)112

Embedded mode Effort = 2.8 EAF (Size)12


Effort = number of staff-months EAF = product of 15 effort adjustment factors (Table B-l) Size = number of delivered source instructions (in units of thousands of lines of code)

The effort adjustment factor (EAF) multiplier represents the combined effects of multiple parameters. These parameters allow the project to be characterized and normalized against the projects in the COCOMO database. Each parameter is assessed as very low, low, nominal, high, or very high. The effect of each parameter setting is a multiplier that typically ranges from 0.5 to 1.5. The product of these 15 effects is used as the coefficient in the cost equation.

Table B-l. COCOMO project characterization parameters

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook

Post a comment