COCOMO II/Preface/Boehm et al.
PREFACE
"We are becoming a software company" is an increasingly repeated phrase
in organizations as diverse as finance, transportation, aerospace, electronics and
manufacturing firms. Competitive advantage is increasingly dependent on the
development of software for smart, tailorable products and services, and on the
ability to develop and adapt these products and services more rapidly than
competitors' adaptation times. These trends highlight the need for strong
capabilities to accurately estimate software cost and schedules, and to support
tradeoff, risk, sensitivity, and business case analyses for software decisions.
Concurrently, a new generation of software processes and products is
changing the way organizations develop software. These new approaches-evolutionary, risk-driven, and collaborative software processes; fourth generation
languages and application generators; commercial off-the-shelf (COTS) and
reuse-driven software approaches; fast-track software development approaches;
software process maturity initiatives -- lead to significant benefits in terms of
improved software quality and reduced software cost, risk, and cycle time.
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
401284072
COCOMO II/Preface/Boehm et al.
However, although some of the existing software cost models have
initiatives addressing aspects of these issues, these new approaches have not to
date been strongly matched by complementary new models for estimating
software costs and schedules. This makes it difficult for organizations to conduct
effective planning, analysis, and control of projects using the new approaches.
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 project 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-theshelf (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
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
401284072
COCOMO II/Preface/Boehm et al.
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].
[Insert Table P1]
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.).
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
401284072
COCOMO II/Preface/Boehm et al.
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.
At the USC Center for Software Engineering (USC-CSE), we have been
developing an approach called Model-Based (System) Architecting and Software
Engineering (MBASE), for endowing a project with a consistent and mutually
supportive set of product, process, property, and success models [Boehm-Port,
1999a]. 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
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
401284072
COCOMO II/Preface/Boehm et al.
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.
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
401284072
COCOMO II/Preface/Boehm et al.
Content of Book Chapters
Chapter 1 also provides the overall context and framework for COCOMO
II, including its model of future software practices and resulting choice of a threestage 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.
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
401284072
COCOMO II/Preface/Boehm et al.
Others address the problems of estimating the cost of software COTS integration
(COCOTS); stage/phase distribution of schedule and effort (COSSEMO); 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 CDROM.
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 up
with using the package. This is important because it shows you how to effectively
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
401284072
COCOMO II/Preface/Boehm et al.
employ the package—and the COCOMO II model—to develop estimates, make
tradeoffs and perform various kinds of cost analyses.
The CD also provides you with a number of additional resources. It
contains briefings, reports, manuals and amplifying details on the COCOMO II
package so that you will understand its history and how it was derived. Our goal
is to update the CD every two years as we publish updates to this book.
Mapping of Chapters onto Reader Interests
If you are a software manager, analyst, or developer wishing to make and
use software estimates, read Chapters 1, 2, and 3, and Appendix E in concert with
use of the USC COCOMO II tool.
If you are a software estimation specialist for your organization, read the
entire book.
If you are a software metrics and models researcher, read Chapters 1, 2, 4,
5, 6 and Appendices A, B, and C.
If you want a general understanding of COCOMO II and its uses, read
Chapters 1, 2, and 3.
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
401284072
COCOMO II/Preface/Boehm et al.
Relation to 1981 Software Engineering Economics Book
About 30% of the 1981 Software Engineering Economics book [Boehm,
1981] is superseded by the contents of this book. Here is a chapter-by-chapter
assessment of the 1981 book as it relates to the contents of this COCOMO II
book—remember, the chapters listed below are those found in the original 1981
book:
Chapters 1 & 2. These chapters are still timely and useful as a motivation for the
human-economics approach to software engineering.
Chapter 3. The GOALS approach has evolved into MBASE and the stakeholder
win-win approach. The material here and in Appendix B is good for background
and examples, but not for operational guidance.
Chapter 4. COCOMO II has been structured to produce cost and schedule
estimates consistent with the Waterfall Model milestones in this chapter. The
Work Breakdown Structure framework is also still applicable.
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
401284072
COCOMO II/Preface/Boehm et al.
Chapters 5-9. The material on Basic and Intermediate COCOMO 81 has been
replaced by the COCOMO II Applications Composition, Early Design, and PostArchitecture series of models. Portions of Chapters 6 and 7 on Waterfall-model
phase and activity distributions are still relevant.
Chapters 10-20. The material on software microeconomics is still valid as a
framework for using COCOMO II estimates.
Chapters 21 & 22. The seven-step approach and comparison of software
estimation techniques are still valid. The COCOMO II book complements this
material by providing example-based guidance on using COCOMO II for various
estimation, tradeoff analysis and life-cycle estimation purposes (in Chapter 3).
Chapter 23. This material is specific to COCOMO 81. Including phase-sensitive
cost drivers is a downstream COCOMO II goal.
Chapters 24-27. Some of the cost driver experience discussions are dated
(Turnaround Time, Tool Use, Modern Programming Practices, Schedule
stretchout effects). The others are still useful. We plan to provide updates and
coverage of the new cost drivers in some future editions.
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
401284072
COCOMO II/Preface/Boehm et al.
Chapter 28. Personnel Continuity and Documentation are now COCOMO II cost
drivers. Their effects were significant in the latest COCOMO II data analysis.
Requirements Volatility is now being treated as a size modifier via the Breakage
parameter. Other parts of the chapter are largely specific to COCOMO 81.
Chapter 29. The material in this chapter is largely superseded by Chapter 4 of the
COCOMO II book.
Chapter 30. The maintenance data trends are still relevant. The maintenance
model for COCOMO II has been updated to include the Software Understanding
and Personnel Unfamiliarity factors.
Chapter 31. The material on estimating conversion, computer, installation,
training and documentation costs is largely out of date. The business case in
Section 31.8 is still highly useful.
Chapter 32. The planning and control techniques are still valid. Earned value
techniques are now more frequently used for software. The primary trend not
captured is the use of other progress tracking metrics such as those in the
Practical Software Measurement handbook [McGarry et al., 1998]
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
401284072
COCOMO II/Preface/Boehm et al.
Chapter 33. The coverage of COTS and Very High Level Languages was very
good for 1981, but much more is known now; see the COCOTS discussion in
Chapter 5b of this book. The discussions of product, platform, and people
productivity factors are still useful. COCOMO II has more process productivity
options in its scale factors, and a stronger treatment of reuse.
Appendix A. Superseded by current Appendix C.
Appendix B. Good for background, as discussed for Chapter 3.
Bottom Line.
Most of the 1981 book is still useful and relevant. The parts that are
mostly outdated or superseded by this book are Chapters 5-9, 23, 28-29, 31
(except section 31.8), and Appendices A and B.
© 1999-2000 USC Center for Software Engineering. All Rights Reserved
401284072