These concerns have led the authors of this book to formulate a new version of the Constructive Cost Model (COCOMO®) for software effort, cost and schedule estimation. The original COCOMO® 81 Boehm 1981 and its specialized Ada COCOMO® successor Boehm and Royce 1989 were reasonably well matched to the classes of software projects that they modeled: largely custom, built-to-specification software Miyazaki and Mori 1985; Goudy 1987. Although Ada COCOMO® added a capability for estimating the costs and schedules for incremental software development, COCOMO® 81 encountered increasing difficulty in estimating the costs of software created via spiral or evolutionary development models, or of software developed largely via commercial off-the-shelf (COTS) applications-composition capabilities. Software Estimation State of the Practice

A number of commercial software estimation models continue to pass the market test for value added to users. And quite a few organizations do a good job of software project planning, estimating, and control. However, a very large number of organizations do not: in the 1995 Standish Group study, over 53% of the software projects were overrun by more than 50% in both budget and schedule Standish 1995.

Some recent collections of software failure case studies provide more detail on the reasons for such overruns. Table P1 summarizes the results from six such projects. The first three are from Flowers 1996; the second three are from Glass 1998.Model Clashes and MBASE

We have analyzed the projects in Table P1, and have found that many of their problems result from model clashes Boehm-Port 1999b. Model clashes involve incompatibilities among the primary models being used to define and manage the project. These include product models (requirements, architecture, design, etc.); process models (waterfall, spiral, maturity models, etc.); property models (cost, schedule, performance, etc.), and success models (business case, stakeholder win-win, IKIWISI: I'll know it when I see it, etc.).

Table P1 Software Overrun Case Studies


Last Estimate Project

Cost ($M)

Schedule (Months)

Status at Completion

PROMS (Royalty collection)


21+ 22

46 Cancelled

Month 28


London Ambulance


6+ 7

17+ Cancelled

Month 17


London Stock Exchange



70 Cancelled

Month 36


Confirm (Travel reservations)


160+ 45

60+ Cancelled

Month 48

FAA Advanced Automation System


7000+ 48

96 Cancelled

Month 70


Master Net (Banking)


80+ 9

48+ Cancelled

Month 48

The projects in Table P1 all had a number of model clashes contributing to their failure. Several model clashes involved cost and schedule property models. For example, the London Ambulance project established a $2.25M cost baseline from misreading a consultant's report giving a best-possible cost if an (unavailable) packaged product solution could be found. The low bidder's $1.5M bid was based on a very sketchy build-from-scratch product model. It uses stakeholder success models as the critical project drivers, and a stakeholder win-win variant of the spiral model to determine a compatible set of product, process, property, and success models for the system. It also integrates software engineering with system engineering, and provides a strong framework for transitioning to the new Integrated Capability Maturity Model (CMM I).MBASE and COCOMO® II

Our research on MBASE includes research on success models (win-win; expectations management); process models (WinWin Spiral Model, anchor points, requirements negotiation); product models (domain models, software architectures); and property models (primarily COCOMO® II and its extensions). The concurrent research on these component models helps to strengthen their relationships and to ground them in software practices. For example, our anchor point process research began with an effort to define a set of common life-cycle milestones upon which to base COCOMO® II cost and schedule estimates. In collaboration with Rational, Inc., we have integrated the MBASE phases and milestones with those of the Rational Unified Process, and have provided MBASE/RUP phase and activity distribution estimators for COCOMO® II in Appendix A.

Also, we try to apply MBASE to our own projects. Thus, in scoping COCOMO® II, we used the MBASE principles of identifying stakeholders, gathering their objectives in using software estimation models, and determining their principal needs for improvement over the existing COCOMO® 81 capability. Thus, Chapter 1 of this book begins with a summary of COCOMO® II user objectives, followed by a set of COCOMO® II model objectives in terms of desired improvements over COCOMO® 81, followed by a set of COCOMO® II development and evolution strategies for achieving the objectives.

One of the stakeholder objectives was to avoid basing COCOMO® II on a single process model such as the waterfall model assumed in COCOMO® 81. Thus, we have developed interpretations of COCOMO® II to cover the waterfall model, MBASE/RUP, and incremental development. Content of Book Chapters

Chapter 1 provides the overall context and framework for COCOMO® II, including its model of future software practices and resulting choice of a three-stage model tailorable to the major future software practices. Chapter 2 presents the specific definitions of COCOMO® II quantities, estimating equations, cost driver and scale factor definitions and rating scales, and guidance in interpreting the definitions in special situations.

The final section of Chapter 2 shows how to use COCOMO® II to perform quick manual analyses for a number of the objectives established in Chapter 1: making investment decisions, performing tradeoff and risk analyses, tailoring models to project practices.

Chapter 3 shows how you can use the USC COCOMO® II tool to perform more extensive cost estimates and tradeoff analyses, using two representative examples: a transaction processing system and an aircraft radar system.

Chapter 4 summarizes the COCOMO® II Bayesian calibration process and results, and provides guidelines for organizations to produce their own calibrated version of the model.

Chapter 5 describes some emerging extensions of the central COCOMO® II model. The Applications Composition model is still considered to be an emerging extension, as its calibration and counting rules are not yet robust. Others address the problems of estimating the cost of software COTS integration (COCOTS); phase distribution of schedule and effort (COPSEMO); rapid application development effort and schedule adjustments (CORADMO); quality in terms of delivered defect density (COQUALMO); and the effects of applying software productivity strategies (COPROMO).

Chapter 6 projects future software trends and how they are likely to affect software cost estimation and COCOMO® II.

Six appendices provide A) COCOMO® II definitions, assumptions, and phase/activity distribution estimates, B) an incremental development estimation model, C) data collection forms for COCOMO® II and emerging extensions to better calibrate the model to your organization, D) information on the USC-CSE COCOMO® II and other Affiliate programs, E) a Software Reference Manual for the USC COCOMO® II tool, and forms and guidelines for COCOMO® II data collection, and F) information on the content and use of the accompanying CD-ROM.

This CD provides you a current copy of a COCOMO® II estimating software package developed by USC-CSE, and demonstration copies of three commercial COCOMO® II packages. We have also put the examples used within the book as files on the CD so that you can generate the results we've come.