Basic COCOMO Phase Distribution of Effort and Schedule

Basic COCOMO Phase Distribution of Effort and Schedule

As well as estimating development effort and schedule, it is often necessary to estimate how the effort is distributed among the primary life cycle activities. COCOMO takes a pretty simplistic view of the life cycle phases, considering only plans and requirements, product design, coding, and integration and test as the four development phases, and maintenance as the final life cycle phase. Any of these activities may be going on during any of the phases: requirements analysis, product design, coding, test planning, verification and validation, project office functions, configuration management and quality assurance, documentation, and so on.

Let's look at an example of phase distribution of effort and schedule (see Table 1).

Assume that an embedded mode project is sized at 80 KLOC.

E (effort in staff-months) = 3.6(KLOC)1.20 = 3.6(80)1.20 = 3.6(192.18) = 692 staff-months

TDEV (development time) = 2.5(E)0.32 = 2.5(692)0.32 = 2.5(8.106) = 20 months

Basic COCOMO Phase Distribution of Effort and Schedule Example

Intermediate COCOMO

Intermediate COCOMO uses size and modes just like the basic model, plus 15 additional variables called cost drivers, which will be explained, and modified effort equations (Table 2). The idea is that there are characteristics of a given project that drive the cost (effort) up or down.

Intermediate COCOMO Effort Estimation

Inputs to intermediate COCOMO are KLOC (just as with basic COCOMO) and cost driver ratings, which further refine and improve the estimate. The equation appears in Box 1.

Intermediate COCOMO Formula

Note that constants for exponents and coefficients are different for each mode (see Box 2 and Table 2).

Intermediate COCOMO Formula - Coefficients and Exponents Change from Basic

Intermediate COCOMO Effort Formulas

Cost Drivers

The concept of the effort adjustment factor (EAF) is that it has the effect of increasing or decreasing the effort, and therefore cost, depending on a set of environmental factors. These environmental factors are also known as cost adjustment factors [C,s], or cost drivers. There are two steps in determining this multiplying factor:

Step 1. is to assign numerical values to the cost drivers.
Step 2. is to multiply the cost drivers together to generate the effort adjustment factor, C.

EAF is the product of the cost adjustment factors, as shown in Box 3.

When multiplied together, the cost adjustment factors can affect project cost and schedule estimates by 10 times or more.

Product of Cost Drivers Is the Effort Adjustment Factor

Cost drivers are grouped into four categories, as shown in Table 3.

Product Attributes

Some of the attributes that will drive the cost of a project up or down have to do with the product itself or with the nature of the job to be done. They contain:

●  Required reliability - applies mainly to real-time applications;

●  Database size - applies mainly to data-processing applications;

●  Product complexity - execution time constraints.

Computer Attributes

Other attributes have to do with the computer platform as a support tool, as well as with the job to be done:

●  Execution time constraint - applies when processor speed is barely sufficient;

●  Main storage constraints - applies when memory size is barely sufficient;

●  Virtual machine volatility - includes hardware and operating system of target machine;

●  Computer turnaround time - used for development (not too much of a problem now).

Intermediate COCOMO Cost Driver Categories

Project Attributes

Still others relate to practices and tools:

●  Modern programming practices - structured techniques or OO;

●  Modern programming tools - CASE, good debuggers, test-generation tools;

●  Schedule compression (or expansion) - deviation from ideal can never help, but shorter is worse than longer.

Personnel Attributes

Some attributes describe the people who do the job. These cost drivers tend to have high potential for cost increase or decrease:

●  Analyst capability;

●  Application experience;

●  Programmer capability;

●  Virtual machine experience - includes operating system and hardware;

●  Programming language experience - includes tools and practices.

Other Cost Drivers

Although product, computer, personnel, and project attributes are the four categories that are commonly associated with applications of the intermediate COCOMO model, additional attributes are often added by a project manager aware of other organizational (or project) strengths and/or weaknesses. Some common ones include:

●  Requirements volatility - some is expected, but too much can be a big problem;

●  Development machine volatility - unstable OS, compilers, CASE tools, and so on;

●  Security requirements - used for classified programs;

●  Access to data - sometimes very difficult;

●  Impact of standards and imposed methods;

●  Impact of physical surroundings.

Cost drivers are selected for their general significance to all software development projects and are independent of project size.

Each cost driver determines a multiplying factor that estimates the effect of the attribute on the amount of effort.

Numerical values of the cost drivers, multiplied together, generate the adjustment factor, C, as shown in Box 4.

Product of Cost Drivers

