2-3 single space pages

snowflakes997

COCOMO_II_Ch_2_Boehm_et_al_2000-2.pdf

Home >Business & Finance homework help >Accounting homework help >2-3 single space pages

COCOMO II/Chapter 2/Boehm et al. - 1 -

CHAPTER 2

COCOMO II: MODEL DEFINITION

2.1 Introduction

2.1.1 Overview

This chapter presents two models, the Post-Architecture and Early Design

models. Recall from Chapter 1 that these two models are used in the development

of Application Generator, System Integration, or Infrastructure developments.

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 in the exploration of architectural alternatives or incremental

COCOMO II/Chapter 2/Boehm et al. - 2 -

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 drivers. These will be presented

first. Then, the Post-Architecture model will be explained followed by the Early

Design model. The chapter ends with a discussion and example of using the

models for the eight decision analysis situations introduced at the beginning of

Chapter 1.

2.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. The amount of effort in person-months, PMNS, is

estimated by the formula:

∑

∏

×+=

××=

1j j

1i i

E NS

SF0.01BE where

EMSizeAPM Eqn. 2.1

The amount of calendar time, TDEVNS, it will take to develop the product

is estimated by the formula:

COCOMO II/Chapter 2/Boehm et al. - 3 -

( )

B)(E0.2D

SF0.2DF where

PMCTDEV 5

1j j

F NSNS

−×+=

×+=

×=

∑ =

Eqn. 2.2

The value of n is 16 for the Post-Architecture model effort multipliers,

EMi, and 6 for the Early Design model. 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 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

2.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 2.4.

COCOMO II/Chapter 2/Boehm et al. - 4 -

The specific milestones used as the endpoints in measuring development

effort and calendar time are defined in Appendix A, 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.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 B = 0.91 C = 3.67 D = 0.28

Details of the calibration are presented in Chapter 4, 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, TDEVNS = 3.67(586.6)(0.28+0.2×(1.15-0.91)) =

3.67(586.6)0.328 = 29.7 months. The average number of staff required for the

nominal-schedule development is PMNS / TDEVNS = 586.6 / 29.7 = 19.75 or 20

COCOMO II/Chapter 2/Boehm et al. - 5 -

people. In this example, an average 100 KSLOC software project will take about

30 months to complete with an average of 20 people.

2.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 sizing reused code.

COCOMO II/Chapter 2/Boehm et al. - 6 -

2.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, using 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 81, pp. 58-59]. The goal is to measure the

amount of intellectual work put into program development.

Defining a line of code is difficult due to 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

COCOMO II/Chapter 2/Boehm et al. - 7 -

definition checklists, report forms and supplemental forms to support

measurement definitions [Park 1992, Goethert et al. 1992].

Figure 2.1 shows the SLOC definition checklist as it is being applied to

support the development of the COCOMO II model. 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. The full checklist is provided at the end of this chapter in

Section 2.7.3.

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. 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,

COCOMO II/Chapter 2/Boehm et al. - 8 -

such as PERT sizing, expert consensus, analogy, top-down, and bottom-up, see

Section 21.4 and Chapter 22 of [Boehm, 1981].

Measurement unit: Physical source lines Logical source statements √ Statement type Definition √ Data Array Includes Excludes When a line or statement contains more than one type, classify it as the type with the highest precedence.

1 Executable Order of precedence 1 √ 2 Nonexecutable

3 Declarations 2 √ 4 Compiler directives 3 √ 5 Comments

6 On their own lines 4 √ 7 On lines with source code 5 √ 8 Banners and non-blank spacers 6 √ 9 Blank (empty) comments 7 √

10 Blank lines 8 √ 11 12 How produced Definition √ Data array Includes Excludes 1 Programmed √ 2 Generated with source code generators √ 3 Converted with automated translators √ 4 Copied or reused without change √ 5 Modified √ 6 Removed √ 7 8 Origin Definition √ Data array Includes Excludes 1 New work: no prior existence √ 2 Prior work: taken or adapted from

3 A previous version, build, or release √ 4 Commercial, off-the-shelf software (COTS), other than libraries √ 5 Government furnished software (GFS), other than reuse libraries √ 6 Another product √ 7 A vendor-supplied language support library (unmodified) √ 8 A vendor-supplied operating system or utility (unmodified) √ 9 A local or modified language support library or operating system √ 10 Other commercial library √ 11 A reuse library (software designed for reuse) √ 12 Other software component or library √

COCOMO II/Chapter 2/Boehm et al. - 9 -

2.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 2.1.

COCOMO II/Chapter 2/Boehm et al. - 10 -

Table 2.1 User Function Types

Function Point Description

External Input (EI) Count each unique user data or user control input type that enters the external boundary of the software system being measured.

External Output (EO)

Count each unique user data or control output type that leaves the external boundary of the software system being measured.

Internal Logical File (ILF)

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.

External Interface Files (EIF)

Files passed or shared between software systems should be counted as external interface file types within each system.

External Inquiry (EQ)

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 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 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 5% limit on the effect of reuse is

inconsistent with COCOMO experience; thus COCOMO II uses Unadjusted

COCOMO II/Chapter 2/Boehm et al. - 11 -

Function Points for sizing, and applies its reuse factors, cost drivers, and scale

drivers 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 procedure 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-level function counts. 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

following scheme:

COCOMO II/Chapter 2/Boehm et al. - 12 -

Table 2.2 FP Counting Weights

For Internal Logical Files and External Interface Files

Data Elements Record Elements 1 - 19 20 - 50 51+

1 Low Low Avg. 2 - 5 Low Avg. High 6+ Avg. High High

For External Output and External Inquiry Data Elements

File Types 1 - 5 6 - 19 20+ 0 or 1 Low Low Avg. 2 - 3 Low Avg. High 4+ Avg. High High

For External Input Data Elements

File Types 1 - 4 5 - 15 16+ 0 or 1 Low Low Avg. 2 - 3 Low Avg. High 3+ 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):

Table 2.3 UFP Complexity Weights

Complexity-Weight

Function Type Low Average High Internal Logical Files 7 10 15 External Interfaces Files 5 7 10 External Inputs 3 4 6 External Outputs 4 5 7 External Inquiries 3 4 6

COCOMO II/Chapter 2/Boehm et al. - 13 -

4. Compute Unadjusted Function Points. Add all the weighted functions counts

to get one number, the Unadjusted Function Points.

2.2.3 Relating UFPs to SLOC

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 Post-Architecture models by using tables to convert

Unadjusted Function Points into equivalent SLOC. The current conversion ratios

shown in Table 2.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.

USR_1 through USR_5 are five extra slots provided by USC COCOMO

II.2000 to accommodate users' 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.

COCOMO II/Chapter 2/Boehm et al. - 14 -

Table 2.4 UFP to SLOC Conversion Ratios

Language SLOC / UFP Language SLOC / UFP

Access 38 Jovial 107 Ada 83 71 Lisp 64 Ada 95 49 Machine Code 640 AI Shell 49 Modula 2 80 APL 32 Pascal 91 Assembly - Basic 320 PERL 27 Assembly - Macro 213 PowerBuilder 16 Basic - ANSI 64 Prolog 64 Basic - Compiled 91 Query – Default 13 Basic - Visual 32 Report Generator 80 C 128 Second Generation Language 107 C++ 55 Simulation – Default 46 Cobol (ANSI 85) 91 Spreadsheet 6 Database – Default 40 Third Generation Language 80 Fifth Generation Language 4 Unix Shell Scripts 107 First Generation Language 320 USR_1 1 Forth 64 USR_2 1 Fortran 77 107 USR_3 1 Fortran 95 71 USR_4 1 Fourth Generation Language 20 USR_5 1 High Level Language 64 Visual Basic 5.0 29 HTML 3.0 15 Visual C++ 34 Java 53

2.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. Pre-existing code that is treated as a

black-box and plugged into the product is called reused code. Pre-existing code

that is treated as a white-box and is modified for use with the product is called

COCOMO II/Chapter 2/Boehm et al. - 15 -

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.2.4.1 Nonlinear Reuse Effects

Analysis in [Selby 1988] of reuse costs across nearly 3,000 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 2.2). 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.

COCOMO II/Chapter 2/Boehm et al. - 16 -

The figure 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 2.4.) It can be seen that small modifications in the reused product

generate disproportionately large costs. This is primarily due to two factors: the

cost of understanding the software to be modified, and the relative cost of

checking module interfaces.

[Parikh and Zvegintzov 1983] contain data indicating that 47% of the

effort in software maintenance involves understanding the software to be

COCOMO II/Chapter 2/Boehm et al. - 17 -

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 and 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 2.3.

( ) ⎟ ⎠ ⎞

⎜ ⎝ ⎛ −×+×=

2 1kkk-mkN Eqn. 2.3

Figure 2.3 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.

COCOMO II/Chapter 2/Boehm et al. - 18 -

For m = 10

0 2 4 6 8 10

Figure 2.3 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 and Denskat 1994], and software which 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.2.4.2 A Reuse Model

The COCOMO II treatment of software reuse uses a nonlinear estimation

model, Equation 2-4. This involves estimating the amount of software to be

COCOMO II/Chapter 2/Boehm et al. - 19 -

adapted and three degree-of-modification 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 used to estimate effort. These are explained next.

( ) ( ) ( )

AAMKSLOC Adapted KSLOC Equivalent

50AAFfor , 100

