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.

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 1981, pp. 58-59].  The goal is to measure the amount of intellectual work put into program development.

Defining a line of code is difficult because of conceptual differences involved in accounting for executable statements and data declarations in different languages.  Difficulties arise when trying to define consistent measures across different programming languages.  In COCOMO II, the logical source statement has been chosen as the standard line of code.  The Software Engineering Institute (SEI) definition checklist for a logical source statement is used in defining the line of code measure.  The SEI has developed this checklist as part of a system of definition checklists, report forms and supplemental forms to support measurement definitions [Park 1992; Goethert et al. 1992].

A SLOC definition checklist is used to support the development of the COCOMO II model.  The full checklist is provided at the end of this manual, Table 64.  Each checkmark in the “Includes” column identifies a particular statement type or attribute included in the definition, and vice versa for the excludes.  Other sections in the definition clarify statement attributes for usage, delivery, functionality, replications and development status.

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, such as PERT sizing, expert consensus, analogy, top-down, and bottom-up, see Section 21.4 and Chapter 22 of [Boehm 1981].

2.2             Counting Unadjusted Function Points (UFP)

The function point cost estimation approach is based on the amount of functionality in a software project and a set of individual project factors [Behrens 1983; Kunkler 1985; IFPUG 1994].  Function points are useful estimators since they are based on information that is available early in the project life-cycle.  A brief summary of function points and their calculation in support of COCOMO II follows.

Function points measure a software project by quantifying the information processing functionality associated with major external data or control input, output, or file types.  Five user function types should be identified as defined in Table 1.

Table 1.         User Function Types

Function Point

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 then added to a base level of 0.65 to produce a general characteristic adjustment factor that ranges from 0.65 to 1.35.

Each of these fourteen characteristics, such as distributed functions, performance, and reusability, thus have a maximum of 5% contribution to estimated effort.  Having, for example, a 5% limit on the effect of reuse is inconsistent with COCOMO experience; thus COCOMO II uses Unadjusted Function Points for sizing, and applies its reuse factors, cost drivers, and scale 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.

            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.

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

 

Table 2.         FP Counting Weights

 

For Internal Logical Files and External Interface Files

 

 

Data Elements

 

Record Elements

1 - 19

20 - 50

51+

 

1

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

 

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

            Compute Unadjusted Function Points.  Add all the weighted functions counts to get one number, the Unadjusted Function Points.

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

Table 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.4             Aggregating New, Adapted, and Reused Code

A product’s size discussed thus far has been for new development.  Code that is taken from another source and used in the product under development also contributes to the product's effective size.  Preexisting code that is treated as a black-box and plugged into the product is called reused code.  Preexisting code that is treated as a white-box and is modified for use with the product is called adapted code.  The effective size of reused and adapted code is adjusted to be its equivalent in new code.  The adjusted code is called equivalent source lines of code (ESLOC).  The adjustment is based on the additional effort it takes to modify the code for inclusion in the product.  The sizing model treats reuse with function points and source lines of code the same in either the Early Design model or the Post-Architecture model.

2.4.1       Nonlinear Reuse Effects


Analysis in [Selby 1988] of reuse costs across nearly three thousand reused modules in the NASA Software Engineering Laboratory indicates that the reuse cost function, relating the amount of modification of the reused code to the resulting cost to reuse, is nonlinear in two significant ways (see Figure 1).  The effort required to reuse code does not start at zero.  There is generally a cost of about 5% for assessing, selecting, and assimilating the reusable component.

Figure 1.                   Non-Linear Reuse Effects

Figure 2.2 shows the results of the NASA analysis as blocks of relative cost.  A dotted line is superimposed on the blocks of relative cost to show increasing cost as more of the reused code is modified. (The solid lines are labeled AAM for Adaptation Adjustment Modifier.  AAM is explained in Equation 4.)  It can be seen that small modifications in the reused product generate disproportionately large costs.  This is primarily because of two factors: the cost of understanding the software to be modified, and the relative cost of checking module interfaces.

