SCEplus is an Excel addin providing a complete COCOMO II Software Cost Estimating Capability

• SCEplus is a Microsoft Excel add-in that provides a complete COCOMO II software cost analysis capability and function point modeling.
• As an Excel add-in; you can develop your estimates with a tool you already know, add additional cost information, generate charts and distribute results in a standard format.   When changes come along you don't have to contend with re-importing the data from your modeling tool.  You start in Excel - you work in Excel - you finish in Excel.
• By harnessing the power of Excel, software cost estimating doesn't become a full-time career - it is straight forward and easy.  That means you can spend your time on the hard part - determining the scope & size of the project.

Supports COCOMO II's early design & post architecture models

Supports the following COCOMO II sizing methods:

SCEplus Provides:

Other Cost Model Features:

If you would like additional information or have suggestion for future product updates, please send a note to: info@SchemeQuest.com

(The follow information is provided in accordance with the copyright provision prescribed by the University of Southern California.)

COCOMO II is a model that allows one to estimate the cost, effort, and schedule when planning a new software development activity. It consists of three sub-models, each one offering increased fidelity the further along one is in the project planning and design process. Listed in increasing fidelity, these sub-models are called the Applications Composition, Early Design, and Post-architecture models. Until recently, only the last and most detailed sub-model, Post-architecture, had been implemented in a calibrated software tool. As such, unless otherwise explicitly indicated, all further references on this web page to "COCOMO II" or "USC COCOMO II" can be assumed to be in regard to the Post-architecture model.

The implemented tool provides a range on its cost, effort, and schedule estimates, from best case to most likely to worst case outcomes. It also allows a planner to easily perform "what if" scenario exploration, by quickly demonstrating the effect adjusting requirements, resources, and staffing might have on predicted costs and schedules (e.g., for risk management or job bidding purposes).

The original COCOMO model was first published by Dr. Barry Boehm in 1981, and reflected the software development practices of the day. In the ensuing decade and a half, software development techniques changed dramatically. These changes included a move away from mainframe overnight batch processing to desktop-based real-time turnaround; a greatly increased emphasis on reusing existing software and building new systems using off-the-shelf software components; and spending as much effort to design and manage the software development process as was once spent creating the software product.

These changes and others began to make applying the original COCOMO model problematic. The solution to the problem was to reinvent the model for the 1990s. After several years and the combined efforts of USC-CSE, IRUS at UC Irvine, and the COCOMO II Project Affiliate Organizations, the result is COCOMO II, a revised cost estimation model reflecting the changes in professional software development practice that have come about since the 1970s. This new, improved COCOMO is now ready to assist professional software cost estimators for many years to come.

The original model published in 1981 went by the simple name of COCOMO. This is an acronym derived from the first two letters of each word in the longer phrase Constructive Cost Model. The word "constructive" refers to the fact that the model helps an estimator better understand the complexities of the software job to be done, and by its openness permits the estimator to know exactly why the model gives the estimate it does. Not surprisingly, the new model (composed of all three sub-models) was initially given the name COCOMO 2.0. However, after some confusion in how to designate subsequent releases of the software implementation of the new model, the name was permanently changed to COCOMO II. To further avoid confusion, the original COCOMO model was also then re-designated COCOMO 81. All references to COCOMO found in books and literature published before 1995 refer to what is now called COCOMO 81. Most references to COCOMO published from 1995 onward refer to what is now called COCOMO II.

(If in examining a reference you are still unsure as to which model is being discussed, there are a few obvious clues. If in the context of discussing COCOMO these terms are used: Basic, Intermediate, or Detailed for model names; Organic, Semidetached, or Embedded for "development mode," then the model being discussed is COCOMO 81. However, if the model names mentioned are Application Composition, Early Design, or Post-architecture; or if there is mention of "scale factors" Precedentedness, Development Flexibility, Architecture/Risk Resolution, Team Cohesion, or Process Maturity, then the model being discussed is COCOMO II.)

We would like to address two misconceptions about COCOMO, source lines of code (SLOC) and function points (FP):

Misconception 1: COCOMO does not support the use of function points. Function-point versions of COCOMO have been available 1987. COCOMO II supports the use of either function points or source lines of code. In both cases, this is done via "backfiring" tables of source lines of code per function point for source languages at different levels.

Misconception 2: It is irresponsible to use SLOC as a general productivity metric, but it is not irresponsible to use FP as a general sizing parameter for estimation. This breaks down into two cases:

2a. Your organization uses different language levels to develop software. In this case, it is irresponsible to use SLOC as a productivity metric, as you get higher productivity/SLOC at higher language levels. However, it is also irresponsible to use FP as your general sizing metric for estimation, as pure FP will give you the same cost (or schedule or quality) estimate for a program with the same functionality developed using different language levels, which is clearly wrong. To get responsible results in this case, FP-based estimation models need to use some form of backfiring to account for the difference in language level.