UNFM)](SUAAF[AA

50AAFfor , 100

UNFM))]SU0.02(AAF(1[AA

AAM

IM0.3CM0.3DM0.4AAF

⋅=

⎪ ⎪ ⎩

⎪⎪ ⎨

⎧

> ×++

≤ ××++

×+×+×=

Eqn. 2.4

The Software Understanding increment (SU) is obtained from Table 2.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 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.

COCOMO II/Chapter 2/Boehm et al. - 20 -

Table 2.5 Rating Scale for Software Understanding Increment SU

Very Low Low Nominal High Very High

Structure

Very low cohesion, high coupling, spaghetti code.

Moderately low cohesion, high coupling.

Reasonably well-structured; some weak areas.

High cohesion, low coupling.

Strong modularity, information hiding in data / control structures.

Application

Clarity

No match between program and application world-views.

Some correlation between program and application.

Moderate correlation between program and application.

Good correlation between program and application.

Clear match between program and application world-views.

Self- Descriptive-

ness

Obscure code; documentation missing, obscure or obsolete

Some code commentary and headers; some useful documentation.

Moderate level of code commentary, headers, documentation.

Good code commentary and headers; useful documentation; some weak areas.

Self- descriptive code; documentation up-to-date, well- organized, with design rationale.

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 2.6 provides the rating scale and values for the

assessment and assimilation increment. AA is a percentage.

COCOMO II/Chapter 2/Boehm et al. - 21 -

Table 2.6 Rating Scale for Assessment and Assimilation Increment (AA)

AA Increment Level of AA Effort

0 None 2 Basic module search and documentation 4 Some module Test and Evaluation (T&E), documentation 6 Considerable module T&E, documentation 8 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 in Table

2.7.

COCOMO II/Chapter 2/Boehm et al. - 22 -

Table 2.7 Rating Scale for Programmer Unfamiliarity (UNFM)

UNFM Increment Level of Unfamiliarity

0.0 Completely familiar 0.2 Mostly familiar 0.4 Somewhat familiar 0.6 Considerably familiar 0.8 Mostly unfamiliar 1.0 Completely unfamiliar

Equation 2.4 is used to determine an equivalent number of new 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).

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.)

COCOMO II/Chapter 2/Boehm et al. - 23 -

• 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 2.2. Under the worst case, it can

take twice the effort to modify a reused module than developing 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.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

COCOMO II/Chapter 2/Boehm et al. - 24 -

software developed from scratch. Adapted code is pre-existing code that has

some changes to it, while reused code has no changes to the pre-existing source

(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).

Since there is no source 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 can 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 2.8 shows the valid ranges of reuse factors with additional

notes for the different categories.

COCOMO II/Chapter 2/Boehm et al. - 25 -

Table 2.8 Adapted Software Parameter Constraints and Guidelines Code Category

Reuse Parameters DM CM IM AA SU UNFM

New - all original software

not applicable

Adapted - changes to pre- existing software

0% - 100% normally > 0%

0+% - 100% usually > DM and

must be > 0%

0% - 100+% IM usually

moderate and can be > 100%

0% – 8%

0% - 50%

0 - 1

Reused - unchanged existing software

0% - 100% rarely 0%, but could be very

small

0% – 8%

not applicable

COTS - off-the-shelf software (often requires new glue code as a wrapper around the COTS)

0% - 100%

0% – 8%

not applicable

2.2.5 Requirements Evolution and Volatility (REVL)

COCOMO II uses a factor called REVL, to adjust the effective size of the

product due to requirements evolution and volatility due to 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.

COCOMO II/Chapter 2/Boehm et al. - 26 -

The use of REVL for computing size in given in Equation 2.5.

DSize100 REVL1Size ⋅⎟

⎠ ⎞

⎜ ⎝ ⎛ += Eqn. 2.5

where

SizeD is the reuse-equivalent of the delivered software.

2.2.6 Automatically Translated Code

The COCOMO II reuse model needs additional refinement to estimate the

costs of software re-engineering and conversion. The major difference in re-

engineering 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 re-engineering case study [Ruhl

and Gunn 1991], 80% of the code (13,131 COBOL source statements) was re-

engineered by automatic translation, and the actual re-engineering effort, 35

person months, was more than a factor of 4 lower than the COCOMO estimate of

152 person months.

The COCOMO II re-engineering and conversion estimation approach

involves estimation of an additional factor, AT, the percentage of the code that is

COCOMO II/Chapter 2/Boehm et al. - 27 -

re-engineered by automatic translation. Based on an analysis of the project data

above, the productivity for automated translation is 2400 source statements /

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 2.6 shows how automated

translation affects the estimated effort, PMAuto.

( ) ATPROD

100 ATSLOC Adapted

PMAuto ×

= Eqn. 2.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 2.9 [Ruhl and Gunn 1991].

COCOMO II/Chapter 2/Boehm et al. - 28 -

Table 2.9 Variation in Percentage of Automated Re-engineering

Re-engineering Target AT (% automated translation)

Batch processing 96% Batch with SORT 90% Batch with DBMS 88%

Batch, SORT, DBMS 82% Interactive 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.

2.2.7 Sizing Software Maintenance

COCOMO II differs from COCOMO 81 in applying the scale drivers to

the size of the modified code rather that to the size of the product being modified.

Applying the scale drivers to a 10 million SLOC product produced overlarge

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.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

COCOMO II/Chapter 2/Boehm et al. - 29 -

changing over 50% of the existing software, and development of sizable (over

20%) interfacing systems requiring little rework of the existing system.

The maintenance size is normally obtained via Equation 2.7, when the

base code size is known and the percentage of change to the base code is known.

[ MAFMCFSize) Code (Base(Size)M ]××= Eqn. 2.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 2.8:

SizeCode Base Modified Size Added SizeMCF += Eqn. 2.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.

MAFModified) Size Added (Size(Size)M ×+= Eqn. 2.9

COCOMO II/Chapter 2/Boehm et al. - 30 -

The size can refer to thousands of source lines of code (KSLOC), Function

Points, or Object Points. When using Function Points or Object 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 2.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.2.4.2) to model the effects of well or poorly

structured/understandable software on maintenance effort.

⎟ ⎠ ⎞

⎜ ⎝ ⎛ ×+= UNFM 100 SU1MAF Eqn. 2.10

The use of (Size)M in determining maintenance effort, Equation 2.9, is

discussed in Section 2.5.

COCOMO II/Chapter 2/Boehm et al. - 31 -

2.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 2.1,

and is summarized in Equation 2.11. This model form is used for both the Early

Design and Post-Architecture cost estimation models. 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.

COCOMO II/Chapter 2/Boehm et al. - 32 -

II.2000) COCOMO(for 2.94A where

EM(Size)APM n

1i i

××= ∏ = Eqn. 2.11

The exponent E is explained in detail in Section 2.3.1. The effort

multipliers are explained in Section 2.3.2. The constant, A, approximates a

productivity constant in (Person Months) / (thousands of lines of source code) for

the case where E = 1.0. Productivity changes as E increases due to 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. Chapter 4 discusses how to calibrate the model.

The Size is in units of thousands of source lines of code (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.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

COCOMO II/Chapter 2/Boehm et al. - 33 -

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 expres

the impact of the driver on development effort. These ratings can range from

Extra Low to Extra High. Each rating level of each cost driver has a value, called

an effort multiplier (EM), associated with it. This scheme translates a cost dri

qualitative rating into a quantitative one for use in the model. The EM value

assigned to a cost driver's nominal rating is 1.00. If a cost driver's rating level

causes more software development effort, then its corresponding EM is above 1.0.

Conversel

ver's

y, if the rating level reduces the effort then the corresponding EM is less

than 1.0

uld

here are 7

Archite

This ex

The rating of cost drivers is based on a strong rationale that they wo

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 cost drivers and the areas of influence they explain. T

cost drivers for the Early Design model and 17 cost drivers for the Post-

cture model. Each set is explained with its model later in the chapter.

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

ponent is an aggregation of five scale drivers. These are discussed next.

What is not apparent in the model definition form given in Equation 2.11

is that there are some model drivers that apply only to the project as a whole. Th

COCOMO II/Chapter 2/Boehm et al. - 34 -

scale drivers in the exponent, E, are only used at the project level. Addition

one of the cost drivers that is in the product of effort multipliers, Required

Development Schedule (SCED) is only used at the project level. The other cos

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 eff

for a project that has only one component or multiple components. For multi-

component pro

ally,

ort

jects the project-level cost drivers apply to all components, see

ection 2.2.3.

.3.1 Scale Drivers

t is

standards

and adm

The exponent E in Equation 2.11 is an aggregation of five scale drivers

that account for the relative economies or diseconomies of scale encountered for

software projects of different sizes [Banker et al 1994a]. If E < 1.0, the project

exhibits economies of scale. If the product's size is doubled, the project effor

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. Fo

small projects, fixed start-up costs such as tool tailoring and setup of

inistrative reports are often a source of economies of scale.

COCOMO II/Chapter 2/Boehm et al. - 35 -

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

due to two main factors: growth of interpersonal communications overhead

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 no

the effort

and

t only

to develop the small product, but also the additional overhead effort to

design,

ee [Banker et al 1994a] for a further discussion of software economies

and diseconomies of scale.

maintain, integrate, and test its interfaces with the remainder of the

product.

COCOMO II/Chapter 2/Boehm et al. - 36 -

Figure 2.4 Diseconomies of Scale Effect on Effort

quation 2.12 defines the exponent, E, used in Equation 2.11. Table 2.10

provides the rating levels for the COCOMO II scale drivers. The selection of

scale drivers is based on the rationale that they

exponential variation on a project’s effort or productivity variation. Each scale

Very Low to Extra High. Each rating

level ha

t c

2000

6000

8000

12000

14000

KSLOC

P er

so n

M hs

4000

10000

16000

0 500 1000

on t

B=1.226

B=0.91

B=1.00

are a significant source of

driver has a range of rating levels, from

s a weight. The specific value of the weight is called a scale factor (SF).

The project's scale factors, the selected scale driver ratings, are summed and used

to determine a scale exponent, E, via equation 2.12. The B term in the equation is

a constant tha an be calibrated. Calibration is discussed in Chapter 4.

COCOMO II/Chapter 2/Boehm et al. - 37 -

II.2000) COCOMO(for 0.91B where

SF0.01BE 5

1j= Eqn. 2.12 j

×+= ∑

For example, scale drivers in COCOMO II with an Extra High rating are

ach assigned a scale factor weight of (0). Thus, a 100 KSLOC project with Extra

High ratings for all scale drivers will have ΣSFj = 0, E = 0.91, and a relative effort

of 2 94(1 0.91 94 Pe onths. F COM 0 c on of

scale factors in Table 2.10, a project with Very Low ratings for all scale drivers

will have ΣS , E = 1 a rela t of 1.226

Person Months. This represents a large varia but the increase invo in a

one-unit change in one of the factors is only about 6%. For very large (1,000

) p e eff ale uc s r

. 00) = 1 rson M or the CO O II.200 alibrati

Fj=31.6 .226, and tive effor 2.94(100) = 832

tion, lved

KSLOC roducts, th ect of the sc factors is m h larger, as een in Figu e

.4.

COCOMO II/Chapter 2/Boehm et al. - 38 -

Table 2.10 Scale Drivers for COCOMO II Models

Scale rivers Very Low Low Nominal High

Very High Extra High D

PREC

thoroughly unprecedented

largely unprecedented

somewhat unprecedented

generally familiar

largely familiar

thoroughly familiar

SFj: 6.20 4.96 3.72 2.48 1.24 0.00 FLEX rigorous occasional some general some general

goals relaxation relaxation conformity conformity

SF : 5.07 4.05 3.04 2.03 1.01 0.00 j RESL little (20%) some (40%) often (60%) generally

(75%) mostly (90%)

full (100%)

SFj: 7.07 5.65 4.24 2.83 1.41 0.00 very difficult some difficult basically

cooperative interactions

largely cooperative

highly cooperative

seamless interactions TEAM interactions interactions

SFj: 5.48 4.38 3.29 2.19 1.10 0.00

PMA SW-CMM Level

Lower SW-CMM Level

1 U SW-CMM Level

2 SW-CMM SW-CMM

Level 4 SW-CMM

T 1 pper Level 3 Level 5

SFj: 7.80 6.24 4.68 3.12 1.56 0.00 or the estimated Process M l (EMPL) aturity Leve

le drivers ess and Flexibility largely capture the

ifferences between the Organic, Semidetached, and Embedded modes of the

Table 2.11 and Table 2.12 reorganize

oehm 1981; Table 6.3] to map its project features onto the Precedentedness and

Development Flexibility scales. These table can be used as a more in depth

explanation for the PREC and FLEX rating scales given in Table 2.10.

2.3.1.1 Precedentedness (PREC)

The two sca , Precedentedn

original COCOMO model [Boehm, 1981].

COCOMO II/Chapter 2/Boehm et al. - 39 -

If a product is similar to several previously developed projects, then the

igh.

dness Rating Levels

eature Very Low Nominal / High Extra High

precedentedness is h

Table 2.11 Precedente

Organizational understanding of product objectives

General Considerable Thorough

Experience in working with related software systems

Moderate Considerable Extensive

Concurrent de associated ne opera

Some velopment of w hardware and

tional procedures

Extensive Moderate

Need processing architectures, algori

Minimal for innovative data

thms

Considerable Some

2.3.1.2 Development Flexibility (FLEX)

Table 2.12 Development Flexibility Rating Levels

Fe xtra High ature Very Low Nominal / High E

Need for software confo estab

Basic rmance with pre- lished requirements

Full Considerable

Need for software confo interface specifications

Full Considerable Basic rmance with external

Comb above with p compl

Low ination of inflexibilities remium on early

etion

High Medium

COCOMO II/Chapter 2/Boehm et al. - 40 -

The PREC and FLEX scale factors are largely intrinsic to a project and

uncontrollable. The next three factors identify management controllables by

hich projects can reduce diseconomies of scale by reducing sources of project

turbulence, entropy, and rework.

cture / Ris lution )

combines two of the scale drivers in Ada COCOMO, “Design

y Product Revi R)” a sk E by

oyce 1989; Figures 4 and 5]. Table 2.13 consolidates the

atings to fo a more c rehensive definition for the

SL rating levels. It also relates the rating level to the

ife Cycle A itecture ( ) milestone as well as to the wate

he RES g is th ective ed ave f the l

evels