[Parikh-Zvegintzov 1983] contain data indicating that 47% of the effort in software maintenance involves understanding the software to be modified.  Thus, as soon as one goes from unmodified (black-box) reuse to modified-software (white-box) reuse, one encounters this software understanding penalty.  Also, [Gerlich-Denskat 1994] shows that, if one modifies k out of m software modules, the number of module interface checks required, N, is expressed in Equation 3.

                                                                                                      Eq. 3

Figure 2 shows this relation between the number of modules modified k and the resulting number, N, of module interface checks required for an example of m = 10 modules.  In this example, modifying 20% (2 of 10) of the modules required revalidation of 38% (17 of 45) of the interfaces.

The shape of this curve is similar for other values of m.  It indicates that there are nonlinear effects involved in the module interface checking which occurs during the design, code, integration, and test of modified software.

Figure 2.                  

Number of Module Interface Checks, N, vs. Modules Modified, k

The size of both the software understanding penalty and the module interface-checking penalty can be reduced by good software structuring.  Modular, hierarchical structuring can reduce the number of interfaces which need checking [Gerlich-Denskat 1994], and software that is well-structured, explained, and related to its mission will be easier to understand.  COCOMO II reflects this in its allocation of estimated effort for modifying reusable software. 

2.4.2       A Reuse Model

The COCOMO II treatment of software reuse uses a nonlinear estimation model, Equation 4.  This involves estimating the amount of software to be adapted and three degree-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.

                                              Eq. 4

The Software Understanding increment (SU) is obtained from Table 5.  SU is expressed quantitatively as a percentage.  If the software is rated very high on structure, applications clarity, and self-descriptiveness, the software understanding and interface-checking penalty is 10%.  If the software is rated very low on these factors, the penalty is 50%.  SU is determined by taking the subjective average of the three categories.

Table 5.         Rating Scale for Software Understanding Increment SU

 

 

Very Low

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

 

50

 

40

 

30

 

20

 

10

The other nonlinear reuse increment deals with the degree of Assessment and Assimilation (AA) needed to determine whether a reused software module is appropriate to the application, and to integrate its description into the overall product description.  Table 6 provides the rating scale and values for the assessment and assimilation increment.  AA is a percentage.

Table 6.         Rating Scale for Assessment and Assimilation Increment (AA)

AA Increment

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

Table 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 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).  The term (1 – AT/100) is for automatically translated code and is discussed in Section 2.2.6.

AAM uses the factors discussed above, Software Understanding (SU), Programmer Unfamiliarity (UNFM), and Assessment and Assimilation (AA) with a factor called the Adaptation Adjustment Factor (AAF).  AAF contains the quantities DM, CM, and IM where:

·         DM (Percent Design Modified) is the percentage of the adapted software’s design which is modified in order to adapt it to the new objectives and environment.  (This is necessarily a subjective quantity.)

·         CM (Percent Code Modified) is the percentage of the adapted software’s code which is modified in order to adapt it to the new objectives and environment. 

·         IM (Percent of Integration Required for Adapted Software) is the percentage of effort required to integrate the adapted software into an overall product and to test the resulting product as compared to the normal amount of integration and test effort for software of comparable size.

If there is no DM or CM (the component is being used unmodified) then there is no need for SU.  If the code is being modified then SU applies.

The range of AAM is shown in Figure 1.  Under the worst case, it can take twice the effort to modify a reused module than it takes to develop it as new (the value of AAM can exceed 100).  The best case follows a one for one correspondence between adapting an existing product and developing it from scratch.

2.4.3       Guidelines for Quantifying Adapted Software

This section provides guidelines to estimate adapted software factors for different categories of code using COCOMO II.  The New category refers to software developed from scratch.  Adapted code is preexisting code that has some changes to it, while reused code has no changes to the preexisting source (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 8 shows the valid ranges of reuse factors with additional notes for the different categories.

 

Table 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 preexisting 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%

 

0%

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%

 

 

 

0%

 

 

 

0% - 100%

 

 

 

0% – 8%

 

 

 

not applicable

2.5             Requirements Evolution and Volatility (REVL)

COCOMO II uses a factor called REVL, to adjust the effective size of the product caused by requirements evolution and volatility caused by such factors as mission or user interface evolution, technology upgrades, or COTS volatility.  It is the percentage of code discarded due to requirements evolution.  For example, a project which delivers 100,000 instructions but discards the equivalent of an additional 20,000 instructions has an REVL value of 20.  This would be used to adjust the project’s effective size to 120,000 instructions for a COCOMO II estimation.

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

                                                                                                       Eq. 5

where

                                SizeD is the reuse-equivalent of the delivered software.

2.6             Automatically Translated Code

The COCOMO II reuse model needs additional refinement to estimate the costs of software reengineering and conversion.  The major difference in reengineering and conversion is the efficiency of automated tools for software restructuring.  These can lead to very high values for the percentage of code modified (CM in the COCOMO II reuse model), but with very little corresponding effort.  For example, in the NIST reengineering case study [Ruhl-Gunn 1991], 80% of the code (13,131 COBOL source statements) was re-engineered by automatic translation, and the actual reengineering effort, 35 Person-Months, was more than a factor of 4 lower than the COCOMO estimate of 152 person months.

The COCOMO II reengineering and conversion estimation approach involves estimating an additional factor, AT, the percentage of the code that is re-engineered by automatic translation.  Based on an analysis of the project data above, the 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 6 shows how automated translation affects the estimated effort, PMAuto.

                                                                                     Eq. 6

The NIST case study also provides useful guidance on estimating the AT factor, which is a strong function of the difference between the boundary conditions (e.g., use of COTS packages, change from batch to interactive operation) of the old code and the re-engineered code.  The NIST data on percentage of automated translation (from an original batch processing application without COTS utilities) are given in Table 9 [Ruhl-Gunn 1991].


Table 9.         Variation in Percentage of Automated Re-engineering

Re-engineering Target

AT (% automated translation)

Batch processing

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.  If the automatically translated Adapted SLOC count is included as Size in the Equivalent KSLOC, it must be backed out to prevent double counting.  This is done by adding the term (1 – AT/100) to the equation for Equivalent KSLOC, Equation 2.4.

2.7             Sizing Software Maintenance

COCOMO II differs from COCOMO 81 in applying the COCOMO II scale drivers to the size of the modified code rather than applying the COCOMO 81 modes to the size of the product being modified.  Applying the scale 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.4.2.

The scope of “software maintenance” follows the COCOMO 81 guidelines in [Boehm 1981; pp.534-536]. It includes adding new capabilities and fixing or adapting existing capabilities. It excludes major product rebuilds changing over 50% of the existing software, and development of sizable (over 20%) interfacing systems requiring little rework of the existing system.

The maintenance size is normally obtained via Equation 7, when the base code size is known and the percentage of change to the base code is known.

                                                                             Eq. 7

The Maintenance Adjustment Factor (MAF) is discussed below.  But first, the percentage of change to the base code is called the Maintenance Change Factor (MCF).  The MCF is similar to the Annual Change Traffic in COCOMO 81, except that maintenance periods other than a year can be used.  Conceptually the MCF represents the ratio in Equation 8:

                                                                                         Eq. 8

A simpler version can be used when the fraction of code added or modified to the existing base code during the maintenance period is known.  Deleted code is not counted.

                                                                       Eq. 9

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 10, is used to adjust the effective maintenance size to account for software understanding and unfamiliarity effects, as with reuse.  COCOMO II uses the Software Understanding (SU) and Programmer Unfamiliarity (UNFM) factors from its reuse model (discussed in Section 2.4.2) to model the effects of well or poorly structured/understandable software on maintenance effort.

                                                                                                      Eq. 10

The use of (Size)M in determining maintenance effort, Equation 9, is discussed in Section 5.