2b. Your organization always uses the same programming language (level). Here, it's responsible to use pure FP as your sizing metric for estimation. But it's also responsible to use SLOC as your productivity metric.

The first USC-CSE implementation of COCOMO II was released to the general public in mid-1997. USC COCOMO II.1997 is calibrated to 83 data points (historical software development projects), using a 10% weighted-average approach (35kb) to blending empirical data with expert opinion to calibrate the model parameters. Over those 83 data points, the '97 release demonstrates an accuracy of within 20% of actuals 46% of the time for effort, and within 20% of actuals 48% of the time for a nonincremental development schedule.

USC COCOMO II.1998.0 beta was released in October 1998. The '98 version of the model has been calibrated to 161 data points, this time using a Bayesian statistical approach (119kb) to blending empirical data with expert opinion to calibrate the model. Over those 161 data points, the '98 release demonstrates an accuracy of within 30% of actuals 75% of the time (and within 30% of the actuals 80% of the time after stratification by organization) for effort, and within 30% of actuals 72% of the time (within 30% of the actuals 81% of the time after stratification by organization) for a nonincremental development schedule.

USC COCOMO II.1999.0 was released in mid-1999 and USC COCOMO II.2000.0 has been released in conjunction with the publication of Cost Estimation With COCOMO II (Prentice Hall, July 2000). While each release of the USC COCOMO II tool has seen improvements in its user friendliness, for logistical reasons related to preparation of materials for the book, the 1998, 1999, and 2000 model calibrations are the same. That is, no new data points have been added to the database used to calibrate the 1999 and 2000 releases of the tool beyond those that appeared in the 1998 calibration database. The same 161 data points noted above appear in all three implementations. With publication of the new book achieved, however, attention is again now focusing on improving the calibration of the tool itself, and it is anticipated that USC COCOMO II.2001.0 will indeed have a new calibration.

Finally, experience has shown that if an organization calibrates the multiplicative constant in COCOMO II to its own empirical data, the accuracy of the model can be greatly improved over the generic calibration results indicated above.

Once a calibrated version of COCOMO II was finally released to the public, the need to provide a single, concise, authoritative resource documenting the model and explaining the use of the USC COCOMO II software became apparent. To that end, members of the COCOMO research group have authored a book called Software Cost Estimation With COCOMO II (Prentice Hall, July 2000) shown above on the left. The book explains the theory behind the model, while keeping a focus on the practical informational needs of the professional software cost estimator.

Rather than as a replacement of Software Engineering Economics (Prentice Hall, 1981) shown above on the right, which was Barry Boehm's earlier text detailing the theory and application of COCOMO 81, this new book should be viewed as an updated supplement (in practical terms it supercedes about one third of the material in the original book). For the software professional, it serves quite well as a stand-alone resource, providing all the information needed to effectively apply the USC COCOMO II tool. For the student studying software economics, it complements Boehm's original text, omitting the broader discussions of software project management still valid in the earlier book, while providing insight into the changes in software development practice that have occurred over the past twenty years and which have made the development of COCOMO II necessary.

COCOMO 81 is a model that allows one to estimate the cost, effort, and schedule when planning a new software development activity, according to software development practices that were commonly used in the 1970s through the 1980s. It exists in three forms, each one offering greater detail and accuracy the further along one is in the project planning and design process. Listed by increasing fidelity, these forms are called Basic, Intermediate, and Detailed COCOMO. However, only the Intermediate form has been implemented by USC in a calibrated software tool.

The implemented tool provides cost, effort, and schedule point estimates. It also allows a planner to easily perform "what if" scenario exploration, by quickly demonstrating the effect adjusting requirements, resources, and staffing might have on predicted costs and schedules (e.g., for risk management or job bidding purposes). Over 63 data points in the COCOMO 81 calibration database, the Intermediate form demonstrates an accuracy of within 20% of actuals 68% of the time for effort, and within 20% of actuals 58% of the time for a nonincremental development schedule.

COCOMO 81 has a rich legacy. Originally published by Dr. Barry Boehm in 1981 under the simple name COCOMO, it went on to become (and arguably remains) the most widely used software project cost estimation model throughout the world. It has also existed in other incarnations, the most prominent being Ada COCOMO. After nearly twenty years of solid service, however, it is finally being retired in favor of COCOMO II, which models the way software is built today in the 1990s, and will continue to be built well into the new century.

Boehm, Barry W., Software Engineering Economics, Prentice Hall, 1981.

Dr. Boehm's 1981 book is still the most complete resource for information regarding original COCOMO, as well as providing a wealth of material that will improve one's understanding and application of COCOMO II.

Copyright 1995-2001 The University of Southern California

Webmaster@SchemeQuest.com
Copyright © 2001-2003 SchemeQuest
Last modified: November 22, 2003