Because cost drivers are multiplicative, when a cost driver has no effect on effort, its value is 1, leaving the final value of C unchanged. Such cost drivers are considered normal or "nominal". For instance, if the programming language experience (LEXP) of the team in a given organization is better than that of any other organization in town, the LEXP value would still remain 1 because superior language ability is the norm in that environment. The estimator is searching for circumstances that will cause the effort to expand (the product of all cost drivers is greater than 1) or contract (the product of all cost drivers is less than 1) from the customary in an environment. Generally, when more effort is required, it is because the technology is new, the team is newly formed or consists of novices in the domain area, the complexity of the technological problem is great, or some other circumstance differs from the standard. When less effort is required, it is generally because the class of problem has been successfully tackled before.

Figure 1 illustrates the effect of the cost drivers moving from extra high to very low values. Product complexity (CPLX) for instance, takes a value of 0.70 if very low and 1.60 if very high. It becomes apparent how the product of the cost drivers (C) affects the effort estimation. If CPLX were the only cost driver that was not nominal and raw effort was 24 staff-months, the degree of complexity could cause the effort to range from 16.8 staff-months to 38.4 staff-months. Note the "bathtub" curve as SCED moves from very low to very high. To what can this phenomenon be attributed?

The Effect of Cost Drivers

The suggested values of the original 15 cost drivers are listed in Table 4. The rationale behind the assigned values is explaind in Table 5.

Intermediate COCOMO Software Development Cost Driver Values

Intermediate COCOMO Software Cost Driver Ratings

The model, having a strong sensitivity to CPLX, presents definitions of rating values for that cost driver in a separate table. Tables 6 through 9 show how CPLX is defined for five different applications: control operations, computational operations, device-dependent operations, data management operations, and requirements and product design.

CPLX Effort Adjustment Table for Control Operations

CPLX Effort Adjustment Table for Computational Operations

CPLX Effort Adjustment Table for Device-Dependent Operations

CPLX Effort Adjustment Table for Data Management Operations

Intermediate COCOMO Examples

Two examples of intermediate COCOMO follow. One uses normal values for the cost drivers; the other changes ACAP and PCAP ratings to high.

Intermediate COCOMO Example 1

A 10 KLOC embedded-mode software product is to perform communications processing functions on a commercial microprocessor.

●  The embedded mode formula gives nominal effort:
     En = 2.8(10)1.20 = 2.8(15.85) = 44 staff-months

●  An evaluation of the project environment yields choices for cost driver multiplier values. These values are shown in Table 10.

●  The adjustment factor is applied to the nominal effort:
     E = 2.8(10)1.20 x C = 44 x 1.17 = 51 staff-months

Cost Driver Values for the Intermediate COCOMO Example 1

Intermediate COCOMO Example 2

A project is estimated at 44 staff-months (SM). Using more capable personnel on the project decreases both the ACAP and PCAP ratings from nominal (1.00) to high (0.86), but the staff cost increases from $5,000 to $6,000 per SM. Suppose that all other cost drivers are rated nominal (1.00).

Effort Adjustment Factor (EAF) = C = RELY x DATA x CPLX x TIME x STOR x VIRT x TURN x ACAP x AEXP x PCAP x VEXP x LEXP x MODP x TOOL x SCED = 1.00 x 1.00 x 1.00 x 1.00 x 1.00 x 1.00 x 1.00 x 0.86 x 1.00 x 0.86 x 1.00 x 1.00 x 1.00 x 1.00 x 1.00 = 0.74

staff-month adjustment: 44 SM x 0.74 = 32.6


Conclusion: In this example, upgrading of the personnel more than pays for itself in the form of overall project savings.

Cost drivers behave like dial settings in that they help "tune" raw size until the level of effort becomes reasonable to support the development of the software, adhering to functional requirements. As shown in Figure 2, using size as a base, the output-staffing plan (effort spread over time) will change with cost driver settings.

Cost Drivers Tune Staffing

Although these 15 cost drivers are a good jump-start for environments that have little or no historical data upon which to draw, they are not expected to serve every organization in the same way or even one organization over a long span of time. What worked for TRW under Boehm's leadership in the late 1970s and early 1980s will not work for anyone else - and probably wouldn't even work for TRW in the 1990s. The idea is to use the model (not the actual data) and tailor it for a given environment. Boehm strongly suggests adding, changing, and deleting cost drivers as well as changing the values assigned to the ratings (extra high to very low). The data from the original 63 projects may be used until actual data is gathered, but after the actual data is available, it should replace the original and the model should be calibrated until it is tuned for a given type of application, a given organizational environment, or both. Many vendors supply automated tools to produce estimates, given size and complexity; many of the same tools provide automated support for adding actual data and calibrating the model by changing the exponent, the coefficient, the cost driver values, or all three. Having five data points (projects where size, time duration, and effort are observable) is enough to create a calibrated model.


cost drivers, variables, attributes, life cycle
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus