COCOMO II
Model Definition Manual

Version 2.1
© 1995 – 2000 Center for Software Engineering, USC
Table of Contents
Acknowledgements ..........................................................................................
Acknowledgements
The COCOMO II model is part of a suite of Constructive Cost Models. This suite is an
effort to update and...
Copyright Notice
This document is copyrighted, and all rights are reserved by the Center for Software Engineering
at the U...
1. Introduction
1.1

Overview

This manual presents two models, the Post-Architecture and Early Design models. These
two m...
COCOMO II.2000 schedule equation are obtained by calibration to the actual schedule values
for the 161 project currently i...
2. Sizing
A good size estimate is very important for a good model estimation. However,
determining size can be challenging...
Some changes were made to the line-of-code definition that departs from the default
definition provided in [Park 1992]. Th...
5% limit on the effect of reuse is inconsistent with COCOMO experience; thus COCOMO II
uses Unadjusted Function Points for...
Table 3.

UFP Complexity Weights

Function Type
Internal Logical Files
External Interfaces Files
External Inputs
External ...
USR_1 through USR_5 are five extra slots provided by USC COCOMO II.2000 to
accommodate user-specified additional implement...
AAM Worst Case:
AAF = varies
AA = 8
SU = 50
UNFM = 1

1.5

AAM
1.0

Relative Cost

Selby data
summary

AAM Best Case:
AAF ...
For m = 10
50
40

N

30
20
10
0
0

2

4

6

8

10

k

Figure 2. Number of Module Interface Checks, N, vs. Modules Modified...
10%. If the software is rated very low on these factors, the penalty is 50%. SU is determined by
taking the subjective ave...
Table 7.

Rating Scale for Programmer Unfamiliarity (UNFM)

UNFM Increment
0.0
0.2
0.4
0.6
0.8
1.0

Level of Unfamiliarity...
Since there is no source code modified in reused and COTS, DM=0, CM=0, and SU and
UNFM don’t apply. AA and IM can have non...
2.6

Automatically Translated Code

The COCOMO II reuse model needs additional refinement to estimate the costs of
softwar...
estimates as most of the product was not being touched by the changes. COCOMO II accounts
for the effects of the product b...
3. Effort Estimation
In COCOMO II effort is expressed as Person-Months (PM). A person month is the
amount of time one pers...
causes more software development effort, then its corresponding EM is above 1.0. Conversely,
if the rating level reduces t...
16000
B=1.226

14000

Person Months

12000
10000
8000
6000
B=1.00

4000
2000

B=0.91

0
0

500

1000

KSLOC

Figure 3. Dis...
Table 10. Scale Factor Values, SFj, for COCOMO II Models
Scale
Factors

SFj:
FLEX
SFj:
RESL
SFj:

Low

Nominal

thoroughly...
Table 11. Precedentedness Rating Levels
Feature

Very Low

Extra High

Considerable

Need for innovative data processing
a...
Table 13. RESL Rating Levels
Characteristic
Percent of required top
software architects available
to project.
Tool support...
The procedure for determining PMAT is organized around the Software Engineering
Institute’s Capability Maturity Model (CMM...
Rarely if Ever

Does Not Apply

Software Project Tracking and Oversight
• Actual results and performances are tracked agai...
Rarely if Ever

Does Not Apply

Training Program
• Training activities are planned.
• Training for developing the skills a...
Rarely if Ever

Does Not Apply

Technology Change Management
• Incorporation of technology changes are planned.
• New tech...
3.2

Effort Multipliers

3.2.1 Post-Architecture Cost Drivers
This model is the most detailed. It is intended to be used w...
Table 17. RELY Cost Driver
RELY
Descriptors:

Rating Levels
Effort Multipliers

slight
inconvenience
Very Low
0.82

low, e...
Table 19. Component Complexity Ratings Levels
Devicedependent
Operations

Data
Management
Operations

Evaluation of
simple...
Table 19. Component Complexity Ratings Levels
Data
Management
Operations

User Interface
Management
Operations

Operations...
Developed for Reusability (RUSE)
This cost driver accounts for the additional effort needed to construct components
intend...
3.2.1.2

Platform Factors

The platform refers to the target-machine complex of hardware and infrastructure
software (prev...
and the distributed information repositories. The platform includes any compilers or assemblers
supporting the development...
should not be considered here; it is rated with APEX, LTEX, and PLEX. A very low rated
programmer team is in the fifteenth...
Table 30. PLEX Cost Driver
PLEX Descriptors:
Rating Levels
Effort Multipliers

≤ 2 months
Very Low
1.19

6 months
Low
1.09...
Table 32. TOOL Cost Driver
TOOL
Descriptors

Rating Levels
Effort Multipliers

edit, code,
debug

Very Low
1.17

simple,
f...
further research in concert with our emerging CORADMO extension to address rapid application
development (goto http://suns...
Table 35. Early Design and Post-Architecture Effort Multipliers
Early Design Cost Driver
PERS
RCPX
RUSE
PDIF
PREX
FCIL
SCE...
Table 36. PERS Cost Driver
PERS Descriptors:
• Annual Personnel Turnover
Rating Levels
Effort Multipliers

45%
Extra
Low
2...
Table 37. RCPX Cost Driver
RCPX Descriptors:
Rating Levels

Extra
Low
0.49

Effort Multipliers

Very
Low
0.60

Low
0.83

N...
Table 39. PREX Cost Driver
PREX Descriptors:
Rating Levels
Effort Multipliers

Extra
Low
1.59

Very
Low
1.33

Low
1.22

No...
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Cii modelma
Upcoming SlideShare
Loading in …5
×

Cii modelma

819 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
819
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cii modelma

  1. 1. COCOMO II Model Definition Manual Version 2.1 © 1995 – 2000 Center for Software Engineering, USC
  2. 2. Table of Contents Acknowledgements .........................................................................................................................ii Copyright Notice ............................................................................................................................iii Warranty.........................................................................................................................................iii 1. Introduction ............................................................................................................................... 1 1.1 Overview.......................................................................................................................... 1 1.2 Nominal-Schedule Estimation Equations ........................................................................ 1 2. Sizing......................................................................................................................................... 3 2.1 Counting Source Lines of Code (SLOC)......................................................................... 3 2.2 Counting Unadjusted Function Points (UFP) .................................................................. 4 2.3 Relating UFPs to SLOC................................................................................................... 6 2.4 Aggregating New, Adapted, and Reused Code ............................................................... 7 2.5 Requirements Evolution and Volatility (REVL) ........................................................... 12 2.6 Automatically Translated Code ..................................................................................... 13 2.7 Sizing Software Maintenance ........................................................................................ 13 3. Effort Estimation ..................................................................................................................... 15 3.1 Scale Factors .................................................................................................................. 16 3.2 Effort Multipliers ........................................................................................................... 25 3.3 Multiple Module Effort Estimation ............................................................................... 39 4. Schedule Estimation................................................................................................................ 41 5. Software Maintenance............................................................................................................. 42 6. COCOMO II: Assumptions and phase/activity distributions.................................................. 44 6.1 Introduction.................................................................................................................... 44 6.2 Waterfall and MBASE/RUP Phase Definitions ............................................................ 45 6.3 Phase Distribution of Effort and Schedule .................................................................... 49 6.4 Waterfall and MBASE/RUP Activity Definitions......................................................... 53 6.5 Distribution of Effort Across Activities ........................................................................ 61 6.6 Definitions and Assumptions......................................................................................... 66 7. Model Calibration to the Local Environment ......................................................................... 68 8. Summary ................................................................................................................................. 71 8.1 Models ........................................................................................................................... 71 8.2 Rating Scales ................................................................................................................. 73 8.3 COCOMO II Version Parameter Values ....................................................................... 75 8.4 Source Code Counting Rules......................................................................................... 77 Acronyms and Abbreviations........................................................................................................ 81 References ..................................................................................................................................... 85 Version 2.1 © 1995 – 2000 Center for Software Engineering, USC i
  3. 3. Acknowledgements The COCOMO II model is part of a suite of Constructive Cost Models. This suite is an effort to update and extend the well-known COCOMO (Constructive Cost Model) software cost estimation model originally published in Software Engineering Economics by Barry Boehm in 1981. The suite of models focuses on issues such as non-sequential and rapid-development process models; reuse driven approaches involving commercial-off-the-shelf (COTS) packages, reengineering, applications composition, and software process maturity effects and processdriven quality estimation. Research on the COCOMO suite of models is being led by the Director of the Center of Software Engineering at USC, Barry Boehm and other researchers (listed in alphabetic order): Chris Abts Ellis Horowitz A. Winsor Brown Ray Madachy Sunita Chulani Don Reifer Brad Clark Bert Steece This work is being supported financially and technically by the COCOMO II Program Affiliates: Aerospace, Air Force Cost Analysis Agency, Allied Signal, DARPA, DISA, Draper Lab, EDS, E-Systems, FAA, Fidelity, GDE Systems, Hughes, IDA, IBM, JPL, Litton, Lockheed Martin, Loral, Lucent, MCC, MDAC, Microsoft, Motorola, Northrop Grumman, ONR, Rational, Raytheon, Rockwell, SAIC, SEI, SPC, Sun, TASC, Teledyne, TI, TRW, USAF Rome Lab, US Army Research Labs, US Army TACOM, Telcordia, and Xerox. The successive versions of the tool based on the COCOMO II model have been developed as part of a Graduate Level Course Project by several student development teams lead by Ellis Horowitz. The latest version, USC COCOMO II.2000, was developed by the following graduate student: Jongmoon Baik Version 2.1 © 1995 – 2000 Center for Software Engineering, USC ii
  4. 4. Copyright Notice This document is copyrighted, and all rights are reserved by the Center for Software Engineering at the University of Southern California (USC). Permission to make digital or hard copies of part of all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation of the first page. Abstracting with credit is permitted. To copy otherwise, to republish, to post on Internet servers, or to redistribute to lists requires prior specific permission and/or fee. Copyright © 1995 – 2000 Center for Software Engineering, USC All rights reserved. Warranty This manual is provided “as is” without warranty of any kind, either express or implied, including, but not limited to the implied warranties of merchantability and fitness for a particular purpose. Moreover, the Center for Software Engineering, USC, reserves the right to revise this manual and to make changes periodically without obligation to notify any person or organization of such revision or changes. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC iii
  5. 5. 1. Introduction 1.1 Overview This manual presents two models, the Post-Architecture and Early Design models. These two models are used in the development of Application Generator, System Integration, or Infrastructure developments [Boehm et al. 2000]. The Post-Architecture is a detailed model that is used once the project is ready to develop and sustain a fielded system. The system should have a life-cycle architecture package, which provides detailed information on cost driver inputs, and enables more accurate cost estimates. The Early Design model is a high-level model that is used to explore of architectural alternatives or incremental development strategies. This level of detail is consistent with the general level of information available and the general level of estimation accuracy needed. The Post-Architecture and Early Design models use the same approach for product sizing (including reuse) and for scale factors. These will be presented first. Then, the Post-Architecture model will be explained followed by the Early Design model. 1.2 Nominal-Schedule Estimation Equations Both the Post-Architecture and Early Design models use the same functional form to estimate the amount of effort and calendar time it will take to develop a software project. These nominal-schedule (NS) formulas exclude the cost driver for Required Development Schedule, SCED. The full formula is given in Section 3. The amount of effort in person-months, PMNS, is estimated by the formula: n PM NS = A × Size × ∏ EM i E i =1 5 where E = B + 0.01 × ∑ SFj Eq. 1 j=1 The amount of calendar time, TDEVNS, it will take to develop the product is estimated by the formula: TDEVNS = C × (PM NS ) F 5 where F = D + 0.2 × 0.01 × ∑ SFj Eq. 2 j=1 = D + 0.2 × (E − B) The value of n, the number of effort multipliers, EMi, is 16 for the Post-Architecture model effort multipliers, EMi, and 6 for the Early Design model. SFj stands for the exponential scale factors. The values of A, B, EM1, …, EM16, SF1, …, and SF5 for the COCOMO II.2000 Post-Architecture model are obtained by calibration to the actual parameters and effort values for the 161 projects currently in the COCOMO II database. The values of C and D for the Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 1
  6. 6. COCOMO II.2000 schedule equation are obtained by calibration to the actual schedule values for the 161 project currently in the COCOMO II database. The values of A, B, C, D, SF1, …, and SF5 for the Early Design model are the same as those for the Post-Architecture model. The values of EM1, …, and EM6 for the Early Design model are obtained by combining the values of their 16 Post-Architecture counterparts; the specific combinations are given in Section 3.2.2. The subscript NS applied to PM and TDEV indicates that these are the nominal-schedule estimates of effort and calendar time. The effects of schedule compression or stretch-out are covered by an additional cost driver, Required Development Schedule. They are also included in the COCOMO II.2000 calibration to the 161 projects. Its specific effects are given in Section 4. The specific milestones used as the end points in measuring development effort and calendar time are defined in Section 6, as are the other definitions and assumptions involved in defining development effort and calendar time. Size is expressed as thousands of source lines of code (SLOC) or as unadjusted function points (UFP), as discussed in Section 2. Development labor cost is obtained by multiplying effort in PM by the average labor cost per PM. The values of A, B, C, and D in the COCOMO II.2000 calibration are: A = 2.94 C = 3.67 B = 0.91 D = 0.28 Details of the calibration are presented in Section 7, which also provides formulas for calibrating either A and C or A, B, C, and D to one’s own database of projects. It is recommended that at least A and C be calibrated to the local development environment to increase the model’s accuracy. As an example, let's estimate how much effort and calendar time it would take to develop an average 100 KSLOC sized project. For an average project, the effort multipliers are all equal to 1.0. E will be set to 1.15 reflecting an average, large project. The estimated effort is PMNS = 2.94(100)1.15 = 586.61. × Continuing the example, the duration is estimated as TDEVNS = 3.67(586.6)(0.28+0.2 (1.150.328 = 3.67(586.6) = 29.7 months. The average number of staff required for the nominalschedule development is PMNS / TDEVNS = 586.6 / 29.7 = 19.75 or about 20 people. In this example, an average 100 KSLOC software project will take about 30 months to complete with an average of 20 people. 0.91)) Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 2
  7. 7. 2. Sizing A good size estimate is very important for a good model estimation. However, determining size can be challenging. Projects are generally composed of new code, code reused from other sources--with or without modifications--and automatically translated code. COCOMO II only uses size data that influences effort which is new code and code that is copied and modified. For new and reused code, a method is used to make them equivalent so they can be rolled up into an aggregate size estimate. The baseline size in COCOMO II is a count of new lines of code. The count for code that is copied and then modified has to be adjusted to create a count that is equivalent to new lines of code. The adjustment takes into account the amount of design, code and testing that was changed. It also considers the understandability of the code and the programmer familiarity with the code. For automatically translated code, a separate translation productivity rate is used to determine effort from the amount of code to be translated. The following sections discuss sizing new code and reused code. 2.1 Counting Source Lines of Code (SLOC) There are several sources for estimating new lines of code. The best source is historical data. For instance, there may be data that will convert Function Points, components, or anything available early in the project to estimate lines of code. Lacking historical data, expert opinion can be used to derive estimates of likely, lowest-likely, and highest-likely size. Code size is expressed in thousands of source lines of code (KSLOC). A source line of code is generally meant to exclude non-delivered support software such as test drivers. However, if these are developed with the same care as delivered software, with their own reviews, test plans, documentation, etc., then they should be counted [Boehm 1981, pp. 58-59]. The goal is to measure the amount of intellectual work put into program development. Defining a line of code is difficult because of conceptual differences involved in accounting for executable statements and data declarations in different languages. Difficulties arise when trying to define consistent measures across different programming languages. In COCOMO II, the logical source statement has been chosen as the standard line of code. The Software Engineering Institute (SEI) definition checklist for a logical source statement is used in defining the line of code measure. The SEI has developed this checklist as part of a system of definition checklists, report forms and supplemental forms to support measurement definitions [Park 1992; Goethert et al. 1992]. A SLOC definition checklist is used to support the development of the COCOMO II model. The full checklist is provided at the end of this manual, Table 64. Each checkmark in the “Includes” column identifies a particular statement type or attribute included in the definition, and vice versa for the excludes. Other sections in the definition clarify statement attributes for usage, delivery, functionality, replications and development status. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 3
  8. 8. Some changes were made to the line-of-code definition that departs from the default definition provided in [Park 1992]. These changes eliminate categories of software, which are generally small sources of project effort. For example, not included in the definition are commercial-off-the-shelf software (COTS), government-furnished software (GFS), other products, language support libraries and operating systems, or other commercial libraries. Code generated with source code generators is handled by counting separate operator directives as lines of source code. It is admittedly difficult to count "directives" in a highly visual programming system. As this approach becomes better understood, we hope to provide more specific counting rules. For general source code sizing approaches, such as PERT sizing, expert consensus, analogy, top-down, and bottom-up, see Section 21.4 and Chapter 22 of [Boehm 1981]. 2.2 Counting Unadjusted Function Points (UFP) The function point cost estimation approach is based on the amount of functionality in a software project and a set of individual project factors [Behrens 1983; Kunkler 1985; IFPUG 1994]. Function points are useful estimators since they are based on information that is available early in the project life-cycle. A brief summary of function points and their calculation in support of COCOMO II follows. Function points measure a software project by quantifying the information processing functionality associated with major external data or control input, output, or file types. Five user function types should be identified as defined in Table 1. Table 1. User Function Types Function Point External Input (EI) External Output (EO) Internal Logical File (ILF) External Interface Files (EIF) External Inquiry (EQ) Description Count each unique user data or user control input type that enters the external boundary of the software system being measured. Count each unique user data or control output type that leaves the external boundary of the software system being measured. Count each major logical group of user data or control information in the software system as a logical internal file type. Include each logical file (e.g., each logical group of data) that is generated, used, or maintained by the software system. Files passed or shared between software systems should be counted as external interface file types within each system. Count each unique input-output combination, where input causes and generates an immediate output, as an external inquiry type. Each instance of these function types is then classified by complexity level. The complexity levels determine a set of weights, which are applied to their corresponding function counts to determine the Unadjusted Function Points quantity. This is the Function Point sizing metric used by COCOMO II. The usual Function Point procedure, which is not followed by COCOMO II, involves assessing the degree of influence (DI) of fourteen application characteristics on the software project determined according to a rating scale of 0.0 to 0.05 for each characteristic. The 14 ratings are added together and then added to a base level of 0.65 to produce a general characteristic adjustment factor that ranges from 0.65 to 1.35. Each of these fourteen characteristics, such as distributed functions, performance, and reusability, thus have a maximum of 5% contribution to estimated effort. Having, for example, a Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 4
  9. 9. 5% limit on the effect of reuse is inconsistent with COCOMO experience; thus COCOMO II uses Unadjusted Function Points for sizing, and applies its reuse factors, cost drivers, and scale factors to this sizing quantity to account for the effects of reuse, distribution, etc. on project effort. The COCOMO II procedure for determining Unadjusted Function Points follows the definitions in [IFPUG 1994]. This four step procedure, which follows, is used in both the Early Design and the Post-Architecture models. 1. Determine function counts by type. The unadjusted function counts should be counted by a lead technical person based on information in the software requirements and design documents. The number of each of the five user function types should be counted (Internal Logical File (ILF), External Interface File (EIF), External Input (EI), External Output (EO), and External Inquiry (EQ)). See [IFPUG 1994] for more detailed interpretations of the counting rules for those quantities. 2. Determine complexity levels. Classify each function count into Low, Average and High complexity levels depending on the number of data element types contained and the number of file types referenced. Use the scheme in Table 2. Table 2. FP Counting Weights For Internal Logical Files and External Interface Files Data Elements Record Elements 1 - 19 20 - 50 51+ 1 2-5 6+ Low Low Avg. Low Avg. High Avg. High High For External Output and External Inquiry Data Elements File Types 1-5 6 - 19 20+ 0 or 1 2-3 4+ Low Low Avg. Low Avg. High Avg. High High For External Input Data Elements File Types 1-4 5 - 15 16+ 0 or 1 2-3 3+ Low Low Avg. Low Avg. High Avg. High High 3. Apply complexity weights. Weight the number of function types at each complexity level using the following scheme (the weights reflect the relative effort required to implement the function): Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 5
  10. 10. Table 3. UFP Complexity Weights Function Type Internal Logical Files External Interfaces Files External Inputs External Outputs External Inquiries Complexity-Weight Low Average High 7 5 3 4 3 10 7 4 5 4 15 10 6 7 6 4. Compute Unadjusted Function Points. Add all the weighted functions counts to get one number, the Unadjusted Function Points. 2.3 Relating UFPs to SLOC Next, convert the Unadjusted Function Points (UFP) to Lines of Code. The unadjusted function points have to be converted to source lines of code in the implementation language (Ada, C, C++, Pascal, etc.). COCOMO II does this for both the Early Design and PostArchitecture models by using backfiring tables to convert Unadjusted Function Points into equivalent SLOC. The current conversion ratios shown in Table 4 are from [Jones 1996]. Updates to these conversion ratios as well as additional ratios can be found at http://www.spr.com/library/0Langtbl.htm. Table 4. Language Access Ada 83 Ada 95 AI Shell APL Assembly - Basic Assembly - Macro Basic - ANSI Basic - Compiled Basic - Visual C C++ Cobol (ANSI 85) Database – Default Fifth Generation Language First Generation Language Forth Fortran 77 Fortran 95 Fourth Generation Language High Level Language HTML 3.0 Java UFP to SLOC Conversion Ratios Default SLOC / UFP 38 71 49 49 32 320 213 64 91 32 128 55 91 40 4 320 64 107 71 20 64 15 53 Version 2.1 © 1995 – 2000 Center for Software Engineering, USC Language Jovial Lisp Machine Code Modula 2 Pascal PERL PowerBuilder Prolog Query – Default Report Generator Second Generation Language Simulation – Default Spreadsheet Third Generation Language Unix Shell Scripts USR_1 USR_2 USR_3 USR_4 USR_5 Visual Basic 5.0 Visual C++ Default SLOC / UFP 107 64 640 80 91 27 16 64 13 80 107 46 6 80 107 1 1 1 1 1 29 34 6
  11. 11. USR_1 through USR_5 are five extra slots provided by USC COCOMO II.2000 to accommodate user-specified additional implementation languages. These ratios are easy to determine with historical data or with a recently completed project. It would be prudent to determine your own ratios for your local environment. 2.4 Aggregating New, Adapted, and Reused Code A product’s size discussed thus far has been for new development. Code that is taken from another source and used in the product under development also contributes to the product's effective size. Preexisting code that is treated as a black-box and plugged into the product is called reused code. Preexisting code that is treated as a white-box and is modified for use with the product is called adapted code. The effective size of reused and adapted code is adjusted to be its equivalent in new code. The adjusted code is called equivalent source lines of code (ESLOC). The adjustment is based on the additional effort it takes to modify the code for inclusion in the product. The sizing model treats reuse with function points and source lines of code the same in either the Early Design model or the Post-Architecture model. 2.4.1 Nonlinear Reuse Effects Analysis in [Selby 1988] of reuse costs across nearly three thousand reused modules in the NASA Software Engineering Laboratory indicates that the reuse cost function, relating the amount of modification of the reused code to the resulting cost to reuse, is nonlinear in two significant ways (see Figure 1). The effort required to reuse code does not start at zero. There is generally a cost of about 5% for assessing, selecting, and assimilating the reusable component. Figure 1 shows the results of the NASA analysis as blocks of relative cost. A dotted line is superimposed on the blocks of relative cost to show increasing cost as more of the reused code is modified. (The solid lines are labeled AAM for Adaptation Adjustment Modifier. AAM is explained in Equation 4.) It can be seen that small modifications in the reused product generate disproportionately large costs. This is primarily because of two factors: the cost of understanding the software to be modified, and the relative cost of checking module interfaces. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 7
  12. 12. AAM Worst Case: AAF = varies AA = 8 SU = 50 UNFM = 1 1.5 AAM 1.0 Relative Cost Selby data summary AAM Best Case: AAF = varies AA = 0 SU = 10 UNFM = 0 0.5 [Selby 1988] 0.045 0.0 0.0 50 100 Relative Modification of Size (AAF) Figure 1. Non-Linear Reuse Effects [Parikh-Zvegintzov 1983] contains data indicating that 47% of the effort in software maintenance involves understanding the software to be modified. Thus, as soon as one goes from unmodified (black-box) reuse to modified-software (white-box) reuse, one encounters this software understanding penalty. Also, [Gerlich-Denskat 1994] shows that, if one modifies k out of m software modules, the number of module interface checks required, N, is expressed in Equation 3.  k − 1 N = k × (m - k ) + k ×    2  Eq. 3 Figure 2 shows this relation between the number of modules modified k and the resulting number, N, of module interface checks required for an example of m = 10 modules. In this example, modifying 20% (2 of 10) of the modules required revalidation of 38% (17 of 45) of the interfaces. The shape of this curve is similar for other values of m. It indicates that there are nonlinear effects involved in the module interface checking which occurs during the design, code, integration, and test of modified software. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 8
  13. 13. For m = 10 50 40 N 30 20 10 0 0 2 4 6 8 10 k Figure 2. Number of Module Interface Checks, N, vs. Modules Modified, k The size of both the software understanding penalty and the module interface-checking penalty can be reduced by good software structuring. Modular, hierarchical structuring can reduce the number of interfaces which need checking [Gerlich-Denskat 1994], and software that is well-structured, explained, and related to its mission will be easier to understand. COCOMO II reflects this in its allocation of estimated effort for modifying reusable software. 2.4.2 A Reuse Model The COCOMO II treatment of software reuse uses a nonlinear estimation model, Equation 4. This involves estimating the amount of software to be adapted and three degree-ofmodification factors: the percentage of design modified (DM), the percentage of code modified (CM), and the percentage of integration effort required for integrating the adapted or reused software (IM). These three factors use the same linear model as used in COCOMO 81, but COCOMO II adds some nonlinear increments to the relation of Adapted KSLOC of Equivalent KSLOC to reflect the non-linear tendencies of the model. These are explained next.  AT  Equivalent KSLOC = Adapted KSLOC × 1 −  × AAM  100  [AA + AAF(1 + (0.02 × SU × UNFM))] , for AAF ≤ 50   100 where AAM =  [AA + AAF + (SU × UNFM)] , for AAF > 50  100  AAF = (0.4 × DM ) + (0.3 × CM ) + (0.3 × IM ) Eq. 4 The Software Understanding increment (SU) is obtained from Table 5. SU is expressed quantitatively as a percentage. If the software is rated very high on structure, applications clarity, and self-descriptiveness, the software understanding and interface-checking penalty is Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 9
  14. 14. 10%. If the software is rated very low on these factors, the penalty is 50%. SU is determined by taking the subjective average of the three categories. Table 5. Rating Scale for Software Understanding Increment SU Very Low Application Clarity SelfDescriptiveness Nominal High Very High Very low cohesion, high coupling, spaghetti code. Structure Low Moderately low cohesion, high coupling. Reasonably well-structured; some weak areas. High cohesion, low coupling. No match between program and application world-views. Obscure code; documentation missing, obscure or obsolete. Some correlation between program and application. Some code commentary and headers; some useful documentation. Moderate correlation between program and application. Moderate level of code commentary, headers, documentation. Good correlation between program and application. Good code commentary and headers; useful documentation; some weak areas. Strong modularity, information hiding in data / control structures. Clear match between program and application world-views. Self-descriptive code; documentation up-to-date, well-organized, with design rationale. 50 40 30 20 10 SU Increment to ESLOC The other nonlinear reuse increment deals with the degree of Assessment and Assimilation (AA) needed to determine whether a reused software module is appropriate to the application, and to integrate its description into the overall product description. Table 6 provides the rating scale and values for the assessment and assimilation increment. AA is a percentage. Table 6. Rating Scale for Assessment and Assimilation Increment (AA) AA Increment 0 2 4 6 8 Level of AA Effort None Basic module search and documentation Some module Test and Evaluation (T&E), documentation Considerable module T&E, documentation Extensive module T&E, documentation The amount of effort required to modify existing software is a function not only of the amount of modification (AAF) and understandability of the existing software (SU), but also of the programmer’s relative unfamiliarity with the software (UNFM). The UNFM factor is applied multiplicatively to the software understanding effort increment. If the programmer works with the software every day, the 0.0 multiplier for UNFM will add no software understanding increment. If the programmer has never seen the software before, the 1.0 multiplier will add the full software understanding effort increment. The rating of UNFM is shown in Table 7. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 10
  15. 15. Table 7. Rating Scale for Programmer Unfamiliarity (UNFM) UNFM Increment 0.0 0.2 0.4 0.6 0.8 1.0 Level of Unfamiliarity Completely familiar Mostly familiar Somewhat familiar Considerably familiar Mostly unfamiliar Completely unfamiliar Equation 4 is used to determine an equivalent number of new source lines of code. The calculation of equivalent SLOC is based on the product size being adapted and a modifier that accounts for the effort involved in fitting adapted code into an existing product, called Adaptation Adjustment Modifier (AAM). The term (1 – AT/100) is for automatically translated code and is discussed in Section 2.2.6. AAM uses the factors discussed above, Software Understanding (SU), Programmer Unfamiliarity (UNFM), and Assessment and Assimilation (AA) with a factor called the Adaptation Adjustment Factor (AAF). AAF contains the quantities DM, CM, and IM where: • DM (Percent Design Modified) is the percentage of the adapted software’s design which is modified in order to adapt it to the new objectives and environment. (This is necessarily a subjective quantity.) • CM (Percent Code Modified) is the percentage of the adapted software’s code which is modified in order to adapt it to the new objectives and environment. • IM (Percent of Integration Required for Adapted Software) is the percentage of effort required to integrate the adapted software into an overall product and to test the resulting product as compared to the normal amount of integration and test effort for software of comparable size. If there is no DM or CM (the component is being used unmodified) then there is no need for SU. If the code is being modified then SU applies. The range of AAM is shown in Figure 1. Under the worst case, it can take twice the effort to modify a reused module than it takes to develop it as new (the value of AAM can exceed 100). The best case follows a one for one correspondence between adapting an existing product and developing it from scratch. 2.4.3 Guidelines for Quantifying Adapted Software This section provides guidelines to estimate adapted software factors for different categories of code using COCOMO II. The New category refers to software developed from scratch. Adapted code is preexisting code that has some changes to it, while reused code has no changes to the preexisting source (i.e. used as-is). COTS is off-the-shelf software that is generally treated the same as reused code when there are no changes to it. One difference is that there may be some new glue code associated with it that also needs to be counted (this may happen with reused software, but here the option of modifying the source code may make adapting the software more attractive). Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 11
  16. 16. Since there is no source code modified in reused and COTS, DM=0, CM=0, and SU and UNFM don’t apply. AA and IM can have non-zero values in this case. Reuse doesn’t mean free integration and test. However in the reuse approach, with well-architected product-lines, the integration and test is minimal. For adapted software, CM > 0, DM is usually > 0, and all other reuse factors normally have non-zero values. IM is expected to be at least moderate for adapted software, but can be higher than 100% for adaptation into more complex applications. Table 8 shows the valid ranges of reuse factors with additional notes for the different categories. Table 8. Code Category Adapted Software Parameter Constraints and Guidelines DM CM Reuse Parameters IM AA UNFM 0% - 50% 0-1 not applicable New all original software Adapted changes to preexisting software + 0% - 100% normally > 0% 0 % - 100% usually > DM and must be > 0% Reused unchanged existing software 0% 0% COTS off-the-shelf software (often requires new glue code as a wrapper around the COTS) 0% 0% 2.5 SU 0% - 100+% IM usually moderate and can be > 100% 0% - 100% rarely 0%, but could be very small 0% - 100% 0% – 8% 0% – 8% not applicable 0% – 8% not applicable Requirements Evolution and Volatility (REVL) COCOMO II uses a factor called REVL, to adjust the effective size of the product caused by requirements evolution and volatility caused by such factors as mission or user interface evolution, technology upgrades, or COTS volatility. It is the percentage of code discarded due to requirements evolution. For example, a project which delivers 100,000 instructions but discards the equivalent of an additional 20,000 instructions has an REVL value of 20. This would be used to adjust the project’s effective size to 120,000 instructions for a COCOMO II estimation. The use of REVL for computing size in given in Equation 5.  REVL  Size = 1 +  × Size D 100   where Size D is the reuse - equivalent of the delivered software. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC Eq. 5 12
  17. 17. 2.6 Automatically Translated Code The COCOMO II reuse model needs additional refinement to estimate the costs of software reengineering and conversion. The major difference in reengineering and conversion is the efficiency of automated tools for software restructuring. These can lead to very high values for the percentage of code modified (CM in the COCOMO II reuse model), but with very little corresponding effort. For example, in the NIST reengineering case study [Ruhl-Gunn 1991], 80% of the code (13,131 COBOL source statements) was re-engineered by automatic translation, and the actual reengineering effort, 35 Person-Months, was more than a factor of 4 lower than the COCOMO estimate of 152 person months. The COCOMO II reengineering and conversion estimation approach involves estimating an additional factor, AT, the percentage of the code that is re-engineered by automatic translation. Based on an analysis of the project data above, the default productivity value for automated translation is 2400 source statements per person month. This value could vary with different technologies and is designated in the COCOMO II model as another factor called ATPROD. In the NIST case study ATPROD = 2400. Equation 6 shows how automated translation affects the estimated effort, PMAuto. PM Auto = ( Adapted SLOC × AT 100 ) ATPROD Eq. 6 The NIST case study also provides useful guidance on estimating the AT factor, which is a strong function of the difference between the boundary conditions (e.g., use of COTS packages, change from batch to interactive operation) of the old code and the re-engineered code. The NIST data on percentage of automated translation (from an original batch processing application without COTS utilities) are given in Table 9 [Ruhl-Gunn 1991]. Table 9. Variation in Percentage of Automated Re-engineering Re-engineering Target AT (% automated translation) Batch processing Batch with SORT Batch with DBMS Batch, SORT, DBMS Interactive 96% 90% 88% 82% 50% Automated translation is considered to be a separate activity from development. Thus, its Adapted SLOC are not included as Size in Equivalent KSLOC, and its PMAUTO are not included in PMNS in estimating the project’s schedule. If the automatically translated Adapted SLOC count is included as Size in the Equivalent KSLOC, it must be backed out to prevent double counting. This is done by adding the term (1 – AT/100) to the equation for Equivalent KSLOC, Equation 2.4. 2.7 Sizing Software Maintenance COCOMO II differs from COCOMO 81 in applying the COCOMO II scale factors to the size of the modified code rather than applying the COCOMO 81 modes to the size of the product being modified. Applying the scale factors to a 10 million SLOC product produced overlarge Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 13
  18. 18. estimates as most of the product was not being touched by the changes. COCOMO II accounts for the effects of the product being modified via its software understanding and unfamiliarity factors discussed for reuse in Section 2.4.2. The scope of “software maintenance” follows the COCOMO 81 guidelines in [Boehm 1981; pp.534-536]. It includes adding new capabilities and fixing or adapting existing capabilities. It excludes major product rebuilds changing over 50% of the existing software, and development of sizable (over 20% changed) interfacing systems requiring little rework of the existing system. The maintenance size is normally obtained via Equation 7, when the base code size is known and the percentage of change to the base code is known. (Size) M = [(Base Code Size) × MCF]× MAF Eq. 7 The Maintenance Adjustment Factor (MAF) is discussed below. But first, the percentage of change to the base code is called the Maintenance Change Factor (MCF). The MCF is similar to the Annual Change Traffic in COCOMO 81, except that maintenance periods other than a year can be used. Conceptually the MCF represents the ratio in Equation 8: MCF = Size Added + Size Modified Base Code Size Eq. 8 A simpler version can be used when the fraction of code added or modified to the existing base code during the maintenance period is known. Deleted code is not counted. (Size) M = (Size Added + Size Modified) × MAF Eq. 9 The size can refer to thousands of source lines of code (KSLOC), Function Points, or Application Points. When using Function Points or Application Points, it is better to estimate MCF in terms of the fraction of the overall application being changed, rather than the fraction of inputs, outputs, screens, reports, etc. touched by the changes. Our experience indicates that counting the items touched can lead to significant over estimates, as relatively small changes can touch a relatively large number of items. In some very large COBOL programs, we found ratios of 2 to 3 FP-touched/SLOC-changed as compared to 91 FP/SLOC for development. The Maintenance Adjustment Factor (MAF), Equation 10, is used to adjust the effective maintenance size to account for software understanding and unfamiliarity effects, as with reuse. COCOMO II uses the Software Understanding (SU) and Programmer Unfamiliarity (UNFM) factors from its reuse model (discussed in Section 2.4.2) to model the effects of well or poorly structured/understandable software on maintenance effort.  SU  MAF = 1 +  × UNFM   100  Eq. 10 The use of (Size)M in determining maintenance effort, Equation 9, is discussed in Section 5. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 14
  19. 19. 3. Effort Estimation In COCOMO II effort is expressed as Person-Months (PM). A person month is the amount of time one person spends working on the software development project for one month. COCOMO II treats the number of person-hours per person-month, PH/PM, as an adjustable factor with a nominal value of 152 hours per Person-Month. This number excludes time typically devoted to holidays, vacations, and weekend time off. The number of person-months is different from the time it will take the project to complete; this is called the development schedule or Time to Develop, TDEV. For example, a project may be estimated to require 50 PM of effort but have a schedule of 11 months. If you use a different value of PH/PM–say, 160 instead of 152–COCOMO II adjusts the PM estimate accordingly (in this case, reducing by about 5%). This reduced PM will result in a smaller estimate of development schedule. The COCOMO II effort estimation model was introduced in Equation 1, and is summarized in Equation 11. This model form is used for both the Early Design and PostArchitecture cost models to estimate effort between the end points of LCO and IOC for the MBASE/RUP and SRR and SAR for the Waterfall lifecycle models (see Section 6.2). The inputs are the Size of software development, a constant, A, an exponent, E, and a number of values called effort multipliers (EM). The number of effort multipliers depends on the model. n PM = A × Size E × ∏ EM i i =1 Eq. 11 where A = 2.94 (for COCOMO II.2000) The exponent E is explained in detail in Section 3.1. The effort multipliers are explained in Section 3.2. The constant, A, approximates a productivity constant in PM/KSLOC for the case where E = 1.0. Productivity changes as E increases because of the non-linear effects on Size. The constant A is initially set when the model is calibrated to the project database reflecting a global productivity average. The COCOMO model should be calibrated to local data which then reflects the local productivity and improves the model's accuracy. Section 7 discusses how to calibrate the model to the local environment. The Size is KSLOC. This is derived from estimating the size of software modules that will constitute the application program. It can also be estimated from unadjusted function points (UFP), converted to SLOC, then divided by one thousand. Procedures for counting SLOC or UFP were explained in Section 2, including adjustments for reuse, requirements evolution, and automatically translated code. Cost drivers are used to capture characteristics of the software development that affect the effort to complete the project. A cost driver is a model factor that "drives" the cost (in this case Person-Months) estimated by the model. All COCOMO II cost drivers have qualitative rating levels that express the impact of the driver on development effort. These ratings can range from Extra Low to Extra High. Each rating level of every multiplicative cost driver has a value, called an effort multiplier (EM), associated with it. This scheme translates a cost driver's qualitative rating into a quantitative one for use in the model. The EM value assigned to a multiplicative cost driver's nominal rating is 1.00. If a multiplicative cost driver's rating level Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 15
  20. 20. causes more software development effort, then its corresponding EM is above 1.0. Conversely, if the rating level reduces the effort then the corresponding EM is less than 1.0. The rating of cost drivers is based on a strong rationale that they would independently explain a significant source of project effort or productivity variation. The difference between the Early Design and Post-Architecture models are the number of multiplicative cost drivers and the areas of influence they explain. There are seven multiplicative cost drivers for the Early Design model and seventeen multiplicative cost drivers for the Post-Architecture model. Each set is explained with its model later in the manual. It turns out that the most significant input to the COCOMO II model is Size. Size is treated as a special cost driver in that it has an exponential factor, E. This exponent is an aggregation of five scale factors. These are discussed next. What is not apparent in the model definition form given in Equation 11 is that there are some model drivers that apply only to the project as a whole. The scale factors in the exponent, E, are only used at the project level. Additionally, one of the multiplicative cost drivers that is in the product of effort multipliers, Required Development Schedule (SCED) is only used at the project level. The other multiplicative cost drivers, which are all represented in the product of effort multipliers, and size apply to individual project components. The model can be used to estimate effort for a project that has only one component or multiple components. For multicomponent projects the project-level cost drivers apply to all components, see Section 3.3. 3.1 Scale Factors The exponent E in Equation 11 is an aggregation of five scale factors (SF) that account for the relative economies or diseconomies of scale encountered for software projects of different sizes [Banker et al. 1994]. If E < 1.0, the project exhibits economies of scale. If the product’s size is doubled, the project effort is less than doubled. The project’s productivity increases as the product size is increased. Some project economies of scale can be achieved via project-specific tools (e.g., simulations, testbeds), but in general these are difficult to achieve. For small projects, fixed start-up costs such as tool tailoring and setup of standards and administrative reports are often a source of economies of scale. If E = 1.0, the economies and diseconomies of scale are in balance. This linear model is often used for cost estimation of small projects. If E > 1.0, the project exhibits diseconomies of scale. This is generally because of two main factors: growth of interpersonal communications overhead and growth of large-system integration overhead. Larger projects will have more personnel, and thus more interpersonal communications paths consuming overhead. Integrating a small product as part of a larger product requires not only the effort to develop the small product, but also the additional overhead effort to design, maintain, integrate, and test its interfaces with the remainder of the product. See [Banker et al. 1994] for a further discussion of software economies and diseconomies of scale. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 16
  21. 21. 16000 B=1.226 14000 Person Months 12000 10000 8000 6000 B=1.00 4000 2000 B=0.91 0 0 500 1000 KSLOC Figure 3. Diseconomies of Scale Effect on Effort Equation 12 defines the exponent, E, used in Equation 11. Table 10 provides the rating levels for the COCOMO II scale factors. The selection of scale factors is based on the rationale that they are a significant source of exponential variation on a project’s effort or productivity variation. Each scale factors has a range of rating levels, from Very Low to Extra High. Each rating level has a weight. The specific value of the weight is called a scale factor (SF). The project's scale factors, the selected scale factors ratings, are summed and used to determine a scale exponent, E, via Equation 12. The B term in the equation is a constant that can be calibrated [Boehm et al. 2000]. 5 E = B + 0.01 × ∑ SFj j=1 Eq. 12 where B = 0.91 (for COCOMO II.2000) For example, scale factors in COCOMO II with an Extra High rating are each assigned a scale factor weight of (0). Thus, a 100 KSLOC project with Extra High ratings for all scale factors will have ΣSFj = 0, E = 0.91, and a relative effort of 2.94(100)0.91 = 194 PM. For the COCOMO II.2000 calibration of scale factors in Table 10, a project with Very Low ratings for all scale factors will have ΣSFj=31.6, E = 1.226, and a relative effort of 2.94(100)1.226 = 832 PM. This represents a large variation, but the increase involved in a one-unit rating level change in one of the scale factors is only about 6%. For very large (1,000 KSLOC) products, the effect of the scale factors is much larger, as seen in Figure 3. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 17
  22. 22. Table 10. Scale Factor Values, SFj, for COCOMO II Models Scale Factors SFj: FLEX SFj: RESL SFj: Low Nominal thoroughly unpreceden ted largely unpreceden ted somewhat unpreceden ted 6.20 4.96 3.72 2.48 1.24 0.00 rigorous 5.07 occasional relaxation 4.05 some relaxation 3.04 general conformity 2.03 some conformity 1.01 general goals 0.00 little (20%) some (40%) often (60%) 5.65 4.24 mostly (90%) 1.41 full (100%) 7.07 generally (75%) 2.83 very difficult interactions PREC Very Low some difficult interactions basically cooperative interactions largely cooperative highly cooperative seamless interactions 5.48 4.38 3.29 2.19 1.10 0.00 TEAM SFj: PMAT SFj: High Very High generally familiar largely familiar The estimated Equivalent Process Maturity Level (EPML) or SW-CMM SW-CMM SW-CMM SW-CMM SW-CMM Level 2 Level 3 Level 4 Level 1 Level 1 Upper Lower 7.80 6.24 4.68 3.12 1.56 Extra High thoroughly familiar 0.00 SW-CMM Level 5 0.00 The two scale factors, Precedentedness and Flexibility largely capture the differences between the Organic, Semidetached, and Embedded modes of the original COCOMO model [Boehm 1981]. Table 11 and Table 12 reorganize [Boehm 1981; Table 6.3] to map its project features onto the Precedentedness and Development Flexibility scales. These tables can be used as a more in depth explanation for the PREC and FLEX rating scales given in Table 10. 3.1.1 Precedentedness (PREC) If a product is similar to several previously developed projects, then the precedentedness is high. Table 11. Precedentedness Rating Levels Feature Organizational understanding of product objectives Experience in working with related software systems Concurrent development of associated new hardware and operational procedures Very Low Nominal / High Extra High General Considerable Thorough Moderate Considerable Extensive Extensive Moderate Some Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 18
  23. 23. Table 11. Precedentedness Rating Levels Feature Very Low Extra High Considerable Need for innovative data processing architectures, algorithms Nominal / High Some Minimal 3.1.2 Development Flexibility (FLEX) Table 12. Development Flexibility Rating Levels Feature Very Low Nominal / High Extra High Full Considerable Basic Full Considerable Basic High Medium Low Need for software conformance with preestablished requirements Need for software conformance with external interface specifications Combination of inflexibilities above with premium on early completion The PREC and FLEX scale factors are largely intrinsic to a project and uncontrollable. The next three scale factors identify management controllables by which projects can reduce diseconomies of scale by reducing sources of project turbulence, entropy, and rework. 3.1.3 Architecture / Risk Resolution (RESL) This factor combines two of the scale factors in Ada COCOMO, “Design Thoroughness by Product Design Review (PDR)” and “Risk Elimination by PDR” [Boehm-Royce 1989; Figures 4 and 5]. Table 13 consolidates the Ada COCOMO ratings to form a more comprehensive definition for the COCOMO II RESL rating levels. It also relates the rating level to the MBASE/RUP Life Cycle Architecture (LCA) milestone as well as to the waterfall PDR milestone. The RESL rating is the subjective weighted average of the listed characteristics. Table 13. RESL Rating Levels Characteristic Risk Management Plan identifies all critical risk items, establishes milestones for resolving them by PDR or LCA. Schedule, budget, and internal milestones through PDR or LCA compatible with Risk Management Plan. Percent of development schedule devoted to establishing architecture, given general product objectives. Very Low Low Nominal High Very High Extra High None Little Some Generally Mostly Fully None Little Some Generally Mostly Fully 5 10 17 25 33 40 Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 19
  24. 24. Table 13. RESL Rating Levels Characteristic Percent of required top software architects available to project. Tool support available for resolving risk items, developing and verifying architectural specs. Level of uncertainty in key architecture drivers: mission, user interface, COTS, hardware, technology, performance. Number and criticality of risk items. Very Low Low Nominal High Very High Extra High 20 40 60 80 100 120 None Little Some Good Strong Full Extreme Significant Considerable Some Little Very Little > 10 Critical 5-10 Critical 2-4 Critical 1 Critical > 5NonCritical < 5 NonCritical 3.1.4 Team Cohesion (TEAM) The Team Cohesion scale factor accounts for the sources of project turbulence and entropy because of difficulties in synchronizing the project’s stakeholders: users, customers, developers, maintainers, interfacers, others. These difficulties may arise from differences in stakeholder objectives and cultures; difficulties in reconciling objectives; and stakeholders' lack of experience and familiarity in operating as a team. Table 14 provides a detailed definition for the overall TEAM rating levels. The final rating is the subjective weighted average of the listed characteristics. Table 14. TEAM Rating Components Very Low Characteristic Consistency of stakeholder objectives and cultures Ability, willingness of stakeholders to accommodate other stakeholders’ objectives Experience of stakeholders in operating as a team Stakeholder teambuilding to achieve shared vision and commitments Low Nominal Little Some Basic Little Some Basic None Little None Little High Very High Extra High Considerable Considerable Strong Full Strong Full Little Basic Extensive Little Basic Considerable Considerable Extensive 3.1.5 Process Maturity (PMAT) Overall Maturity Levels Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 20
  25. 25. The procedure for determining PMAT is organized around the Software Engineering Institute’s Capability Maturity Model (CMM). The time period for rating Process Maturity is the time the project starts. There are two ways of rating Process Maturity. The first captures the result of an organized evaluation based on the CMM, and is explained in Table 15. Table 15. PMAT Ratings for Estimated Process Maturity Level (EPML) PMAT Rating Maturity Level EPML Very Low Low Nominal High Very High Extra High CMM Level 1 (lower half) CMM Level 1 (upper half) CMM Level 2 CMM Level 3 CMM Level 4 CMM Level 5 0 1 2 3 4 5 Key Process Area Questionnaire The second is organized around the 18 Key Process Areas (KPAs) in the SEI Capability Maturity Model [Paulk et al. 1995]. The procedure for determining PMAT is to decide the percentage of compliance for each of the KPAs. If the project has undergone a recent CMM Assessment, then the percentage compliance for the overall KPA (based on KPA Key Practice compliance assessment data) is used. If an assessment has not been done, then the levels of compliance to the KPA’s goals are used (with the Likert scale in Table 16) to set the level of compliance. The goal-based level of compliance is determined by a judgment-based averaging across the goals for each Key Process Area. See [Paulk et al. 1995] for more information on the KPA definitions, goals and activities. Rarely if Ever Does Not Apply Requirements Management • System requirements allocated to software are controlled to establish a baseline for software engineering and management use. • Software plans, products, and activities are kept consistent with the system requirements allocated to software. Software Project Planning • Software estimates are documented for use in planning and tracking the software project. • Software project activities and commitments are planned and documented. • Affected groups and individuals agree to their commitments related to the software project. • • • • • • • • • • • • • Version 2.1 © 1995 – 2000 Center for Software Engineering, USC Don’t Know 5 4 3 2 Frequently Almost Always Key Process Areas (KPA) 7 Occasionally • 1 About Half 6 Table 16. KPA Rating Levels 21
  26. 26. Rarely if Ever Does Not Apply Software Project Tracking and Oversight • Actual results and performances are tracked against the software plans • Corrective actions are taken and managed to closure when actual results and performance deviate significantly from the software plans. • Changes to software commitments are agreed to by the affected groups and individuals. Software Subcontract Management • The prime contractor selects qualified software subcontractors. • The prime contractor and the subcontractor agree to their commitments to each other. • The prime contractor and the subcontractor maintain ongoing communications. • The prime contractor tracks the subcontractor’s actual results and performance against its commitments. Software Quality Assurance (SQA) • SQA activities are planned. • Adherence of software products and activities to the applicable standards, procedures, and requirements is verified objectively. • Affected groups and individuals are informed of software quality assurance activities and results. • Noncompliance issues that cannot be resolved within the software project are addressed by senior management. Software Configuration Management (SCM) • SCM activites are planned. • Selected workproducts are identified, controlled, and available. • Changes to identified work products are controlled. • Affected groups and individuals are informed of the status and content of software baselines. Organization Process Focus • Software process development and improvement activities are coordinated across the organization. • The strengths and weaknesses of the software processes used are identified relative to a process standard. • Organization-level process development and improvement activities are planned. Organization Process Definition • A standard software process for the organiation is developed and maintained. • Information related to the use of the organization’s standard software process by the software projects is collected, reviewed, and made available. • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Version 2.1 © 1995 – 2000 Center for Software Engineering, USC Don’t Know 5 4 3 2 Frequently Almost Always Key Process Areas (KPA) 7 Occasionally • 1 About Half 6 Table 16. KPA Rating Levels 22
  27. 27. Rarely if Ever Does Not Apply Training Program • Training activities are planned. • Training for developing the skills and knowledge needed to perform software management and technical roles is provided. • Individuals in the software engineering group and software-related groups receive the training necessary to perform their roles. Integrated Software Management • The project’s defined software process is a tailored version of the organization’s standard software process. • The project is planned and managed according to the project’s defined software process. Software Product Engineering • The software engineering tasks are defined, integrated, and consistently performed to produce the software • Software work products are kept consistent with each other. Intergroup Coordination • The customer’s requirements are agreed to by all affected groups. • The commitments between the engineering groups are agreed to by the affected groups. • The engineering groups identify, track, and resolve intergroup issues. Peer Reviews • Peer review activities are planned. • Defects in the software work products are identified and removed. Quantitative Process Management • The quantitative process management activities are planned. • The process performance of the project’s defined software process is controlled quantitatively. • The process capability of the organization’s standard software process is known in quantitative terms. Software Quality Management • The project’s software quality management activities are planned. • Measurable goals of software product quality and their priorities are defined. • Actual progress toward achieving the quality goals for the software products is quantified and managed. Defect Prevention • Defect prevention activities are planned. • Common causes of defects are sought out and identified. • Common causes of defects are priortized and systematically eliminated. • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • Version 2.1 © 1995 – 2000 Center for Software Engineering, USC • Don’t Know 5 4 3 2 Frequently Almost Always Key Process Areas (KPA) 7 Occasionally • 1 About Half 6 Table 16. KPA Rating Levels 23
  28. 28. Rarely if Ever Does Not Apply Technology Change Management • Incorporation of technology changes are planned. • New technologies are evaluated to determine their effect on quality and productivity. • Appropriate new technologies are transferred into normal practice across the organization. Process Change Management • Continuous process improvement is planned. • Participation in the organization’s software process improvement activities is organization wide. • The organization’s standard software process and the project’s defined software processes are improved continuously. • • • • • • • • • • • • • Don’t Know 5 4 3 2 Frequently Almost Always Key Process Areas (KPA) 7 Occasionally • 1 About Half 6 Table 16. KPA Rating Levels 1. Check Almost Always when the goals are consistently achieved and are well established in standard operating procedures (over 90% of the time). 2. Check Frequently when the goals are achieved relatively often, but sometimes are omitted under difficult circumstances (about 60 to 90% of the time). 3. Check About Half when the goals are achieved about half of the time (about 40 to 60% of the time). 4. Check Occasionally when the goals are sometimes achieved, but less often (about 10 to 40% of the time). 5. Check Rarely If Ever when the goals are rarely if ever achieved (less than 10% of the time). 6. Check Does Not Apply when you have the required knowledge about your project or organization and the KPA, but you feel the KPA does not apply to your circumstances. 7. Check Don’t Know when you are uncertain about how to respond for the KPA. An equivalent process maturity level (EPML) is computed as five times the average compliance level of all n rated KPAs for a single project (Does Not Apply and Don’t Know are not counted which sometimes makes n less than 18). After each KPA is rated, the rating level is weighted (100% for Almost Always, 75% for Frequently, 50% for About Half, 25% for Occasionally, 1% for Rarely if Ever). The EPML is calculated as in Equation 2-13.  n KPA% i  1 EPML = 5 ×  ∑ ×  i =1 100  n Eq. 13 An EPML of 0 corresponds with a PMAT rating level of Very Low in the rating scales of Table 10 and Table 15. The COCOMO II project is tracking the progress of the recent CMM Integration (CMMI) activity to determine likely future revisions in the definition of PMAT. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 24
  29. 29. 3.2 Effort Multipliers 3.2.1 Post-Architecture Cost Drivers This model is the most detailed. It is intended to be used when a software life-cycle architecture has been developed. This model is used in the development and maintenance of software products in the Application Generators, System Integration, or Infrastructure sectors [Boehm et al. 2000]. The seventeen Post-Architecture effort multipliers (EM) are used in the COCOMO II model to adjust the nominal effort, Person-Months, to reflect the software product under development, see Equation 11. Each multiplicative cost driver is defined below by a set of rating levels and a corresponding set of effort multipliers. The Nominal level always has an effort multiplier of 1.00, which does not change the estimated effort. Off-nominal ratings generally do change the estimated effort. For example, a high rating of Required Software Reliability (RELY) will add 10% to the estimated effort, as determined by the COCOMO II.2000 data calibration. A Very High RELY rating will add 26%. It is possible to assign intermediate rating levels and corresponding effort multipliers for your project. For example, the USC COCOMO II software tool supports rating cost drivers between the rating levels in quarter increments, e.g. Low+0.25, Nominal+0.50, High+0.75, etc. Whenever an assessment of a cost driver is halfway between quarter increments always round to the Nominal rating, e.g. if a cost driver rating falls halfway between Low+0.5 and Low+0.75, then select Low+0.75; or if a rating falls halfway between High+0.25 and High+0.5, then select High+0.25. Normally, linear interpolation is used to determine intermediate multiplier values, but nonlinear interpolation is more accurate for the high end of the TIME and STOR cost drivers and the low end of SCED. The COCOMO II model can be used to estimate effort and schedule for the whole project or for a project that consists of multiple modules. The size and cost driver ratings can be different for each module, with the exception of the Required Development Schedule (SCED) cost driver and the scale factors. The unique handling of SCED is discussed in Section 3.2.1.4 and in 4. 3.2.1.1 Product Factors Product factors account for variation in the effort required to develop software caused by characteristics of the product under development. A product that is complex, has high reliability requirements, or works with a large testing database will require more effort to complete. There are five product factors, and complexity has the strongest influence on estimated effort. Required Software Reliability (RELY) This is the measure of the extent to which the software must perform its intended function over a period of time. If the effect of a software failure is only slight inconvenience then RELY is very low. If a failure would risk human life then RELY is very high. Table 17 provides the COCOMOII.2000 rating scheme for RELY. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 25
  30. 30. Table 17. RELY Cost Driver RELY Descriptors: Rating Levels Effort Multipliers slight inconvenience Very Low 0.82 low, easily recoverable losses Low 0.92 moderate, easily recoverable losses Nominal 1.00 high financial loss risk to human life High 1.10 Very High 1.26 Extra High n/a This cost driver can be influenced by the requirement to develop software for reusability, see the description for RUSE. Data Base Size (DATA) This cost driver attempts to capture the effect large test data requirements have on product development. The rating is determined by calculating D/P, the ratio of bytes in the testing database to SLOC in the program. The reason the size of the database is important to consider is because of the effort required to generate the test data that will be used to exercise the program. In other words, DATA is capturing the effort needed to assemble and maintain the data required to complete test of the program through IOC, see Table 18. Table 18. DATA Cost Driver Testing DB 10 ≤ D/P < 100 ≤ D/P < D/P ≥ 1000 bytes/Pgm 100 1000 SLOC < 10 Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers n/a 0.90 1.00 1.14 1.28 n/a * DATA is rated as Low if D/P is less than 10 and it is very high if it is greater than 1000. P is measured in equivalent source lines of code (SLOC), which may involve function point or reuse conversions. DATA* Descriptors Product Complexity (CPLX) Complexity is divided into five areas: control operations, computational operations, device-dependent operations, data management operations, and user interface management operations. Using Table 19, select the area or combination of areas that characterize the product or the component of the product you are rating. The complexity rating is the subjective weighted average of the selected area ratings. Table 20 provides the COCOMO II.2000 effort multipliers for CPLX. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 26
  31. 31. Table 19. Component Complexity Ratings Levels Devicedependent Operations Data Management Operations Evaluation of simple expressions: e.g., A=B+C*(DE) Simple read, write statements with simple formats. Simple arrays in main memory. Simple COTSDB queries, updates. Simple input forms, report generators. Evaluation of moderate-level expressions: e.g., D=SQRT(B**24.*A*C) No cognizance needed of particular processor or I/O device characteristics. I/O done at GET/PUT level. Use of simple graphic user interface (GUI) builders. Use of standard math and statistical routines. Basic matrix/vector operations. I/O processing includes device selection, status checking and error processing. Single file subsetting with no data structure changes, no edits, no intermediate files. Moderately complex COTSDB queries, updates. Multi-file input and single file output. Simple structural changes, simple edits. Complex COTS-DB queries, updates. Control Operations Very Low Low Nominal Computational Operations Straight-line code with a few non-nested structured programming operators: DOs, CASEs, IFTHEN-ELSEs. Simple module composition via procedure calls or simple scripts. Straightforward nesting of structured programming operators. Mostly simple predicates Mostly simple nesting. Some intermodule control. Decision tables. Simple callbacks or message passing, including middlewaresupported distributed processing Version 2.1 © 1995 – 2000 Center for Software Engineering, USC User Interface Management Operations Simple use of widget set. 27
  32. 32. Table 19. Component Complexity Ratings Levels Data Management Operations User Interface Management Operations Operations at physical I/O level (physical storage address translations; seeks, reads, etc.). Optimized I/O overlap. Simple triggers activated by data stream contents. Complex data restructuring. Widget set development and extension. Simple voice I/O, multimedia. Difficult but structured numerical analysis: nearsingular matrix equations, partial differential equations. Simple parallelization. Routines for interrupt diagnosis, servicing, masking. Communication line handling. Performanceintensive embedded systems. Distributed database coordination. Complex triggers. Search optimization. Moderately complex 2D/3D, dynamic graphics, multimedia. Difficult and unstructured numerical analysis: highly accurate analysis of noisy, stochastic data. Complex parallelization. Device timingdependent coding, microprogrammed operations. Performancecritical embedded systems. Highly coupled, dynamic relational and object structures. Natural language data management. Complex multimedia, virtual reality, natural language interface. Control Operations High Very High Extra High Computational Operations Highly nested structured programming operators with many compound predicates. Queue and stack control. Homogeneous, distributed processing. Single processor soft real-time control. Reentrant and recursive coding. Fixedpriority interrupt handling. Task synchronization, complex callbacks, heterogeneous distributed processing. Singleprocessor hard real-time control. Multiple resource scheduling with dynamically changing priorities. Microcode-level control. Distributed hard real-time control. Basic numerical analysis: multivariate interpolation, ordinary differential equations. Basic truncation, round-off concerns. Devicedependent Operations Table 20. CPLX Cost Driver Rating Levels Effort Multipliers Very Low 0.73 Low 0.87 Nominal 1.00 Version 2.1 © 1995 – 2000 Center for Software Engineering, USC High 1.17 Very High 1.34 Extra High 1.74 28
  33. 33. Developed for Reusability (RUSE) This cost driver accounts for the additional effort needed to construct components intended for reuse on current or future projects. This effort is consumed with creating more generic design of software, more elaborate documentation, and more extensive testing to ensure components are ready for use in other applications. “Across project” could apply to reuse across the modules in a single financial applications project. “Across program” could apply to reuse across multiple financial applications projects for a single organization. “Across product line” could apply if the reuse is extended across multiple organizations. “Across multiple product lines” could apply to reuse across financial, sales, and marketing product lines, see Table 21. Development for reusability imposes constraints on the project's RELY and DOCU ratings. The RELY rating should be at most one level below the RUSE rating. The DOCU rating should be at least Nominal for Nominal and High RUSE ratings, and at least High for Very High and Extra High RUSE ratings. Table 21. RUSE Cost Driver RUSE Descriptors: Rating Levels Effort Multipliers none Very Low n/a across project across program across product line Low 0.95 Nominal 1.00 High 1.07 Very High 1.15 across multiple product lines Extra High 1.24 Documentation Match to Life-Cycle Needs (DOCU) Several software cost models have a cost driver for the level of required documentation. In COCOMO II, the rating scale for the DOCU cost driver is evaluated in terms of the suitability of the project’s documentation to its life-cycle needs. The rating scale goes from Very Low (many life-cycle needs uncovered) to Very High (very excessive for life-cycle needs), see Table 22. Attempting to save costs via Very Low or Low documentation levels will generally incur extra costs during the maintenance portion of the life-cycle. Poor or missing documentation will increase the Software Understanding (SU) increment discussed in Section 2.4.2. Table 22. DOCU Cost Driver DOCU Descriptors: Rating Levels Effort Multipliers Many lifecycle needs uncovered Some lifecycle needs uncovered. Right-sized to life-cycle needs Excessive for life-cycle needs Very Low 0.81 Low 0.91 Nominal 1.00 High 1.11 Very excessive for life-cycle needs Very High 1.23 Extra High n/a This cost driver can be influenced by the developed for reusability cost factor, see the description for RUSE. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 29
  34. 34. 3.2.1.2 Platform Factors The platform refers to the target-machine complex of hardware and infrastructure software (previously called the virtual machine). The factors have been revised to reflect this as described in this section. Some additional platform factors were considered, such as distribution, parallelism, embeddedness, and real-time operations. These considerations have been accommodated by the expansion of the Component Complexity rating levels in Table 19. Execution Time Constraint (TIME) This is a measure of the execution time constraint imposed upon a software system. The rating is expressed in terms of the percentage of available execution time expected to be used by the system or subsystem consuming the execution time resource. The rating ranges from nominal, less than 50% of the execution time resource used, to extra high, 95% of the execution time resource is consumed, see Table 23. Table 23. TIME Cost Driver TIME Descriptors: Rating Levels Effort Multipliers Very Low n/a Low n/a ≤ 50% use of available execution time Nominal 1.00 70% use of available execution time High 1.11 85% use of available execution time Very High 1.29 95% use of available execution time Extra High 1.63 Main Storage Constraint (STOR) This rating represents the degree of main storage constraint imposed on a software system or subsystem. Given the remarkable increase in available processor execution time and main storage, one can question whether these constraint variables are still relevant. However, many applications continue to expand to consume whatever resources are available---particularly with large and growing COTS products---making these cost drivers still relevant. The rating ranges from nominal (less than 50%), to extra high (95%) see Table 24. Table 24. STOR Cost Driver STOR Descriptors: Rating Levels Effort Multipliers Very Low n/a Low n/a ≤ 50% use of available storage Nominal 1.00 70% use of available storage High 1.05 85% use of available storage Very High 1.17 95% use of available storage Extra High 1.46 Platform Volatility (PVOL) “Platform” is used here to mean the complex of hardware and software (OS, DBMS, etc.) the software product calls on to perform its tasks. If the software to be developed is an operating system then the platform is the computer hardware. If a database management system is to be developed then the platform is the hardware and the operating system. If a network text browser is to be developed then the platform is the network, computer hardware, the operating system, Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 30
  35. 35. and the distributed information repositories. The platform includes any compilers or assemblers supporting the development of the software system. This rating ranges from low, where there is a major change every 12 months, to very high, where there is a major change every two weeks, see Table 25. Table 25. PVOL Cost Driver PVOL Descriptors: Rating Levels Effort Multipliers 3.2.1.3 Very Low n/a Major change every 12 mo.; Minor change every 1 mo. Low 0.87 Major: 6 mo.; Minor: 2 wk. Nominal 1.00 Major: 2 mo.;Minor: 1 wk. High 1.15 Major: 2 wk.;Minor: 2 days Very High 1.30 Extra High n/a Personnel Factors After product size, people factors have the strongest influence in determining the amount of effort required to develop a software product. The Personnel Factors are for rating the development team’s capability and experience – not the individual. These ratings are most likely to change during the course of a project reflecting the gaining of experience or the rotation of people onto and off the project. Analyst Capability (ACAP) Analysts are personnel who work on requirements, high-level design and detailed design. The major attributes that should be considered in this rating are analysis and design ability, efficiency and thoroughness, and the ability to communicate and cooperate. The rating should not consider the level of experience of the analyst; that is rated with APEX, LTEX, and PLEX. Analyst teams that fall in the fifteenth percentile are rated very low and those that fall in the ninetieth percentile are rated as very high, see Table 26. Table 26. ACAP Cost Driver ACAP Descriptors: Rating Levels Effort Multipliers 15th percentile Very Low 1.42 35th percentile Low 1.19 55th percentile Nominal 1.00 75th percentile High 0.85 90th percentile Very High 0.71 Extra High n/a Programmer Capability (PCAP) Current trends continue to emphasize the importance of highly capable analysts. However the increasing role of complex COTS packages, and the significant productivity leverage associated with programmers’ ability to deal with these COTS packages, indicates a trend toward higher importance of programmer capability as well. Evaluation should be based on the capability of the programmers as a team rather than as individuals. Major factors which should be considered in the rating are ability, efficiency and thoroughness, and the ability to communicate and cooperate. The experience of the programmer Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 31
  36. 36. should not be considered here; it is rated with APEX, LTEX, and PLEX. A very low rated programmer team is in the fifteenth percentile and a very high rated programmer team is in the ninetieth percentile, see Table 27. Table 27. PCAP Cost Driver PCAP Descriptors Rating Levels Effort Multipliers 15th percentile Very Low 1.34 35th percentile Low 1.15 55th percentile Nominal 1.00 75th percentile High 0.88 90th percentile Very High 0.76 Extra High n/a Personnel Continuity (PCON) The rating scale for PCON is in terms of the project’s annual personnel turnover: from 3%, very high continuity, to 48%, very low continuity, see Table 28. Table 28. PCON Cost Driver PCON Descriptors: Rating Levels Effort Multipliers 48% / year Very Low 1.29 24% / year Low 1.12 12% / year Nominal 1.00 6% / year High 0.90 3% / year Very High 0.81 Extra High Applications Experience (APEX) The rating for this cost driver (formerly labeled AEXP) is dependent on the level of applications experience of the project team developing the software system or subsystem. The ratings are defined in terms of the project team’s equivalent level of experience with this type of application. A very low rating is for application experience of less than 2 months. A very high rating is for experience of 6 years or more, see Table 29. Table 29. APEX Cost Driver APEX Descriptors: Rating Levels Effort Multipliers ≤ 2 months Very Low 1.22 6 months Low 1.10 1 year Nominal 1.00 3 years High 0.88 6 years Very High 0.81 Extra High n/a Platform Experience (PLEX) The Post-Architecture model broadens the productivity influence of platform experience, PLEX (formerly labeled PEXP), by recognizing the importance of understanding the use of more powerful platforms, including more graphic user interface, database, networking, and distributed middleware capabilities, see Table 30. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 32
  37. 37. Table 30. PLEX Cost Driver PLEX Descriptors: Rating Levels Effort Multipliers ≤ 2 months Very Low 1.19 6 months Low 1.09 1 year Nominal 1.00 3 years High 0.91 6 year Very High 0.85 Extra High n/a Language and Tool Experience (LTEX) This is a measure of the level of programming language and software tool experience of the project team developing the software system or subsystem. Software development includes the use of tools that perform requirements and design representation and analysis, configuration management, document extraction, library management, program style and formatting, consistency checking, planning and control, etc. In addition to experience in the project’s programming language, experience on the project’s supporting tool set also affects development effort. A low rating is given for experience of less than 2 months. A very high rating is given for experience of 6 or more years, see Table 31. Table 31. LTEX Cost Driver LTEX Descriptors: Rating Levels Effort Multipliers 3.2.1.4 ≤ 2 months Very Low 1.20 6 months Low 1.09 1 year Nominal 1.00 3 years High 0.91 6 year Very High 0.84 Extra High Project Factors Project factors account for influences on the estimated effort such as use of modern software tools, location of the development team, and compression of the project schedule. Use of Software Tools (TOOL) Software tools have improved significantly since the 1970s’ projects used to calibrate the 1981 version of COCOMO. The tool rating ranges from simple edit and code, very low, to integrated life-cycle management tools, very high. A Nominal TOOL rating in COCOMO 81 is equivalent to a Very Low TOOL rating in COCOMO II. An emerging extension of COCOMO II is in the process of elaborating the TOOL rating scale and breaking out the effects of TOOL capability, maturity, and integration, see Table 32. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 33
  38. 38. Table 32. TOOL Cost Driver TOOL Descriptors Rating Levels Effort Multipliers edit, code, debug Very Low 1.17 simple, frontend, backend CASE, little integration basic lifecycle tools, moderately integrated strong, mature lifecycle tools, moderately integrated Low 1.09 Nominal 1.00 High 0.90 strong, mature, proactive life-cycle tools, well integrated with processes, methods, reuse Very High 0.78 Extra High n/a Multisite Development (SITE) Given the increasing frequency of multisite developments, and indications that multisite development effects are significant, the SITE cost driver has been added in COCOMO II. Determining its cost driver rating involves the assessment and judgement-based averaging of two factors: site collocation (from fully collocated to international distribution) and communication support (from surface mail and some phone access to full interactive multimedia). For example, if a team is fully collocated, it doesn’t need interactive multimedia to achieve an Extra High rating. Narrowband e-mail would usually be sufficient, see Table 33. Table 33. SITE Cost Driver SITE: Collocation Descriptors: SITE: Communications Descriptors: Rating Levels Effort Multipliers Some phone, mail Multi-city and Multicompany Individual phone, FAX Multi-city or Multicompany Narrow band email Same city or metro. area Wideband electronic communicat ion. Very Low 1.22 Low 1.09 Nominal 1.00 High 0.93 International Same building or complex Wideband elect. comm., occasional video conf. Very High 0.86 Fully collocated Interactive multimedia Extra High 0.80 Required Development Schedule (SCED) This rating measures the schedule constraint imposed on the project team developing the software. The ratings are defined in terms of the percentage of schedule stretch-out or acceleration with respect to a nominal schedule for a project requiring a given amount of effort. Accelerated schedules tend to produce more effort in the earlier phases to eliminate risks and refine the architecture, more effort in the later phases to accomplish more testing and documentation in parallel. In Table 34, schedule compression of 75% is rated very low. A schedule stretch-out of 160% is rated very high. Stretch-outs do not add or decrease effort. Their savings because of smaller team size are generally balanced by the need to carry project administrative functions over a longer period of time. The nature of this balance is undergoing Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 34
  39. 39. further research in concert with our emerging CORADMO extension to address rapid application development (goto http://sunset.usc.edu/COCOMOII/suite.html for more information). SCED is the only cost driver that is used to describe the effect of schedule compression / expansion for the whole project. The scale factors are also used to describe the whole project. All of the other cost drivers are used to describe each module in a multiple module project. Using the COCOMO II Post-Architecture model for multiple module estimation is explained in Section 3.3. Table 34. SCED Cost Driver SCED Descriptors Rating Level Effort Multiplier 75% of nominal Very Low 1.43 85% of nominal Low 1.14 100% of nominal Nominal 1.00 130% of nominal High 1.00 160% of nominal Very High 1.00 Extra High n/a SCED is also handled differently in the COCOMO II estimation of time to develop, TDEV. This special use of SCED is explained in Section 4. 3.2.2 Early Design Model Drivers This model is used in the early stages of a software project when very little may be known about the size of the product to be developed, the nature of the target platform, the nature of the personnel to be involved in the project, or the detailed specifics of the process to be used. This model could be employed in either Application Generator, System Integration, or Infrastructure development sectors. For discussion of these marketplace sectors see [Boehm et al. 2000]. The Early Design model uses KSLOC or unadjusted function points (UFP) for size. UFPs are converted to the equivalent SLOC and then to KSLOC as discussed in Section 2.3. The application of exponential scale factors is the same for Early Design and the PostArchitecture models and was described in Section 3.1. In the Early Design model a reduced set of multiplicative cost drivers is used as shown in Table 35. The Early Design cost drivers are obtained by combining the Post-Architecture model cost drivers. Whenever an assessment of a cost driver is halfway between the rating levels always round to the Nominal rating, e.g. if a cost driver rating is halfway between Very Low and Low, then select Low. The effort equation is the same as given in Equation 11 except that the number of effort multipliers is reduced to 7 (n = 7). Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 35
  40. 40. Table 35. Early Design and Post-Architecture Effort Multipliers Early Design Cost Driver PERS RCPX RUSE PDIF PREX FCIL SCED Counterpart Combined Post-Architecture Cost Drivers ACAP, PCAP, PCON RELY, DATA, CPLX, DOCU RUSE TIME, STOR, PVOL APEX, PLEX, LTEX TOOL, SITE SCED Overall Approach The following approach is used for mapping the full set of Post-Architecture cost drivers and rating scales onto their Early Design model counterparts. It involves the use and combination of numerical equivalents of the rating levels. Specifically, a Very Low PostArchitecture cost driver rating corresponds to a numerical rating of 1, Low is 2, Nominal is 3, High is 4, Very High is 5, and Extra High is 6. For the combined Early Design cost drivers, the numerical values of the contributing Post-Architecture cost drivers are summed, and the resulting totals are allocated to an expanded Early Design model rating scale going from Extra Low to Extra High. The Early Design model rating scales always have a Nominal total equal to the sum of the Nominal ratings of its contributing Post-Architecture elements. An example is given below for the PERS cost driver. Personnel Capability (PERS) and Mapping Example An example will illustrate this approach. The Early Design PERS cost driver combines the Post-Architecture cost drivers Analyst capability (ACAP), Programmer capability (PCAP), and Personnel continuity (PCON), see Table 36. Each of these has a rating scale from Very Low (=1) to Very High (=5). Adding up their numerical ratings produces values ranging from 3 to 15. These are laid out on a scale, and the Early Design PERS rating levels assigned to them, as shown below. The associated effort multipliers are derived from the ACAP, PCAP, and PCON effort multipliers by averaging the products of each combination of effort multipliers associated with the given Early Design rating level. The effort multipliers for PERS, like the other Early Design model cost drivers, are derived from those of the Post-Architecture model by averaging the products of the constituent Post-Architecture multipliers (in this case ACAP, PCAP, PCON) for each combination of cost driver ratings corresponding with the Early Design rating level. For PERS = Extra High, this would involve four combinations: ACAP, PCAP, and PCON all Very High, or only one High and the other two Very High. Table 36. PERS Cost Driver PERS Descriptors: • Sum of ACAP, PCAP, PCON Ratings • Combined ACAP and PCAP Percentile 3, 4 5, 6 7, 8 9 20% 35% 45% 55% Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 10, 11 65% 12, 13 14, 15 75% 85% 36
  41. 41. Table 36. PERS Cost Driver PERS Descriptors: • Annual Personnel Turnover Rating Levels Effort Multipliers 45% Extra Low 2.12 30% Very Low 1.62 20% 12% 9% Low 1.26 Nominal 1.00 High 0.83 6% Very High 0.63 4% Extra High 0.50 The Nominal PERS rating of 9 corresponds to the sum (3 + 3 + 3) of the Nominal ratings for ACAP, PCAP, and PCON, and its corresponding effort multiplier is 1.0. Note, however that the Nominal PERS rating of 9 can result from a number of other combinations, e.g. 1 + 3 + 5 = 9 for ACAP = Very Low, PCAP = Nominal, and PCON = Very High. The rating scales and effort multipliers for PCAP and the other Early Design cost drivers maintain consistent relationships with their Post-Architecture counterparts. For example, the PERS Extra Low rating levels (20% combined ACAP and PCAP percentile; 45% personnel turnover) represent averages of the ACAP, PCAP, and PCON rating levels adding up to 3 or 4. Maintaining these consistency relationships between the Early Design and PostArchitecture rating levels ensures consistency of Early Design and Post-Architecture cost estimates. It also enables the rating scales for the individual Post-Architecture cost drivers, Table 35, to be used as detailed backups for the top-level Early Design rating scales given above. Product Reliability and Complexity (RCPX) This Early Design cost driver combines the four Post-Architecture cost drivers Required software reliability (RELY), Database size (DATA), Product complexity (CPLX), and Documentation match to life-cycle needs (DOCU). Unlike the PERS components, the RCPX components have rating scales with differing width. RELY and DOCU range from Very Low to Very High; DATA ranges from Low to Very High, and CPLX ranges from Very Low to Extra High. The numerical sum of their ratings thus ranges from 5 (VL, L, VL, VL) to 21 (VH, VH, EH, VH). Table 36 assigns RCPX ratings across this range, and associates appropriate rating scales to each of the RCPX ratings from Extra Low to Extra High. As with PERS, the PostArchitecture RELY, DATA CPLX, and DOCU rating scales discussed in Section 3.2.1.1 provide detailed backup for interpreting the Early Design RCPX rating levels. Table 37. RCPX Cost Driver RCPX Descriptors: • Sum of RELY, DATA, CPLX, DOCU Ratings • Emphasis on reliability, documentation • Product complexity • Database size 5, 6 7, 8 9 - 11 12 13 - 15 16 - 18 19 - 21 Very Little Very simple Small Little Some Basic Strong Extreme Simple Some Moderate Complex Small Small Moderate Large Very Strong Very complex Very Large Version 2.1 © 1995 – 2000 Center for Software Engineering, USC Extremely complex Very Large 37
  42. 42. Table 37. RCPX Cost Driver RCPX Descriptors: Rating Levels Extra Low 0.49 Effort Multipliers Very Low 0.60 Low 0.83 Nominal 1.00 Very High 1.91 High 1.33 Extra High 2.72 Developed for Reusability (RUSE) This Early Design model cost driver is the same as its Post-Architecture counterpart, which is covered in Section 3.2.1 Platform Difficulty (PDIF) This Early Design cost driver combines the three Post-Architecture cost drivers Execution time constraint (TIME), Main storage constraint (STOR), and Platform volatility (PVOL). TIME and STOR range from Nominal to Extra High; PVOL ranges from Low to Very High. The numerical sum of their ratings thus ranges from 8 (N, N, L) to 17 (EH, EH, VH). Table 38 assigns PDIF ratings across this range, and associates the appropriate rating scales to each of the PDIF rating levels. The Post-Architecture rating scales in Tables 23, 24, 25 provide additional backup definition for the PDIF ratings levels. Table 38. PDIF Cost Driver PDIF Descriptors: • Sum of TIME, STOR, and PVOL ratings • Time and storage constraint • Platform volatility 8 9 10 - 12 13 - 15 16, 17 ≤ 50% Very stable ≤ 50% Stable 80% Volatile Low 0.87 Nominal 1.00 65% Somewhat volatile High 1.29 90% Highly volatile Extra High 2.61 Rating Levels Effort Multipliers Very High 1.81 Personnel Experience (PREX) This Early Design cost driver combines the three Post-Architecture cost drivers Application experience (APEX), Language and tool experience (LTEX), and Platform experience (PLEX). Each of these range from Very Low to Very High; as with PERS, the numerical sum of their ratings ranges from 3 to 15. Table 39 assigns PREX ratings across this range, and associates appropriate effort multipliers and rating scales to each of the rating levels. Table 39. PREX Cost Driver PREX Descriptors: • Sum of APEX, PLEX, and LTEX ratings • Applications, Platform, Language and Tool Experience 3, 4 5, 6 7, 8 9 10, 11 12, 13 14, 15 ≤ 3 mo. 5 months 9 months 1 year 2 years 4 years 6 years Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 38
  43. 43. Table 39. PREX Cost Driver PREX Descriptors: Rating Levels Effort Multipliers Extra Low 1.59 Very Low 1.33 Low 1.22 Nominal 1.00 High 0.87 Very High 0.74 Extra High 0.62 Facilities (FCIL) This Early Design cost driver combines two Post-Architecture cost drivers: Use of software tools (TOOL) and Multisite development (SITE). TOOL ranges from Very Low to Very High; SITE ranges from Very Low to Extra High. Thus, the numerical sum of their ratings ranges from 2 (VL, VL) to 11 (VH, EH). Table 40 assigns FCIL ratings across this range, and associates appropriate rating scales to each of the FCIL rating levels. The individual Post-Architecture TOOL and SITE rating scales in Section 3.2.1 again provide additional backup definition for the FCIL rating levels. Table 40. FCIL Cost Driver FCIL Descriptors: • Sum of TOOL and SITE ratings • TOOL support • Multisite conditions Rating Levels Effort Multipliers 2 3 Minimal Some Weak support of complex multisite developme nt Extra Low 1.43 Some support of complex M/S devel. Very Low 1.30 4, 5 6 7, 8 9, 10 11 Simple CASE tool collection Some support of moderately complex M/S devel. Basic lifecycle tools Basic support of moderately complex M/S devel. Good; moderately integrated Strong support of moderately complex M/S devel. Strong; moderately integrated Strong support of simple M/S devel. Low 1.10 Nominal 1.0 High 0.87 Strong; well integrated Very strong support of collocated or simple M/S devel. Extra High 0.62 Very High 0.73 Required Development Schedule (SCED) This Early Design model cost driver is the same as its Post-Architecture counterpart, which is covered in Section 3.2.1. 3.3 Multiple Module Effort Estimation Usually software systems are comprised of multiple subsystems or components. It is possible to use COCOMO II to estimate effort and schedule for multiple components. The technique described here is for one level of sub-components. For multiple levels of subcomponents see [Boehm 1981]. Version 2.1 © 1995 – 2000 Center for Software Engineering, USC 39

×