2.3.1.3 Archite k Reso (RESL

This factor

Thoroughness b

PDR” [Boehm and R

Design ew (PD nd “Ri limination

Ada COCOMO r

COCOMO II RE

rm omp

MBASE/RUP L rch LCA rfall

PDR milestone. T

characteristics.

L ratin e subj weight rage o isted

Table 2.13 RESL Rating L

COCOMO II/Chapter 2/Boehm et al. - 41 -

Charac Low

Very High

Extra High

teristic Very Low Nominal High

Risk M identifi establis resolvi LCA.

Mostly Fully anagement Plan es all critical risk items, hes milestones for

ng them by PDR or

None Little Some Generally

Sched internal mil PDR o Risk M

ostly Fully ule, budget, and estones through

r LCA compatible with anagement Plan.

None Little Some Generally M

Percent of de schedu establishing architecture, given g objecti

40 velopment le devoted to

eneral product ves.

5 10 17 25 33

Percen softwa to project.

40 60 80 100 120 t of required top re architects available

Tool su rt available for resolving risk items, develo archite

None Little Some Good Strong Full ppo

ping and verifying ctural specs.

Level of uncertainty in key architecture drivers: mission, user interface, COTS hardware, tech perform

Extreme Significant Considera ble

Some Little Very Little

, nology,

ance. Numbe items.

> 10 Criti

5-10 Crit

2-4 Critical 1 Critical > 5Non- C

< 5 Non- al

r and criticality of risk cal ical ritical Critic

2.3.1.4 Team Cohesion (TEA

eam Cohesion scale driver accounts for the sources of project

es in synchronizing the project’s

, maintainers, interfacers, others. These

ficulties may arise from differences in stakeholder objectives and cultures;

; and stakeholders' lack of experience and

The T

turbulence and entropy due to difficulti

stakeholders: users, customers, developers

dif

difficulties in reconciling objectives

COCOMO II/Chapter 2/Boehm et al. - 42 -

familiarity in operating as a team. Table 2.14 provides a detailed definition for

the ove

Characteristic

Very Low

Low

Nominal

High

Very High

Extra High

rall TEAM rating levels. The final rating is the subjective weighted

average of the listed characteristics.

Table 2.14 TEAM Rating Components

Consistency of stakeholder obje

Little Some Basic Considera Strong Full ctives and cultures ble

A s

bili takeholders to

accommod stakeholders’ o

ble trong Full ty, willingness of Little Some Basic Considera S

ate other bjectives

Experience of stake s i operating as a te

ittle Basic sidera

Extensive h am

older n None Little L Con ble

Stakeholder te to achieve share ommitments

tle Little Basic sidera

Extensive ambuilding vision andd

None Lit Con ble

Overall Ma

2.3.1.5 Process Maturity (PMAT)

turity Levels

The procedure for determining PMAT is organized around the Software

Engineering Institute’s Capability Maturity Model (CMM). The time period f

rating Process Maturity is the time the project starts. There are two ways of rating

COCOMO II/Chapter 2/Boehm et al. - 43 -

Process Maturity. The first captures the result of an organized evaluation based

on the CMM.

Table 2.15 PMAT Ratings for Estimated Process Maturity Level (EPM

PMAT Rating Very Low - CM

Maturity Level EPML M Level 1 (lower half) 0

Low - CMM Level 1 (upper half) 1 Nominal - CMM Level 2 2

High - CMM Level 3 3 Very High - CMM Level 4 4 Extra High - CMM Level 5 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., 1993, 1993a]. 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

2.16) to set the level of compliance. The goal-based level of compliance is

determined by a judgement-based averaging across the goals for each Key

COCOMO II/Chapter 2/Boehm et al. - 44 -

Process Area. See [Paulk et al., 1995] for more information on the KPA

efinitions, goals and activities.

Table 2.16 KPA Ra

A lm

o ys

Fr eq

ue n

A bo

ut H

O cc

a 4

R ar

el y

if Ev

er 5

D oe

s N

o pl

D on

’t K

no w

ting Levels

Key Process Areas (KPA)

st A

lw a

tly

si on

al ly

t A p

Requirements Management

ne for software engineering and management use.

ocated to software.

� � � � � � � • System requirements allocated to software are controlled to

establish a baseli • Software plans, products, and activities are kept consistent with the

system requirements all

Software Project Planning • Software estimates are documented for use in planning and tracking

the software project.

d groups and individuals agree to their commitments related

• Software project activities and commitments are planned and documented.

• Affecte to the software project.

�

Software Project Tracking and Oversight tracked against the software

actual

re commitments are agreed to by the affected

�

• Actual results and performances are plans

• Corrective actions are taken and managed to closure when results and performance deviate significantly from the software plans.

• Changes to softwa groups and individuals.

�

Software Subcontract Management • The prime contractor selects qualified software subcontractors. • The prome contractor and the subcontractor agree to their

h other. r and the subcontractor maintain ongoing

communications. The prime contractor tracks the subcontractor’s actual results and performance against its commitments.

�

� commitments to eac • The prome contracto

•

�

COCOMO II/Chapter 2/Boehm et al. - 45 -

Table 2.16 (Cont'd)

Software Quality Assurance (SQA) • SQA activities are planned. • Adherence of software products and activities to the applicable

standards, procedures, and requirements is verified objectively. of• Affected groups and individuals are informed

ults. software quality

�

assurance activities and res • Noncompliance issues that cannot be resolved within the softwa

project are addressed by senior management.

Software Configuration Management (SCM) • SCM activites are planned. • Selected workproducts are ide •

ntified, 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 activitie 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.

� �

Training Program • Training activities are planned.

Training for developing the skills and knowledge needed to perfo• rm 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.

�

COCOMO II/Chapter 2/Boehm et al. - 46 -

Table 2.16 (Cont'd)

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.

�

COCOMO II/Chapter 2/Boehm et al. - 47 -

Table 2.16 (Cont'd)

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.

�

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.

�

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,

COCOMO II/Chapter 2/Boehm et al. - 48 -

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 1

100 KPA%

5EPML n

i ×⎟ ⎠

⎞ ⎜ ⎝

⎛ ×= ∑

Eqn. 2.13

An EPML of 0 corresponds with a PMAT rating level of Very Low in the

rating scales of Table 2.10 and Table 2.15.

The COCOMO II project is tracking the progress of the recent CMM

Integration (CMM-I) activity to determine likely future revisions in the definition

of PMAT.

2.3.2 Effort Multipliers

2.3.2.1 Post-Architecture Cost Drivers

This model is the most detailed and 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 discussed in Chapter 1.

COCOMO II/Chapter 2/Boehm et al. - 49 -

The 17 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 2.11. Each 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

COCOMO II/Chapter 2/Boehm et al. - 50 -

cost driver ratings can be different for each module, with the exception of the

Required Development Schedule (SCED) cost driver and the scale drivers. The

unique handling of SCED is discussed in Section 2.3.2.1.4 and in 2.4.

2.3.2.1.1 Product Factors

Product factors account for variation in the effort required to develop

software due to characteristics of the product under development. A product that

is complex, has high reliability requirements, or works with a large 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.

COCOMO II/Chapter 2/Boehm et al. - 51 -

Table 2.17 RELY Cost Driver

RELY Descriptors:

slight inconven- ience

low, easily recoverable losses

moderate, easily recoverable losses

high financial loss

risk to human life

Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers 0.82 0.92 1.00 1.10 1.26 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 measure attempts to capture the effect large data requirements have

on product development. The rating is determined by calculating D/P, the ratio of

bytes in the 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 the data required to complete test of the program

through IOC.

COCOMO II/Chapter 2/Boehm et al. - 52 -

Table 2.18 DATA Cost Driver

DATA* Descriptors

DB bytes/Pgm SLOC < 10

10 ≤ D/P < 100

100 ≤ D/P < 1000

D/P ≥ 1000

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.

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 2.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 2.20 provides the COCOMO II.2000 CPLX

effort multipliers.

COCOMO II/Chapter 2/Boehm et al. - 53 -

Table 2.19 Component Complexity Ratings Levels

Control Operations

Computational Operations

Device- dependent Operations

Data Management Operations

User Interface Management Operations

Very Low

Straight-line code with a few non-nested structured programming operators: DOs, CASEs, IF- THEN-ELSEs. Simple module composition via procedure calls or simple scripts.

Evaluation of simple expressions: e.g., A=B+C*(D- E)

Simple read, write statements with simple formats.

Simple arrays in main memory. Simple COTS- DB queries, updates.

Simple input forms, report generators.

Low

Straightforward nesting of structured programming operators. Mostly simple predicates

Evaluation of moderate-level expressions: e.g., D=SQRT(B**2- 4.*A*C)

No cognizance needed of particular processor or I/O device characteristics. I/O done at GET/PUT level.

Single file subsetting with no data structure changes, no edits, no intermediate files. Moderately complex COTS- DB queries, updates.

Use of simple graphic user interface (GUI) builders.

COCOMO II/Chapter 2/Boehm et al. - 54 -

Table 2.19 Component Complexity Ratings Levels

Control Operations

Computational Operations

Device- dependent Operations

Data Management Operations

User Interface Management Operations

Nominal

Mostly simple nesting. Some intermodule control. Decision tables. Simple callbacks or message passing, including middleware- supported distributed processing

Use of standard math and statistical routines. Basic matrix/vector operations.

I/O processing includes device selection, status checking and error processing.

Multi-file input and single file output. Simple structural changes, simple edits. Complex COTS-DB queries, updates.

Simple use of widget set.

Table 2.19 (Cont'd)

Control Operations

Computational Operations

Device- dependent Operations

Data Management Operations

User Interface Management Operations

High

Highly nested structured programming operators with many compound predicates. Queue and stack control. Homogeneous, distributed processing. Single processor soft real-time control.

Basic numerical analysis: multivariate interpolation, ordinary differential equations. Basic truncation, round-off concerns.

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.

COCOMO II/Chapter 2/Boehm et al. - 55 -

Table 2.19 Component Complexity Ratings Levels

Control Operations

Computational Operations

Device- dependent Operations

Data Management Operations

User Interface Management Operations

Very High

Reentrant and recursive coding. Fixed- priority interrupt handling. Task synchronization, complex callbacks, heterogeneous distributed processing. Single- processor hard real-time control.

Difficult but structured numerical analysis: near- singular matrix equations, partial differential equations. Simple parallelization.

Routines for interrupt diagnosis, servicing, masking. Communication line handling. Performance- intensive embedded systems.

Distributed database coordination. Complex triggers. Search optimization.

Moderately complex 2D/3D, dynamic graphics, multimedia.

Extra High

Multiple resource scheduling with dynamically changing priorities. Microcode-level control. Distributed hard real-time control.

Difficult and unstructured numerical analysis: highly accurate analysis of noisy, stochastic data. Complex parallelization.

Device timing- dependent coding, micro- programmed operations. Performance- critical embedded systems.

Highly coupled, dynamic relational and object structures. Natural language data management.

Complex multimedia, virtual reality, natural language interface.

Table 2.20 CPLX Cost Driver

Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers 0.73 0.87 1.00 1.17 1.34 1.74

COCOMO II/Chapter 2/Boehm et al. - 56 -

Developed for Reusability (RUSE)

This cost driver accounts for the additional effort needed to construct

components intended for reuse on the 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.

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.

COCOMO II/Chapter 2/Boehm et al. - 57 -

Table 2.21 RUSE Cost Driver

RUSE Descriptors:

none across project

across program

across product line

across multiple product

lines Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers n/a 0.95 1.00 1.07 1.15 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).

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.2.4.2.

Table 2.22 DOCU Cost Driver

DOCU Descriptors:

Many life cycle needs uncovered

Some life cycle needs uncovered.

Right-sized to life cycle needs

Excessive for life cycle needs

Very excessive for life cycle needs

Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers 0.81 0.91 1.00 1.11 1.23 n/a

COCOMO II/Chapter 2/Boehm et al. - 58 -

This cost driver can be influenced by the developed for reusability cost factor, see

the description for RUSE.

2.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 2.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.

COCOMO II/Chapter 2/Boehm et al. - 59 -

Table 2.23 TIME Cost Driver

TIME Descriptors:

≤ 50% use of available execution time

70% use of available execution time

85% use of available execution time

95% use of available execution time

Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers n/a n/a 1.00 1.11 1.29 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%).

Table 2.24 STOR Cost Driver

STOR Descriptors:

≤ 50% use of available storage

70% use of available storage

85% use of available storage

95% use of available storage

Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers n/a n/a 1.00 1.05 1.17 1.46

COCOMO II/Chapter 2/Boehm et al. - 60 -

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, 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.

Table 2.25 PVOL Cost Driver

PVOL Descriptors:

Major change every 12 mo.; Minor change every 1 mo.

Major: 6 mo.; Minor: 2 wk.

Major: 2 mo.;Minor: 1 wk.

Major: 2 wk.;Minor: 2 days

Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers n/a 0.87 1.00 1.15 1.30 n/a

2.3.2.1.3 Personnel Factors

COCOMO II/Chapter 2/Boehm et al. - 61 -

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 that 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 15th percentile are rated very low and those that fall in the

90th percentile are rated as very high.

Table 2.26 ACAP Cost Driver

ACAP Descriptors:

15th percentile

35th percentile

55th percentile

75th percentile

90th percentile

Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers 1.42 1.19 1.00 0.85 0.71 n/a

Programmer Capability (PCAP)

COCOMO II/Chapter 2/Boehm et al. - 62 -

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 should not be considered here; it is

rated with APEX, LTEX, and PLEX. A very low rated programmer team is in the

15th percentile and a very high rated programmer team is in the 90th percentile.

Table 2.27 PCAP Cost Driver

PCAP Descriptors

15th percentile

35th percentile

55th percentile

75th percentile

90th percentile

Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers 1.34 1.15 1.00 0.88 0.76 n/a

Personnel Continuity (PCON)

COCOMO II/Chapter 2/Boehm et al. - 63 -

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.

Table 2.28 PCON Cost Driver

PCON Descriptors: 48% / year 24% / year 12% / year 6% / year 3% / year Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers 1.29 1.12 1.00 0.90 0.81

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.

Table 2.29 APEX Cost Driver

APEX Descriptors: ≤ 2 months 6 months 1 year 3 years 6 years Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers 1.22 1.10 1.00 0.88 0.81 n/a

COCOMO II/Chapter 2/Boehm et al. - 64 -

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.

Table 2.30 LTEX Cost Driver

LTEX Descriptors: ≤ 2 months 6 months 1 year 3 years 6 year Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers 1.20 1.09 1.00 0.91 0.84

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

COCOMO II/Chapter 2/Boehm et al. - 65 -

graphic user interface, database, networking, and distributed middleware

capabilities.

Table 2.31 PLEX Cost Driver

PLEX Descriptors: ≤ 2 months 6 months 1 year 3 years 6 year Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers 1.19 1.09 1.00 0.91 0.85 n/a

2.3.2.1.4 Project Factors

Project factors account for influences on the estimated effort due to 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 1970’s 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

COCOMO II/Chapter 2/Boehm et al. - 66 -

elaborating the TOOL rating scale and breaking out the effects of TOOL

capability, maturity, and integration.

Table 2.32 TOOL Cost Driver

TOOL Descriptors

edit, code, debug

simple, frontend, backend CASE, little integration

basic life cycle tools, moderately integrated

strong, mature life cycle tools, moderately integrated

strong, mature, proactive life cycle tools, well integrated with processes, methods, reuse

Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers 1.17 1.09 1.00 0.90 0.78 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).

COCOMO II/Chapter 2/Boehm et al. - 67 -

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.

Table 2.33 SITE Cost Driver

SITE: Collocation Descriptors:

Inter- national

Multi-city and Multi- company

Multi-city or Multi- company

Same city or metro. area

Same building or complex

Fully collocated

SITE: Communications Descriptors:

Some phone, mail

Individual phone, FAX

Narrow band email

Wideband electronic communicat ion.

Wideband elect. comm., occasional video conf.

Interactive multimedia

Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers 1.22 1.09 1.00 0.93 0.86 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. A schedule compression of 75% is rated very low. A schedule stretch-

COCOMO II/Chapter 2/Boehm et al. - 68 -

out of 160% is rated very high. Stretch-outs do not add or decrease effort. Their

savings due to 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 further research in concert with our emerging CORADMO

extension to address rapid application development (see Chapter 5).

SCED is the only cost driver that is used to describe the effect of schedule

compression / expansion for the whole project. The scale drivers 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 2.3.3.

Table 2.34 SCED Cost Driver

SCED

Descriptors 75%

of nominal 85%

of nominal 100%

of nominal 130%

of nominal 160%

of nominal

Rating Level Very Low Low Nominal High Very High Extra High Effort Multiplier 1.43 1.14 1.00 1.00 1.00 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 2.4.

2.3.2.2 Early Design Model Drivers

COCOMO II/Chapter 2/Boehm et al. - 69 -

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 Chapter 1.

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.2.3. The application of project scale drivers is the same for

Early Design and the Post-Architecture models and was described in Section

2.3.1. In the Early Design model a reduced set of cost drivers is used as shown in

Table 2.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 2-9 except that the number of

effort multipliers is 7 (n = 7).

COCOMO II/Chapter 2/Boehm et al. - 70 -

Table 2.35 Early Design and Post-Architecture Effort Multipliers

Early Design Cost Driver Counterpart Combined Post-Architecture Cost Drivers

RCPX RELY, DATA, CPLX, DOCU RUSE RUSE PDIF TIME, STOR, PVOL PERS ACAP, PCAP, PCON PREX APEX, PLEX, LTEX FCIL TOOL, SITE

SCED SCED

Overall Approach: Personnel Capability (PERS) Example

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 Post-Architecture 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.

COCOMO II/Chapter 2/Boehm et al. - 71 -

Personnel Capability (PERS)

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). 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 and 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 (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.

COCOMO II/Chapter 2/Boehm et al. - 72 -

Table 2.36 PERS Cost Driver

PERS Descriptors: • Sum of ACAP, PCAP,

PCON Ratings 3, 4 5, 6 7, 8 9 10,

11 12, 13 14, 15

• Combined ACAP and PCAP Percentile

20% 35% 45% 55% 65% 75% 85%

• Annual Personnel Turnover 45% 30% 20% 12% 9% 6% 4% Rating Levels Extra

Low Very Low

Low

Nominal

High

Very High

Extra High

Effort Multipliers 2.12 1.62 1.26 1.00 0.83 0.63 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

Post-Architecture rating levels ensures consistency of Early Design and Post-

Architecture cost estimates. It also enables the rating scales for the individual

COCOMO II/Chapter 2/Boehm et al. - 73 -

Post-Architecture cost drivers, Table 2.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 2.37 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 Post-Architecture RELY, DATA CPLX, and DOCU

rating scales discussed in Section 2.3.2.1.1 provide detailed backup for

interpreting the Early Design RCPX rating levels.

COCOMO II/Chapter 2/Boehm et al. - 74 -

Table 2.37 RCPX Cost Driver

RCPX Descriptors: • Sum of RELY, DATA,

CPLX, DOCU Ratings 5, 6 7, 8 9 - 11 12 13 - 15 16 - 18 19 - 21

• Emphasis on reliability, documentation

Very Little

Little Some Basic Strong Very Strong

Extreme

• Product complexity Very simple

Simple Some Moderate Complex Very complex

Extremely complex

• Database size Small Small Small Moderate Large Very Large

Very Large

Rating Levels Extra Low

Very Low

Low

Nominal

High

Very High

Extra High

Effort Multipliers 0.49 0.60 0.83 1.00 1.33 1.91 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 2.3.2.1.2.

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).

COCOMO II/Chapter 2/Boehm et al. - 75 -

Table 2.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 2.23, 2.24, 2.25 provide additional backup definition for

the PDIF ratings levels.

Table 2.38 PDIF Cost Driver

PDIF Descriptors: • Sum of TIME, STOR, and

PVOL ratings 8 9 10 - 12 13 - 15 16, 17

• Time and storage constraint ≤ 50% ≤ 50% 65% 80% 90% • Platform volatility Very stable Stable Somewhat

volatile Volatile Highly

volatile Rating Levels Low Nominal High Very High Extra High Effort Multipliers 0.87 1.00 1.29 1.81 2.61

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 2.39 assigns PREX ratings across this range, and associates

appropriate effort multipliers and rating scales to each of the rating levels.

COCOMO II/Chapter 2/Boehm et al. - 76 -

Table 2.39 PREX Cost Driver

PREX Descriptors: • Sum of APEX, PLEX, and

LTEX ratings 3, 4 5, 6 7, 8 9 10, 11 12, 13 14, 15

• Applications, Platform, Language and Tool Experience

≤ 3 mo. 5 months

9 months

1 year 2 years

4 years 6 years

Rating Levels Extra Low

Very Low

Low

Nominal

High

Very High

Extra High

Effort Multipliers 1.59 1.33 1.22 1.00 0.87 0.74 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 2.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 2.3.2.1.4 again provide

additional backup definition for the FCIL rating levels.

COCOMO II/Chapter 2/Boehm et al. - 77 -

Table 2.40 FCIL Cost Driver

FCIL Descriptors:

• Sum of TOOL and SITE ratings

4, 5

7, 8

9, 10

• TOOL support

Minimal Some Simple CASE tool collection

Basic life cycle tools

Good; moderately integrated

Strong; moderately integrated

Strong; well integrated

• Multisite conditions

Weak support of complex multisite developme nt

Some support of complex M/S devel.

Some support of moderately complex M/S devel.

Basic support of moderately complex M/S devel.

Strong support of moderately complex M/S devel.

Strong support of simple M/S devel.

Very strong support of collocated or simple M/S devel.

Rating Levels

Extra Low

Very Low

Low

Nominal

High

Very High

Extra High

Effort Multipliers

1.43 1.30 1.10 1.0 0.87 0.73 0.62

Required Development Schedule (SCED)

This Early Design model cost driver is the same as its Post-Architecture

counterpart, which is covered in Section 2.3.2.1.4.

2.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

COCOMO II/Chapter 2/Boehm et al. - 78 -

multiple components. The technique described here is for one level of sub-

components. For multiple levels of sub-components see (Boehm 81).

The COCOMO II method for doing this does not use the sum of the

estimates for each component as this would ignore effort due to integration of the

components. The COCOMO II multiple module method has the following steps:

1. Sum the sizes for all of the components to yield an aggregate size.

∑ =

= n

1i i)Component(Total SizeSize

2. Apply the project-level factors to the aggregated size to derive the nominal

effort for the total project. Don’t forget that the SCED effort multiplier is

applied at the total project-level.

SCED)(SizeAPM ETotalalTotalNomin ××=

3. Apportion the total nominal effort to each component based on its

contribution to the aggregate size.

⎟⎟ ⎠

⎞ ⎜⎜ ⎝

⎛ ×=

Total

i)Component( Nominal TotalNominal i)Component( Size

Size PMPM

COCOMO II/Chapter 2/Boehm et al. - 79 -

4. For each component apply the component-level effort multipliers (excluding

SCED) to the effort apportioned to that component.

∑ =

×= 16

1j jNominal i)Component(i)Component( EMPMPM

5. Sum the effort estimations from all of the components to derive the

aggregate effort for the total project.

∑ =

= n

1i i)Component(Total PMPM

6. Using the total project effort, derive the schedule using Equation 2.14.

2.4 Schedule Estimation

The initial version of COCOMO II provides a simple schedule estimation

capability similar to those in COCOMO and Ada COCOMO. The initial baseline

schedule equation for the COCOMO II Early Design and Post-Architecture stages

is:

COCOMO II/Chapter 2/Boehm et al. - 80 -

0.91B 0.28,D 3.67,C where 100

SCED%])(PM[CTDEV B))(E0.2(DNS

===

××= −×+ Eqn. 2.14

In equation 2.14, C is a TDEV coefficient that can be calibrated, PMNS is

the estimated person-months excluding the SCED effort multiplier as defined in

Equation 2.1, D is a TDEV scaling base-exponent that can also be calibrated, E is

the effort scaling exponent derived as the sum of project scale drivers and B as the

calibrated scale driver base-exponent (discussed in Sections 2.1.2 and 2.3.1), and

SCED% is the compression / expansion percentage in the SCED effort multiplier

rating scale discussed in Section 2.3.2.1.4.

Time to Develop, TDEV, is the calendar time in months between the

estimation endpoints defined in Figure A.1 of Appendix A. For the waterfall

model, this goes from the determination of a product’s requirements baseline to

the completion of an acceptance activity certifying that the product satisfies its

requirements. For the MBASE/RUP model discussed in Chapter 1, it covers the

time span between LCO and IOC milestones.

As COCOMO II evolves, it will have a more extensive schedule

estimation model, reflecting the different classes of process models a project can

use. The effects of reusable and COTS software; the effects of applications

COCOMO II/Chapter 2/Boehm et al. - 81 -

composition capabilities; and the effects of alternative strategies such as Rapid

Application Development are discussed in Chapter 5.

2.5 Software Maintenance

Software maintenance is defined as the process of modifying existing

software while not changing its primary functions [Boehm, 1981]. The

assumption made by the COCOMO II model is that software maintenance cost

generally has the same cost driver attributes as software development costs.

Maintenance includes redesign and recoding of small portions of the original

product, redesign and development of interfaces, and minor modification of the

product structure. Maintenance can be classified as either updates or repairs.

Product repairs can be further segregated into corrective (failures in processing,

performance, or implementation), adaptive (changes in the processing or data

environment), or perfective maintenance (enhancing performance or

maintainability). Maintenance sizing is covered in Section 2.2.7.

There are special considerations for using COCOMO II in software

maintenance. Some of these are adapted from [Boehm, 1981].

COCOMO II/Chapter 2/Boehm et al. - 82 -

• The SCED cost driver (Required Development Schedule) is not used

in the estimation of effort for maintenance. This is because the

maintenance cycle is usually of a fixed duration.

• The RUSE cost driver (Required Reusablity) is not used in the

estimation of effort for maintenance. This is because the extra effort

required to maintain a component’s reusability is roughly balanced by

the reduced maintenance effort due to the component’s careful design,

documentation, and testing.

• The RELY cost driver (Required Software Reliabilty) has a different

set of effort multipliers for maintenance. For maintenance the RELY

cost driver depends on the required reliability under which the product

was developed. If the product was developed with low reliability it

will require more effort to fix latent faults. If the product was

developed with very high reliability, the effort required to maintain

that level of reliability will be above nominal. The table below shows

the effort multipliers for RELY:

COCOMO II/Chapter 2/Boehm et al. - 83 -

Table 2.41 RELY Maintenance Cost Driver

RELY Descriptors:

slight inconvenien ce

low, easily recoverable losses

moderate, easily recoverable losses

high financial loss

risk to human life

Rating Levels Very Low Low Nominal High Very High Extra High Effort Multipliers 1.23 1.10 1.00 0.99 1.07 n/a

• The scaling exponent, E, is applied to the number of changed

KSLOC (added and modified, not deleted) rather than the total

legacy system KSLOC. As discussed in Section 2.2.7, the

effective maintenance size (SIZE)m is adjusted by a

Maintenance Adjustment Factor (MAF) to account for legacy

system effects.

The maintenance effort estimation formula is the same as the COCOMO II

Post-Architecture development model (with the exclusion of SCED and RUSE):

∏ =

⋅⋅= 15

E MM EM)(SizeAPM i Eqn. 2.15

COCOMO II/Chapter 2/Boehm et al. - 84 -

The COCOMO II approach differs from the COCOMO 81 maintenance

effort estimation by letting you use any desired maintenance activity duration,

TM. The average maintenance staffing level, FSPM, can then be obtained via the

relationship:

FSPM = PMM / TM Eqn. 2.16

2.6 Using COCOMO II for Software Decisions

In Section 1.1, we presented a number of software decision situations for

which COCOMO II can provide help in reasoning about your options and

decisions. Now that we have described the COCOMO II framework and cost

driver values, we can use these to illustrate how you can use these for software

decision analyses, even without exercising the full model.

Our example organization is an auto-parts company named UST, Inc. It

has out-sourced or acquired commercial packages for many of its business

functions, but retains a software engineering staff of about 200 people to perform

corporate success-critical software functions.

2.6.1 Making Investment Decisions and Business-Case Analyses.

COCOMO II/Chapter 2/Boehm et al. - 85 -

UST is considering the development of a manufacturing control system

(MCS) to support just-in-time manufacturing in its primary factory. UST expects

that the reductions in inventory carrying costs (usually about 25% of the value of

the inventory per year) will justify the expenditure (mostly software) to develop

the MCS, but would like to do a return-on-investment (ROI) analysis to make

sure. The analysis will make conservative assumptions, both for simplicity and to

strengthen the conclusions.

Conservatively, UST estimates that the new system will reduce its current

average manufacturing inventory value of $80 M by 20%. The corresponding

savings in annual carrying costs (for investing control, property taxes, finances,

etc.) is ($80M)(20%)(25%) = $4M/year.

A similar simple, conservative COCOMO II software cost analysis

assumes that the MCS system will require 100 KSLOC of software, that all the

cost driver and scale driver ratings will be nominal, and that the burdened cost of

a UST software engineer is $8K per person-month. The nominal cost drivers are

all 1.0. The nominal scale factors in Table 2.10 lead to a scaling exponent E =

0.91+.01(3.72+3.04+4.24+3.29+4.68) = 1.10. The resulting estimated effort is E

= 2.94(100)1.10 = 466 person-months (PM). The corresponding estimated

development cost is (466)($8K) = $3.728M.

However, the development cost is not the full MCS project cost. For the

MBASE/RUP spiral model being used for the MCS project, Table 2.42 indicates

COCOMO II/Chapter 2/Boehm et al. - 86 -

that an added 6% is needed for the project’s Inception phase, and an added 12% is

needed for the Transition phase. This extra 18% means that the estimated project

cost is (1.18)($3.728M) = $4.4M.

For software maintenance, the ratings are again assumed to be nominal,

and the annual amount of modified software, discussed in Section 2.2.7, is

estimated to be 20% or 20 KSLOC. The estimated annual cost of software

maintenance is 2.94(20)1.10($8K) = $635K; the net savings per year is thus $4M-

.635M = $3.365M. The annual return on investment is thus savings/project costs

or $3.365M/$4.4M = 76%. For 5 years of operation, the savings are 5•($3.365M)

= $16.8M, and the ROI (5 years) is 16.8/4.4 = about 380%.

This is sufficiently high to justify the investment, even though we have

not used a present-value analysis to reconcile present and future cash flows.

Techniques for such analyses and more complete business-case analyses can be

found in Chapters 14 and 31.8 of [Boehm, 1981].

2.6.2 Setting project budgets and schedules.

The development schedule for the MCS is estimated to be TDEV =

3.67(MCS-PM)(0.28+0.2(E-0.91)) = 3.67(466)0.318 = 26 months. As the MCS project

plans to use the MBASE/RUP spiral approach to development, we can use the

phase schedule and effort percentages in Section 2.5 to calculate the schedule and

COCOMO II/Chapter 2/Boehm et al. - 87 -

effort within each phase. Once we have the estimated effort in person-months

(PM) and the schedule in months (Mo) for each phase, we can calculate the

average personnel level for each phase as P=PM/Mo. These calculations are done

in Table 2.42.

Thus, if the MCS project were truly all-nominal with respect to its cost

drivers and scale drivers, its manager should expect, for example, to employ an

average of 11.5 people during its Elaboration phase (between its Life Cycle

Objective and Life Cycle Architecture milestones as defined in Table A.1 of

Appendix A). The MCS manager should also plan for the Elaboration phase to

take 9.75 months and to cost $896k.

Table 2.42 MCS Project Phase Distributions

Effort Schedule Personnel Cost @ Phase % PM % Mo P $8K/PM Inception 6 28 12.5 3.25 8.6 $224K Elaboration Construction

24 76

112 354

37.5 62.5

9.75 16.25

11.5 21.8

$896K $2832K

Transition 12 56 12.5 3.25 17.2 $448K Devel. Total 100 466 100.0 26.00 17.9 $3728K Project Total 118 550 125 32.5 16.9 $4400K

2.6.3 Performing Tradeoff Analyses

COCOMO II/Chapter 2/Boehm et al. - 88 -

The COCOMO II cost drivers and scale drivers can be used directly to

analyze their effects on a project’s cost and schedule. For example, we can use

the Required Reliability (RELY) effort multipliers for software development and

maintenance to analyze the effects of different RELY levels on software life cycle

costs of the MCS project. For projects such as MCS, a good planning factor is to

assume that life cycle maintenance costs will be about twice as high as the

original project costs for a Nominal level of RELY.

The resulting analysis is shown in Table 2.43. For development, it

appears that lower RELY levels can save money. But these lower RELY levels

cause more maintenance effort to be spent on debugging and error correction,

making their life cycle costs higher than the Nominal level of required reliability.

When the costs of operational failures are also included, the higher RELY levels

will turn out to be lower-cost for high cost-of-failure systems.

Table 2.43 Effects of Reliability Level on MCS Life Cycle Costs

RELY Rating Very Low Low Nominal High Very High

Development Effort Multiplier 0.82 0.92 1.0 1.10 1.26 Cost $3608K $4048K $4400K $4840K $5544K

Maintenance Effort Multiplier 1.35 1.15 1.0 0.98 1.10 Cost (x2 for Nom.) $11,880K $10,120K $8,800K $8,624K $9,680K

Life Cycle Cost $15,488K $14,168K $13,200K $13,464K $15,224K

COCOMO II/Chapter 2/Boehm et al. - 89 -

2.6.4 Cost Risk Management

If there are uncertainties in key cost drivers, it can be a good idea to

establish a risk management reserve to cover the resulting possibilities of cost

growth [Edgar, 1982]. For example, suppose that there is some chance that new

developments will cause a 15% requirement evolution and volatility factor

(REVL) in the amount of software to be developed. From Equation 2.5, this

changes the effective size of the product to (1.15)(100KSLOC) = 115 KSLOC,

and the estimated cost to (2.94)(115)1.1 (1.18)($8K) = $5130K, an increase of

$730K over the original $4400K estimate. In such a case, the project’s financial

sponsor could establish a risk management reserve of $730K to cover any added

costs due to requirements evolution or volatility. Experience has shown that it is

best to provide performance incentives such as award fees to encourage

conserving as much as possible of the risk management reserve.

The project may have other common risks to assess. For example, the

project may not get all the experienced people it has asked for. Rather than

having overall Nominal ratings of Applications Experience (APEX) and Platform

Experience (PLEX), the project personnel may average halfway between Nominal

and Low for these cost drivers. Should this happen, the effort multipliers for

APEX (1.05) and PLEX (1.045) would be halfway between the Nominal and Low

values in Section 2.3.2.1.3. The resulting estimated cost would be

COCOMO II/Chapter 2/Boehm et al. - 90 -

($4400K)(1.05)(1.045) = $4828K and the resulting potential overrun risk would

be $428K. Further risk assessment guidance can be found in [Boehm, 1989] or

[Hall, 1998].

2.6.5 Development vs. Reuse Decisions

Another way of dealing with cost-growth (or schedule-growth) risks is to

reduce the costs. Many of the COCOMO II cost drivers provide opportunities to

reduce costs; one of the most attractive is to reduce the effective product-

development size via software reuse or commercial-off-the-shelf (COTS)

products.

The COCOMO II reuse model, Section 2.2.4, includes a number of factors

which help you to reason about reuse decisions. In the context of the MCS

system, for example, suppose we find a 40 KSLOC component of a related

project which we might reuse. However, it will need a good deal of redesign and

recoding. It is also not well-structured or well-documented, and there are no

people available for its modification who are familiar with its internals.

We would evaluate the COCOMO II reuse factors as follows:

DM = 40 (% design modified)

COCOMO II/Chapter 2/Boehm et al. - 91 -

CM = 50 (% code modified)

IM = 100 (% integration into new system required)

SU = 50 (poorly structured and documented)

UNFM = 1.0 (complete unfamiliarity with software)

AA = 5 (average assessment and adaptation effort)

The resulting equivalent size of the reuse component is:

( ) ( )

( ) KSLOC 46.4

0.550.61KSLOC 40 100

1.0505 100

1000.3500.3400.4KSLOC 40

100 UNFMSUAA

100 IM0.3CM0.3DM0.4SLOC AdaptedESLOC

= +×=

⎟ ⎠ ⎞

⎜ ⎝ ⎛

⎥⎦ ⎤

⎢⎣ ⎡ ×++⎥⎦

⎤ ⎢⎣ ⎡ ×+×+××=

⎟ ⎠ ⎞

⎜ ⎝ ⎛

⎥⎦ ⎤

⎢⎣ ⎡ ×++⎥⎦

⎤ ⎢⎣ ⎡ ×+×+××=

Thus, for this situation, we can see that the reuse component would be a

poor decision: its equivalent size, and thus its contribution to cost and schedule, is

larger than the 40 KSLOC option of developing a new component. Experience

has shown that this is the case for many hasty reuse decisions.

However, the COCOMO II reuse model also shows us which factors

might be able to change the situation. We can’t do much about the nature of the

reused component, but if we could find people to modify it who were very

familiar with its code and structure, we could reduce the unfamiliarity factor

UNFM enough to reduce the equivalent size ESLOC below 40 KSLOC.

COCOMO II/Chapter 2/Boehm et al. - 92 -

However, we would still have some highly unmaintainable software, and a life

cycle analysis would probably show that newly developed software with better

DM, CM, IM, and SU factors would still be a better decision. A similar life cycle

decision situation, legacy software phaseout, is discussed next.

COCOMO II/Chapter 2/Boehm et al. - 93 -

2.6.6 Legacy Software Phaseout Decisions

A separate program related to the MCS program is a corporate property

value accounting system. It is an old 50 KSLOC COBOL program which is

becoming increasingly difficult to maintain. Its key factors are:

Annual MCF = 0.20 (20% of the code –10KSLOC—is changed each year)

SU = 50 (very poorly structured and documented)

UNFM = 0.7 (few people familiar with the code)

Thus, its equivalent size to be changed each year is:

KSLOC/Yr. 13.5100 0.7))(50(1KSLOC 10 =⎥⎦

⎤ ⎢⎣ ⎡ ×+×

If the program were redeveloped, it could use the same database

management system and graphic user interface software as the MCS system is

using, leaving only 20 KSLOC of new applications software to be built.

Conservatively, let us assume that the new software will reduce the SU penalty

from 50 to 25, and that the UNFM factor will be reduced from 0.7 to 0.4. Then

the equivalent size to be changed each year is:

COCOMO II/Chapter 2/Boehm et al. - 94 -

( ) KSLOC/Yr. 4.41.14100 0.42510.20KSLOC 20 =×=⎟

⎠ ⎞⎜

⎝ ⎛ ×+××

If we add up the equivalent sizes of developing and maintaining the new

software for, say, 3 years, we get:

( ) KSLOC 32.24.4320 =×+

Maintaining the old legacy software for 3 years generates a larger

equivalent size of

KSLOC40.513.53 =×

Given that we will need to do property value accounting for at least 3

years, and that the size and cost reductions for the new software continue to

improve after 3 years, it is a good decision to build the new system and phase out

the old one.

COCOMO II/Chapter 2/Boehm et al. - 95 -

2.6.7 Software Reuse and Product Line Decisions

Besides its primary factory in the United States, UST has two large

foreign factories and several smaller factories. UST wishes to analyze whether it

would pay off to develop an MCS to support just-in-time manufacturing in all of

its factories. The product line would have particular challenges; due to the need

to accommodate multiple-country supplier logistics, order-processing interfaces,

and labor regulations. COCOMO II can support such an analysis via its Required

Reusability (RUSE) and related cost drivers affecting the cost to develop suitably

reusable software, and via the reused-software part of its sizing model.

In assessing the RUSE factor with respect to the rating scale in Section

2.3.2.1.1, UST conservatively judges that its multi-country factories have some

aspects of multiple product lines, and assigns a RUSE rating halfway between

Very High and Extra High. Following the RUSE guidance that the Required

Reliability (RELY) rating should be at most one level below the RUSE rating,

RELY is rated halfway between High and Very High. Conservatively, UST also

assigns a High rather than Nominal rating to the Documentation (DOCU) cost

driver. With all the other ratings at Nominal, this leads to an Effort Adjustment

Factor of (RUSE)(RELY)(DOCU) = (1.195)(1.18)(1.11) = 1.551. Applying this

to the Nominal project cost estimate produces a develop-for-reuse cost estimate of

($4400K)(1.551) = $6824K.

COCOMO II/Chapter 2/Boehm et al. - 96 -

In assessing the size adjustments due to reused software, UST makes the

following factor ratings, which are conservative for software developed to the

product-line standards in the develop-for-reuse cost estimate:

New factory-specific software: 40%

Black-box plug-and-play reuse: 30%

Reuse with modifications: 30%

Assessment and assimilation factor (AA): 2

Software understanding increment (SU): 10

Unfamiliarity factor (UNFM): 0.3

% design modified (DM): 10%

% code modified (CM): 20%

% integration redone (IM): 20%

With respect to the 100 KSLOC MCS product, the equivalent size due to

reuse works out to:

[ ] [ ] [ ]

[ ] SLOC 46.9

0.030.060.060.040.02300.640 100

100.3203.0100.40.02SLOC 300.02SLOC 30SLOC 40ESLOC

= ++++×++=

⎟ ⎠ ⎞⎜

⎝ ⎛ ×+×+×+×+×+=

COCOMO II/Chapter 2/Boehm et al. - 97 -

The resulting cost to reuse the software at each new factory is then:

$2966K PM

$8K1.55118.146.92.94Cost 1.1

××××=

We can then compare the cost of redeveloping the MCS software for each

new factory to the product line cost of developing-for-reuse plus the cost-to-reuse

for each reuse instance, as summarized in Figure 2.5.

Number of Factories Redevelopment Cost Product Line Cost Investment Return 1 $4,400K $6,824K -$2,424K 2 8,800K 9,790K -990K 3 13,200K 12,256K 444K 4 17,600K 15,772K 1,878K

-$3,000

-$2,000

-$1,000

$1,000

$2,000

$3,000

$4,000

0 1 2 3 4

Number of Factories

In ve

st m

en t R

et ur

n ($

K )

Figure 2.5 Reuse vs. Redevelopment Costs

COCOMO II/Chapter 2/Boehm et al. - 98 -

The results are consistent with the empirical “Rule of Three” for software

reuse: that it usually takes three instances of a product line to achieve a net payoff.

Given that UST has at least three large factories, and that its factor estimates have

been conservative, a decision to invest in a product line appears reasonable.

However, the decision should also consider other cultural circumstances critical to

successful software reuse; see [Reifer, 1997; Jacobson et. al., 1997; Poulin,

1997].

COCOMO II/Chapter 2/Boehm et al. - 99 -

2.6.8 Process Improvement Decisions

COCOMO II has several cost drivers and scale drivers which can be used

to evaluate candidate strategies for software process and productivity

improvement. Besides the software process maturity scale driver (PMAT), the

main COCOMO II factors include the reuse size factor we just discussed, the tool

usage cost driver (TOOL), the architecture and risk resolution scale driver

(RESL), and the project communications portion of the multisite development

cost driver (SITE). As discussed in Chapter 4, the analysis of the 161 project data

points in the current COCOMO II data base show a statistically significant

correlation between improvements in these and most other COCOMO II cost

drivers and reductions in software project effort.

Below, we show a simple return-on-investment analysis for improving

software productivity based just on the improvements in the Software Engineering

Institute Capability Maturity Model’s (SEI-CMM’s) 18 Key Process Areas

included in the PMAT scale driver rating. The COCOMO II PMAT variable

separates out such pure-process gains from complementary gains achievable via

reuse, tools, project communications, personnel factors, etc. In practice, the

PMAT analysis should be only a part of an overall product / process / personnel

productivity improvement analysis addressing not just effort and cost reduction

but other goals such as schedule reduction and quality improvement. An

COCOMO II/Chapter 2/Boehm et al. - 100 -

emerging COCOMO II extension called the Constructive Productivity Model

(COPROMO) is discussed in Chapter 5 as a step in this direction.

The UST software organization has achieved Level 2 on the SEI -CMM

rating scale, and wishes to perform a return-on-investment analysis for the

investment required to achieve Level 3. UST’s analysis of required investments

identifies process definition and training as the major investment items. Process

definition will be the main responsibility of a Software Engineering Process

Group (SEPG) of 3 full-time people plus 4 quarter-time people from UST’s major

performer organizations. This cost over the normal 2 years required to go from

Level 2 to Level 3 [Hayes-Zubrow, 1995] is estimated as (2years)(4

persons)($96K/person-year) = $768K.

For training, UST has identified three 1-week courses on Peer Reviews,

Product Engineering, and Management and Organizational Factors to cover the 7

Key Process Areas at Level 3. Conservatively, UST assumes that all 200

software people will require the 3 weeks of training. This is 3/52 of their annual

personnel cost of (200 persons)($8K/PM)(12 mo.) = $19,200K, or $1108K. The

other main costs of learning, institutionalization, and evaluation will largely be

done by the SEPG, but UST budgets another $124K for contingencies to make a

total investment of $768K+$1108K+$124K = $2000K, or $2 million.

From the COCOMO II scale drivers in Table 2.10, we can see that the

effect of going from Level 2 (Nominal) to Level 3 (High) involves a reduction in

COCOMO II/Chapter 2/Boehm et al. - 101 -

the scale factor from 4.68 to 3.12, or a reduction of .0156 in the exponent E used

to relate size to effort. For the typical 100KSLOC, all-nominal UST project, the

baseline exponent E = 1.10 yields an estimated effort of 2.94(100)1.10 = 466PM.

The reduced exponent for Level 3 yields an estimated effort of 2.94(100)1.0844 =

434PM, roughly a 7% improvement in productivity. This percentage

improvement will vary from about 4% for small projects (10 KSLOC) to about

11% for very large projects (2000 KSLOC) [Clark, 1999].

As discussed above, the annual cost of UST’s 200-person software

organization is roughly $19.2 million. A 7% improvement in productivity

corresponds with an annual savings of (.07)($19.2 million) = $1.344 million.

This is an annual return of about 67% on the $2 million investment to achieve

Level 3. Even a conservative 4% productivity improvement would produce an

annual return of about 38%. This conservative top-level analysis provides

stronger support of the anecdotal evidence that investments in software process

maturity are worthwhile. However, it is important to repeat that an organization’s

productivity strategies and analyses should not just look at the CMM, but should

be driven by the organization’s goals and priorities (e.g., for improving cost,

schedule, or quality); should consider added improvement strategies such as

reuse, staffing, and tool; and should be tailored to the organization’s specific

situation.

COCOMO II/Chapter 2/Boehm et al. - 102 -

2.6.9 Decision Analysis Summary

This section showed how the elements of the COCOMO II model defined

in Chapter 2 can support the eight decision analysis situations presented at the

beginning of Chapter 1. Note that all of the analyses could be done by hand (and

a hand calculator) via use of COCOMO II’s open internal equations, tables, and

definitions. One of the major advantages of COCOMO II is its ability to support

such analyses, based on a full understanding of the underlying cost drivers and

their effects, and to support reasoned discussion and negotiation of software cost

and schedule tradeoffs, based on the project stakeholders’ shared understanding of

the underlying model.

2.7 COCOMO II Model Summary and Versions

This section is a summary of the Early Design and Post-Architecture models

discussed in this chapter.

2.7.1 Model Equations, Tables, and Driver Rating Scales

2.7.1.1 Sizing equations

COCOMO II/Chapter 2/Boehm et al. - 103 -

The Post-Architecture and Early Design models use the same sizing equations.

Sizing is summarized below and discussed in Sections 2.2.4.2 and 2.2.5.

( )

[ ]

( ) ( ) ( )IM0.3CM0.3DM0.4AAF

0.5AAFfor , 100

UNFM) (SUAAFAA

0.5 AAFfor , 100

)UNFMSU0.02(1AAFAA

AAM

AAMKSLOC AdaptedKSLOC Equivalent

KSLOC Equivalent KSLOC New 100

REVL1Size

×+×+×=

⎪ ⎪ ⎩

⎪⎪ ⎨

⎧

> ×++

≤ ××+×+

×=

+×⎟ ⎠ ⎞

⎜ ⎝ ⎛ +=

Table 2.44 Sizing Equation Symbol Descriptions Symbol Description

AA Assessment and Assimilation AAF Adaptation Adjustment Factor AAM Adaptation Adjustment Modifier CM Percent Code Modified DM Percent Design Modified IM Percent of Integration Integration Required for the Adapted Software

KSLOC Thousands of Source Lines of Code REVL Requirements Evolution and Volatility

SU Software Understanding UNFM Programmer Unfamiliarity with Software

COCOMO II/Chapter 2/Boehm et al. - 104 -

2.7.1.2 Post-Architecture Model equations

( ) ATPROD

100 ATSLOC Adapted

SF0.01BE

PMEMSizeAPM

Auto

1j j

Auto 17

1i i E

× =

×+=

+×⋅=

∑ ∏

Table 2.45 Post-Architecture Model Symbol Descriptions Symbol Description

A Effort coefficient that can be calibrated, currently set to 2.94 AT Percentage of the code that is re-engineered by automatic translation

ATPROD Automatic translation productivity B Scaling base-exponent that can be calibrated, currently set to 0.91 E Scaling exponent described in Section 2.3.1

EM 17 Effort Multipliers discussed in Section 2.3.2.1 PM Person Months effort from developing new and adapted code

PMAuto Person Months effort from automatic translation activities discussed in Section 2.2.6.

SF 5 Scale Factors discussed in Section 2.3.1

COCOMO II/Chapter 2/Boehm et al. - 105 -

2.7.1.3 Early Design Model equations

Auto 7

1i i E PM EMSizeAPM ∏ = +×⋅=

Table 2.46 Early Design Symbol Descriptions Symbol Description

A Effort coefficient that can be calibrated, currently set to 2.94 E Scaling exponent described in Section 2.3.1

EM 7 Effort Multipliers discussed in Section 2.3.2.2 PM Person Months effort from developing new and adapted code

PMAuto Person Months effort from automatic translation activities discussed in Section 2.2.6.

SF 5 Scale Factors discussed in Section 2.3.1

2.7.1.4 Time to Develop equation

[ ]( )B-E0.2DF 100

SCED%])(PM[CTDEV FNS

×+=

××=

Table 2.47 TDEV Equation Symbol Descriptions Symbol Description

B The scaling base-exponent for the effort equation, currently set to 0.91 C Coefficient that can be calibrated, currently set to 3.67 D Scaling base-exponent that can be calibrated, currently set to 0.28 E The scaling exponent for the effort equation

PMNS Person Months estimated without the SCED cost driver (Nominal Schedule) SCED Required Schedule Compression TDEV Time to Develop in calendar months

COCOMO II/Chapter 2/Boehm et al. - 106 -

2.7.1.4 Driver Rating Scales

The driver rating scales for the Scale Drivers are given below and discussed in

Section 2.3.1.

Table 2.48 Scale Factors for COCOMO II Models

Scale

Drivers

Very Low

Low

Nominal

High

Very High

Extra High

PREC thoroughly unpreceden ted

largely unpreceden ted

somewhat unpreceden ted

generally familiar

largely familiar

thoroughly familiar

FLEX rigorous occasional relaxation

some relaxation

general conformity

some conformity

general goals

RESL little (20%) some (40%) often (60%) generally (75%)

mostly (90%)

full (100%)

TEAM

very difficult interactions

some difficult

interactions

basically cooperative interactions

largely cooperative

highly cooperative

seamless interactions

PMAT

SW-CMM Level 1 Lower

SW-CMM Level 1 Upper

SW-CMM Level 2

SW-CMM Level 3

SW-CMM Level 4

SW-CMM Level 5

or the estimated Process Maturity Level (EMPL)

The driver rating scales for the Post-Architecture model Cost Drivers are given

below in Table 2.44 and discussed in Section 2.3.2.1. The Cost Drivers for the

Early Design model are discussed in Section 2.3.2.2

COCOMO II/Chapter 2/Boehm et al. - 107 -

Table 2.49 Cost Driver Ratings for Post-Architecture Model

Cost Drivers

Very Low

Low

Nominal

High

Very High

Extra High

RELY slight inconvenienc

low, easily recoverable

losses

moderate, easily

recoverable losses

high financial loss

risk to human life

DATA DB bytes / Pgm SLOC <

10 ≤ D/P < 100

100 ≤ D/P < 1000

D/P > 1000

CPLX see Table 2.19 RUSE none across

project across

program across

product line across multiple

product lines DOCU Many life-

cycle needs uncovered

Some life- cycle needs uncovered.

Right-sized to life-cycle needs

Excessive for life-cycle needs

Very excessive for life-cycle needs

TIME ≤ 50% use of available execution time

70% 85% 95%

STOR ≤ 50% use of available storage

70% 85% 95%

PVOL major change every 12 mo.; minor change every 1 mo.

major: 6 mo.; minor: 2 wk.

major: 2 mo.; minor: 1 wk.

major: 2 wk.; minor: 2 days

ACAP 15th percentile

35th percentile

55th percentile

75th percentile

90th percentile

PCAP 15th percentile

35th percentile

55th percentile

75th percentile

90th percentile

PCON 48% / year 24% / year 12% / year 6% / year 3% / year AEXP ≤ 2 months 6 months 1 year 3 years 6 years PEXP ≤ 2 months 6 months 1 year 3 years 6 year LTEX ≤ 2 months 6 months 1 year 3 years 6 year TOOL edit, code,

debug simple, frontend, backend CASE, little integration

basic lifecycle tools, moderately integrated

strong, mature lifecycle tools, moderately integrated

strong, mature, proactive lifecycle tools, well integrated with processes, methods, reuse

COCOMO II/Chapter 2/Boehm et al. - 108 -

Table 2.49 (Cont'd)

Cost Drivers

Very Low

Low

Nominal

High

Very High

Extra High

SITE: Collo- cation

International Multi-city and multi- company

Multi-city or multi- company

Same city or metro area

Same building or complex

Fully collocated

SITE: Com- muni- cation

Some phone, mail

Individual phone, FAX

Narrow-band email

Wide-band electronic communica- tion.

Wide-band elect. comm, occasional video conf.

Interactive multimedia

SCED 75% of nominal

85% of nominal

100% of nominal

130% of nominal

160% of nominal

COCOMO II/Chapter 2/Boehm et al. - 109 -

2.7.2 COCOMO II Version Parameter Values

2.7.2.1 COCOMO II.2000 Calibration

The following table, Table 2,46, shows the COCOMO II.2000 calibrated values

for Post-Architecture scale factors and effort multipliers.

Table 2.50 COCOMO II.2000 Post-Architecture Calibrated values

Baseline Effort Constants: A = 2.94; B = 0.91 Baseline Schedule Constants: C = 3.67; D = 0.28

Driver Symbol VL L N H VH XH PREC SF1 6.20 4.96 3.72 2.48 1.24 0.00 FLEX SF2 5.07 4.05 3.04 2.03 1.01 0.00 RESL SF3 7.07 5.65 4.24 2.83 1.41 0.00 TEAM SF4 5.48 4.38 3.29 2.19 1.10 0.00 PMAT SF5 7.80 6.24 4.68 3.12 1.56 0.00 RELY EM1 0.82 0.92 1.00 1.10 1.26 DATA EM2 0.90 1.00 1.14 1.28 CPLX EM3 0.73 0.87 1.00 1.17 1.34 1.74 RUSE EM4 0.95 1.00 1.07 1.15 1.24 DOCU EM5 0.81 0.91 1.00 1.11 1.23 TIME EM6 1.00 1.11 1.29 1.63 STOR EM7 1.00 1.05 1.17 1.46 PVOL EM8 0.87 1.00 1.15 1.30 ACAP EM9 1.42 1.19 1.00 0.85 0.71 PCAP EM10 1.34 1.15 1.00 0.88 0.76 PCON EM11 1.29 1.12 1.00 0.90 0.81 APEX EM12 1.22 1.10 1.00 0.88 0.81 PLEX EM13 1.19 1.09 1.00 0.91 0.85 LTEX EM14 1.20 1.09 1.00 0.91 0.84 TOOL EM15 1.17 1.09 1.00 0.90 0.78 SITE EM16 1.22 1.09 1.00 0.93 0.86 0.80

SCED EM17 1.43 1.14 1.00 1.00 1.00

COCOMO II/Chapter 2/Boehm et al. - 110 -

Table 2.47 shows the COCOMO II.2000 calibrated values for Early Design effort

multipliers. The scale factors are the same as for the Post-Architecture model.

Table 2.51 COCOMO II.2000 Early Design Calibrated values

Baseline Effort Constants: A = 2.94; B = 0.91 Baseline Schedule Constants: C = 3.67; D = 0.28

Driver Symbol XL VL L N H VH XH PERS EM1 2.12 1.62 1.26 1.00 0.83 0.63 0.50 RCPX EM2 0.49 0.60 0.83 1.00 1.33 1.91 2.72 PDIF EM3 0.87 1.00 1.29 1.81 2.61 PREX EM4 1.59 1.33 1.12 1.00 0.87 0.74 0.62 FCIL EM5 1.43 1.30 1.10 1.0 0.87 0.73 0.62

RUSE EM6 0.95 1.00 1.07 1.15 1.24 SCED EM7 1.43 1.14 1.00 1.00 1.00

2.7.2.2 COCOMO II.1997 Calibration

The following table shows the COCOMO II.1997 calibrated values for scale

factors and effort multipliers.

COCOMO II/Chapter 2/Boehm et al. - 111 -

Table 2.52 COCOMO II.1997 Post-Architecture Calibrated values

Baseline Effort Constants: A = 2.45; B = 1.01 Baseline Schedule Constants: C = 2.66; D = 0.33

Driver Symbol VL L N H VH XH PREC SF1 0.0405 0.0324 0.0243 0.0162 0.0081 0.00 FLEX SF2 0.0607 0.0486 0.0364 0.0243 0.0121 0.00 RESL SF3 0.0422 0.0338 0.0253 0.0169 0.0084 0.00 TEAM SF4 0.0494 0.0395 0.0297 0.0198 0.0099 0.00 PMAT SF5 0.0454 0.0364 0.0273 0.0182 0.0091 0.00 RELY EM1 0.75 0.88 1.00 1.15 1.39 DATA EM2 0.93 1.00 1.09 1.19 RUSE EM3 0.91 1.00 1.14 1.29 1.49 DOCU EM4 0.89 0.95 1.00 1.06 1.13 CPLX EM5 0.75 0.88 1.00 1.15 1.30 1.66 TIME EM6 1.00 1.11 1.31 1.67 STOR EM7 1.00 1.06 1.21 1.57 PVOL EM8 0.87 1.00 1.15 1.30 ACAP EM9 1.50 1.22 1.00 0.83 0.67 PCAP EM10 1.37 1.16 1.00 0.87 0.74 PCON EM11 1.24 1.10 1.00 0.92 0.84 APEX EM12 1.22 1.10 1.00 0.89 0.81 PLEX EM13 1.25 1.12 1.00 0.88 0.81 LTEX EM14 1.22 1.10 1.00 0.91 0.84 TOOL EM15 1.24 1.12 1.00 0.86 0.72 SITE EM16 1.25 1.10 1.00 0.92 0.84 0.78 SCED EM17 1.29 1.10 1.00 1.00 1.00

2.7.3 Logical Lines of Source Code Counting Rules

What is a line of source code? This checklist, adopted from the Software

Engineering Institute [Park 1992], attempts to define a logical line of source code.

The intent is to define a logical line of code while not becoming too language

specific for use in collection data to validate the COCOMO 2.0 model.

COCOMO II/Chapter 2/Boehm et al. - 112 -

Table 2.53 Definition Checklist for Source Statements Counts

Definition Checklist for Source Statements Counts

Definition name: Logical Source Statements Date:_______________ (basic definition) Originator: COCOMO II Measurement unit: Physical source lines Logical source statements √ Statement type Definition √ Data Array Includes Excludes When a line or statement contains more than one type, classify it as the type with the highest precedence.

1 Executable Order of precedence: 1 √ 2 Nonexecutable

3 Declarations 2 √ 4 Compiler directives 3 √ 5 Comments

6 On their own lines 4 √ 7 On lines with source code 5 √ 8 Banners and non-blank spacers 6 √ 9 Blank (empty) comments 7 √

10 Blank lines 8 √ How produced Definition √ Data array Includes Excludes 1 Programmed √ 2 Generated with source code generators √ 3 Converted with automated translators √ 4 Copied or reused without change √ 5 Modified √ 6 Removed √ Origin Definition √ Data array Includes Excludes 1 New work: no prior existence √ 2 Prior work: taken or adapted from

Usage Definition √ Data array Includes Excludes 1 In or as part of the primary product √ 2 External to or in support of the primary product √

COCOMO II/Chapter 2/Boehm et al. - 113 -

Table 2.54 Definition Checklist for Source Statements Counts (continued)

Definition Checklist for Source Statements Counts

Definition name: Logical Source Statements Date:_______________ (basic definition) Originator: COCOMO II Delivery Definition √ Data array Includes Excludes 1 Delivered:

2 Delivered as source √ 3 Delivered in compiled or executable form, but not as source

√

4 Not delivered: 5 Under configuration control √ 6 Not under configuration control √

Functionality Definition √ Data array Includes Excludes 1 Operative √ 2 Inoperative (dead, bypassed, unused, unreferenced, or

unaccessible):

3 Functional (intentional dead code, reactivated for special purposes)

√

4 Nonfunctional (unintentionally present) √ Replications Definition √ Data array Includes Excludes 1 Master source statements (originals) √ 2 Physical replicates of master statements, stored in the master code √ 3 Copies inserted, instantiated, or expanded when compiling or linking √ 4 Postproduction replicates—as in distributed, redundant, or

reparameterized systems √

Development status Definition √ Data array Includes Excludes Each statement has one and only one status, usually that of its parent unit.

1Estimated or planned √ 2 Designed √ 3 Coded √ 4 Unit tests completed √ 5 Integrated into components √ 6 Test readiness review completed √ 7 Software (CSCI) tests completed √ 8 System tests completed √ Language Definition √ Data array Includes Excludes

List each source language on a separate line. 1 Separate totals for each language √

COCOMO II/Chapter 2/Boehm et al. - 114 -

Table 2.55 Definition Checklist for Source Statements Counts (continued)

Definition Checklist for Source Statements Counts

Definition name: Logical Source Statements Date:_______________ (basic definition) Originator: COCOMO II Clarifications Definition √ Data array Includes Excludes

(general) 1 Nulls, continues, and no-ops √ 2 Empty statements, e.g. “;;” and lone semicolons on separate lines √ 3 Statements that instantiate generics √ 4 Begin...end and {...} pairs used as executable statements √ 5 Begin...end and {...} pairs that delimit (sub)program bodies √ 6 Logical expressions used as test conditions √ 7 Expression evaluations used as subprograms arguments √ 8 End symbols that terminate executable statements √ 9 End symbols that terminate declarations or (sub)program bodies √ 10 Then, else, and otherwise symbols √ 11 Elseif statements √ 12 Keywords like procedure division, interface, and implementation √ 13 Labels (branching destinations) on lines by themselves √ Clarifications Definition √ Data array Includes Excludes

(language specific) Ada

1 End symbols that terminate declarations or (sub)program bodies √ 2 Block statements, e.g. begin...end √ 3 With and use clauses √ 4 When (the keyword preceding executable statements) √ 5 Exception (the keyword, used as a frame header) √ 6 Pragmas √

Assembly 1 Macro calls √ 2 Macro expansions √

C and C++ 1 Null statement, e.g. “;” by itself to indicate an empty body4 √ 2 Expression statements (expressions terminated by semicolons) √ 3 Expression separated by semicolons, as in a “for” statement √ 4 Block statements, e.g. {...} with no terminating semicolon √ 5 “;”, “;” or “;” on a line by itself when part of a declaration √ 6 “;” or “;” on a line by itself when part of an executable statement √ 7 Conditionally compiled statements (#if, #ifdef, #ifndef) √ 8 Preprocessor statements other than #if, #ifdef, and #ifndef √

COCOMO II/Chapter 2/Boehm et al. - 115 -

Table 2.56 Definition Checklist for Source Statements Counts (continued)

Definition Checklist for Source Statements Counts

Definition name: Logical Source Statements Date:_______________ (basic definition) Originator: COCOMO II Clarifications Definition √ Data array Includes Excludes

(language specific) CMS-2

1 Keywords like SYS-PROC and SYS-DD √ COBOL

1 “PROCEDURE DIVISION”, “END DECLARATIVES”, etc. √ FORTRAN

1 END statements √ 2 Format statements √ 3 Entry statements √

PASCAL 1 Executable statements not terminated by semicolons √ 2 Keywords like INTERFACE and IMPLEMENTATION √ 3 FORWARD declarations √

COCOMO II/Chapter 2/Boehm et al. - 116 -

Table 2.57 Definition Checklist for Source Statements Counts (continued)

Definition Checklist for Source Statements Counts

Definition name: Logical Source Statements Date:_______________ (basic definition) Originator: COCOMO II

Summary of Statement Types Executable statements Executable statements cause runtime actions. They may be simple statements such as assignments, goto’s, procedure calls, macro calls, returns, breaks, exits, stops, continues, nulls, no- ops, empty statements, and FORTRAN’s END. Or they may be structured or compound statements, such as conditional statements, repetitive statements, and “with” statements. Languages like Ada, C, C++, and Pascal have block statements [begin...end and {...}] that are classified as executable when used where other executable statements would be permitted. C and C++ define expressions as executable statements when they terminate with a semicolon, and C++ has a <declaration> statement that is executable. Declarations Declarations are nonexecutable program elements that affect an assembler’s or compiler’s interpretation of other program elements They are used to name, define, and initialize; to specify internal and external interfaces; to assign ranges for bounds checking; and to identify and bound modules and sections of code. Examples include declarations of names, numbers, constants, objects, types, subtypes, programs, subprograms, tasks, exceptions, packages, generics, macros, and deferred constants. Declarations also include renaming declarations, use clauses, and declarations that instantiate generics. Mandatory begin...end and {...} symbols that delimit bodies of programs and subprograms are integral parts of program and subprogram declarations. Language superstructure elements that establish boundaries for different sections of source code are also declarations. Examples include terms such as PROCEDURE DIVISION, DATA DIVISION, DECLARATIVES, END DECLARATIVES, INTERFACE, IMPLEMENTATION, SYS-PROC and SYS- DD. Declarations, in general, are never required by language specifications to initiate runtime actions, although some languages permit compilers to implement them that way. Compiler Directives Compiler directives instruct compilers, preprocessors, or translators (but not runtime systems) to perform special actions. Some, such as Ada’s pragma and COBOL’s COPY, REPLACE, and USE, are integral parts of the source language. In other languages like C and C++, special symbols like # are used along with standardized keywords to direct preprocessor or compiler actions. Still other languages rely on nonstandardized methods supplied by compiler vendors. In these languages, directives are often designated by special symbols such as #, $, and {$}.

COCOMO II/Chapter 2/Boehm et al. - 117 -

2.7.4 COCOMO Model comparisons

Since the 1981 publication of Software Engineering Economics, there have been

upgrades and modifications to COCOMO. The latest upgrade to the model is

presented in this chapter. The table below contrasts the differences of two major

upgrades to the original COCOMO 1981 model: Ada COCOMO and COCOMO

II.

COCOMO II/Chapter 2/Boehm et al. - 118 -

Table 2.58 COCOMO Model Comparisons

COCOMO 81

Ada COCOMO

COCOMO II Early Design

COCOMO II Post-Architecture

Size Delivered Source Instructions (DSI) or Source Lines of Code (SLOC)

DSI or SLOC Function Points (FP) with Language or SLOC

FP with Language or SLOC

Reuse Equivalent SLOC = Linear ƒ(DM,CM,IM)

Equivalent SLOC = Linear ƒ(DM,CM,IM)

Equivalent SLOC = nonlinear ƒ (AA,SU,UNFM,DM,CM,IM)

Requirements Change

Requirements Volatility rating (RVOL)

RVOL rating Change %: Requirements Evolution (REVL)

REVL

Maintenance Annual Change Traffic (ACT) = (%added + %modified)/yr.

ACT ƒ (MCF, SU, UNFM) MCF = (%added + %modified)

ƒ(MCF, SU, UNFM)

Scale Drivers, B, in PMNom=A(Size)B

Organic: 1.05 Semidetached: 1.12 Embedded: 1.20

Embedded: 1.04 – 1.24 depending on the degree of: - early risk elimination - solid architecture - stable requirements - Ada process maturity

B = 0.91 to 1.23 depending on the degree of: - Precedentedness - Development conformity - Early architecture and risk resolution - Team Cohesion - Process maturity

B = 0.91 to 1.23 depending on the degree of: - Prededentedness - Development conformity - Early architecture and risk

resolution - Team Cohesion - Process maturity

Product Cost Drivers

RELY, DATA, CPLX RELY1, DATA, CPLX1, RUSE

RCPX1,2, RUSE1,2 RELY1, DATA1, DOCU1,2, CPLX1,2, RUSE1,2

Platform Cost Drivers

TIME, STOR, VIRT, TURN TIME, STOR, VMVH, VMVT, TURN

Platform difficulty: PDIF1,2 TIME1, STOR1, PVOL1 (=VIRT)

Personnel Cost Drivers

ACAP, AEXP, PCAP, VEXP, LEXP

ACAP1, AEXP, PCAP1, VEXP, LEXP

Personnel capability and experience: PERS1,2, PREX1,2

ACAP1, PCAP1, PCON1,2, APEX1,2, LTEX1,2, PLEX1,2

Project Cost Drivers

MODP, TOOL, SCED MODP1, TOOL1, SCED, SECU

SCED1, FCIL1,2 TOOL1,2, SCED1, SITE1,2

1 Different multiplers 2 Different rating scale

COCOMO II/Chapter 2/Boehm et al. - 119 -

Description
Adaptation Adjustment Modifier
Software Understanding

Description

Effort coefficient that can be calibrated, currently set to 2.94

Description

Effort coefficient that can be calibrated, currently set to 2.94

Description

Person Months estimated without the SCED cost driver (Nominal Schedule)
Time to Develop in calendar months