3

Project Management Estimation Method – Parametric Approach – COCOMO

Posted by mgocean on May 27, 2009 in Estimation, Project Management |

COCOMO is classified as a composite model which relies on analytic techniques, statistical data fitting, and expert judgment. COCOMO was developed primarily using experience from large, specification-built software developed in the late 1970s and early 1980s. These projects served as the basis for fitting a number of duration estimation equations to different functional forms. Experience with COCOMO is mixed, with many stating that the model is no longer suited for use in this era of object-oriented programming and reuse. However, the fact remains that the basic forms of COCOMO are still widely used, and in fact, COCOMO serves as the foundation for most of the proprietary software estimating tools currently available. As with any estimation methodology, COCOMO is based on a number of assumptions and simplifications. Key assumptions and simplifications are as follows:

• A COCOMO estimate accounts for the software design phase, the programming phase, and the integration and testing phases. Estimates for other phases i.e., the implementation and maintenance phases must be calculated separately.

• Estimates only include labor that is directly attributed to the project. Labor costs for such items as administrative support are not included.

• A COCOMO ‘‘person-month’’ consists of 19 days ~152 h of working time.

• The functional requirements for the software are not substantially altered once the development phase has begun. (Smith B. L., 2002, pp: 104 – 110)

 

The examination revealed that COCOMO is extremely sensitive to small variations in an estimator’s judgment, and that the foundation of the COCOMO model is poorly suited for infrastructure system application. As a result, it is recommended that a research and development program be initiated to create specific tools to support the cost estimation of infrastructure system software development.

 

The basic COCOMO procedure is not conceptually complex. First, the overall size of the software system must be estimated. This is done using an approach known as function point analysis. Once the size is estimated in units of function points, it is converted to lines of code using published conversion factors. COCOMO parametric equations are then used to estimate the labor required to develop the software.

The most fundamental calculation in the COCOMO model is the use of the Effort Equation to estimate the number of person-months required to execute a software project. The other COCOMO results, like estimates of person requirements and schedule, are derived from this quantity.

EFFORT = A x (SIZE) B

In this equation, A is proportionally constant and B represents economy or diseconomy of scale. B depends on the development mode. The estimate of a project’s size is in source lines of code (SLOC).

 

The first step in a basic COCOMO analysis is to assign the project to one of three software development types: organic, semidetached, or embedded. These types are described below.

• Organic projects consist of small teams developing familiar code with in-house equipment. The experienced team members need minimal training and have worked with similar projects. The organic mode is typified by systems such as payroll, inventory, and scientific calculation. Other characterizations are that the project team is small, little innovation is required, constraints and deadlines are few, and the development environment is stable.

• Embedded projects are just the opposite. New technologies, unfamiliar code, or innovative problem-solving techniques must be developed to complete the project. Embedded projects require much more effort than organic projects do. The embedded mode is typified by real-time systems such as those for air traffic control, ATMs, or weapon systems. Other characterizations are that the project team is large, a great deal of innovation is required, constraints and deadlines are tight, and the development environment consists of many complex interfaces, including those with hardware and with customers.

 

• A semidetached project falls somewhere between organic and embedded. It generally contains aspects of both categories. Once a development type is designated, the COCOMO parametric equations are applied to find the required effort for the project. Table 4‑1 presents the parametric equations for each of the three development types. The semidetached mode is typified by utility systems such as compilers, database systems, and editors. Other characterizations are that the project team is medium-size, some innovation is required, constraints and deadlines are moderate, and the development environment is somewhat fluid.

 

Development type Effort ~in person-months!
Organic 2.43(Lines of Code/1000)1.05
Semidetached 3.03(Lines of Code/1000)1.12
Embedded 3.63(Lines of Code/1000)1.20

(Smith B. L., 2002, pp: 104 – 110)

 

 

 

Table 4‑2 Basic COCOMO Effort and Development Time Formulas

Mode

a

b

Effort Formula Effort = a x (Size)b

Development Time Formula

Organic

2.4

1.05

E = 2.4 x (S)1.05 TDEV = 2.5 x (E)0.38 Months
Semidetached

3.0

1.12

E = 3.0 x (S)1.12 TDEV = 2.5 x (E)0.35 Months
Embedded

3.6

1.20

E = 3.6 x (S)1.20 TDEV = 2.5 x (E)0.32 Months

 

 

 

Figure 4‑6 Boehm’s Original 63 Projects

Source: Adapted from Boehm, Barry (1976). Software Engineering Economics. Englewood Cliffs, NY: Prentice Hall. p. 76.

 

 

Table 4‑3 COCOMO Mode Characteristics

Mode

Product Size

Project/Team Size

Innovation

Deadline and Constraints

Development Environment

Organic Typically 2–50 KLOC Small project, small team—development team is familiar with the application language and tools Little Not Tight Stable, In-House
Semi–detached Typically 50–300 KLOC Medium project, medium team—team is average in terms of abilities Medium Medium Medium
Embedded Typically over 300 KLOC Large project requiring a large team Greater Severe Constraints Complex HW/Customer Interfaces

 

 

Suppose that a project was estimated to be 200 KLOC. Putting that data into the formula

Effort = a x (Size)b

Effort for the organic mode would be estimated at 2.4 x (200)1.05 = 2.4(260.66) = 626 staff-months.

Effort for the semidetached mode would be estimated at 3.0 x (200)1.12 = 3.0(377.71) = 1,133 staff-months. Effort for the embedded mode would be estimated at 3.6 x (200)1.20 = 3.6(577) = 2,077 staff-months.

After effort is estimated, an exponential formula is also used to calculate a project duration, or completion time (time to develop, TDEV). Project duration is expressed in months.

(Futrell R.T., Shafer D.F. & Safer L. I., 2002)

 

 

COCOMO is defined in terms of three different models: the basic model, the intermediate model, and the detailed model. The more complex models account for more factors that influence software projects, and make more accurate estimates.

Three levels of detail allow the user to achieve greater accuracy with each successive level.

  • Basic

This level uses only size and mode to determine the effort and schedule. It is useful for fast, rough estimates of small to medium-size projects.

  • Intermediate

This level uses size, mode, and 15 additional variables to determine effort. The additional variables are called “cost drivers” and relate to product, personnel, computer, and project attributes that will result in more effort or less effort required for the software project. The product of the cost drivers is known as the environmental adjustment factor (EAF).

  • Detailed

This level builds upon intermediate COCOMO by introducing the additional capabilities of phase-sensitive effort multipliers and a three-level product hierarchy. The intermediate level may be tailored to phase and product level to achieve the detailed level. An example of phase-sensitive effort multipliers would be consideration of memory constraints when attempting to estimate the coding or testing phases of a project. At the same time, though, memory size may not affect the effort or cost of the analysis phase. This will become more obvious after the effort multipliers (or cost drivers) are described. Phase-sensitive multipliers are generally reserved for use in mature organizations and require the use of an automated tool.

A three-level product hierarchy consists of system, subsystem, and module, much like the arrangement of a WBS. Large projects may be decomposed into at least three levels so that each of the cost drivers introduced in intermediate COCOMO is assigned to that level likely to be most influenced by variations in the cost driver. For example, an engineer’s language experience may apply only at the module level, an analyst’s capability may apply at a subsystem level and a module level, and required reliability may apply at the system, subsystem, and module level. As with the phase-sensitive multipliers, this will make more sense after the cost drivers are described. As with the phase-sensitive multipliers, mature organizations with automated tools are the heaviest users.

(Futrell R.T., Shafer D.F. & Safer L. I., 2002)

 

In addition to 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 4‑4).

Suppose 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

 

 

 

 

 

 

 

 

 

Table 4‑4 Basic COCOMO Phase Distribution of Effort and Schedule Example, Where Estimated SM = 692 and Estimated TDEV = 20

Plans and Requirements

Product Design

Coding

Integration and Test

Total

Effort (%) (% of effort spent in each major phase, based on historical data)

10%

12%

50.5%

27.5%

100% effort spread over four major phases

Effort (SM) = typical % of effort spent in this phase x estimated SM

.1 x 692 SM = 6.92 months

.12 x 692 SM = 83.04 months

.505 x 692 SM = 349.46 months

.275 x 692 SM = 190.3 months

692 months total staff-months

Schedule (%) (% of schedule spent on each major phase, based on historical data)

4%

33%

38%

25%

100% schedule spread over four major phases

Schedule (Months) = typical % of schedule spent on this phase x estimated TDEV

.04 x 20 = .8 months

.33 x 20 = 6.6 months

.38 x 20 = 7.6 months

.25 x 20 = 5 months

20 months duration (schedule)

Average # Personnel per major phase (Effort [SM]/Schedule [Months])

6.92÷.8 = 8.65 average persons

83.04÷6.6 = 12.5818 average persons

349.46÷7.6 = 45.98 average persons

190.3÷5 = 38.06 average persons

692÷20 = 34.6 average persons

 

(Futrell R.T., Shafer D.F. & Safer L. I., 2002)

 

 

 

 

 

The advantages of COCOMO include:

  • Actual data “back fitted” from many real programs can supply a set of COCOMO constants and adjustment factors that fit an organization well.
  • It is a repeatable process.
  • The method allows the addition of unique adjustment factors associated with an organization.
  • It is versatile enough to support different “modes” and “levels.”
  • It works well on projects that are not dramatically different in size, complexity, or process.
  • It is highly calibrated, based on previous experience.
  • It is thoroughly documented.
  • It is easy to use.

The disadvantages of COCOMO include:

  • It ignores requirements volatility (but an organization may add this as an extra adjustment factor in computing EAF).
  • It ignores documentation and other requirements.
  • It ignores customer attributes—skill, cooperation, knowledge, and responsiveness.
  • It oversimplifies the impact of security issues.
  • It ignores software safety issues.
  • It ignores the software development environment.
  • It ignores personnel turnover levels.
  • It ignores many hardware issues.
  • All the levels are dependent on the size estimate—the accuracy of the size drives the accuracy of effort, development time, staffing, and productivity estimates.
  • Experience-based estimation may be flawed because of obsolescence of the historical data used or because the estimators’ memory of past projects is flawed.
  • It is dependent on the knowledge of cost drivers and/or the amount of time spent in each phase.

Other potential issues include these:

  • The COCOMO model primarily represents development effort (from the planning phase through the implementation phase). Maintenance, rework, porting, and reuse are issues that don’t fit cleanly into the same model. These activities may also be estimated using a variation of the basic model.
  • COCOMO assumes a very basic level of effort for configuration management and quality assurance, allowing about 5% of the total budget for both (based on typical commercial practice at the time COCOMO was established). It can take two to four times this much with modern software engineering practices and typical complexity of modern software products.
  • Your data may not match the data used to develop COCOMO—if not, your company must collect the data needed to correlate the model.
  • COCOMO assumes a basic waterfall process model: 30% design, 30% coding, and 40% integration and testing.
  • COCOMO excludes: Requirements development and specification, which is often not used in some commercial applications. Even though this portion of the estimate is commonly viewed as the responsibility of a systems engineering or systems analysis function, it is often under scoped unless software engineers are invited to participate in the cost estimate. As shown in Figure 4‑7, an increase of 20% is generally needed for the requirements phase—even more when object-oriented methods are in use.

 

Figure 4‑7 Phases Included by COCOMO

(Futrell R.T., Shafer D.F. & Safer L. I., 2002)

 

COCOMO II takes software size and a set of factors as input and estimates effort in person-months. Estimates from the basic COCOMO II model can be made more accurate by taking into account other factors concerning the required characteristics of the software to be developed, the qualification and experience of the development team, and the software development environment.

COCOMO II is a revised and extended version of the model, built upon the original COCOMO. It more easily allows the estimation of object-oriented software, software created via spiral or evolutionary models, and applications developed from commercial-off-the-shelf software. It was created, in part, to develop software cost database and tool support capabilities for continuous model improvement and to provide a quantitative analytic framework and a set of tools and techniques for evaluating the effects of software technology improvements on software life cycle costs and schedules.

 

During the earliest conceptual stages of a project, the model uses object point estimates to compute effort. During the early design stages, when little is known about project size or project staff, unadjusted function points are used as an input to the model. After architecture has been selected, design and development begin with SLOC input to the model.

 

COCOMO II provides likely ranges of estimates that represent one standard deviation around the most likely estimate. Accommodating factors that received little attention in the first version, COCOMO now adjusts for software reuse and re-engineering where automated tools are used for translation of existing software. COCOMO II also accounts for requirements volatility in its estimates.

 

Whereas the exponent on size in the effort equations in the original COCOMO varies with the development mode, COCOMO II uses scaling factors to generalize and replace the effects of the development mode.

 

The COCOMO II application composition model uses object points to perform estimates. The model assumes the use of integrated CASE tools for rapid prototyping. Objects include screens, reports, and modules in third-generation programming languages. The number of raw objects is estimated, the complexity of each object is estimated, and the weighted total (object-point count) is computed. The percentage of reuse and anticipated productivity is also estimated. With this information, an effort estimate can be computed.

COCOMO II explicitly handles the availability of additional information in later stages of a project, the nonlinear costs of reusing software components, and the effects of several factors on the diseconomies of scale. (Some of these are the turnover rate of the staff, the geographic dispersion of the team, and the “maturity” of the development process as defined by the SEI.) The model also revises some coefficient values and eliminates discontinuities present in the old model (related to “development modes” and maintenance vs. adaptation).

COCOMO II is three different models:

  • The application composition model— Suitable for projects built with modern GUI-builder tools. Based on new object points.
  • The early design model— used to get rough estimates of a project’s cost and duration before the entire architecture has been determined. It uses a small set of new cost drivers and new estimating equations, and it is based on unadjusted function points or KSLOC.
  • The post-architecture model— the most detailed COCOMO II model, to be used after the development of the project’s overall architecture. It has new cost drivers, new line counting rules, and new equations.

In collaboration with Rational, Inc., COCOMO II integrates phases and milestones with those of the Rational Unified Process and has provided phase and activity distribution estimators for COCOMO II.

(Futrell R.T., Shafer D.F. & Safer L. I., 2002)

 

The main disadvantages of COCOMO II Model are;

  • Local calibration needed for accuracy.
  • In early phase of system lifecycle, the size is estimated with great uncertainty value. Its accuracy is necessarily limited because of lack of factors that have a significant influence on software costs.

(Parthasarathy, M. A. , 2007)

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

3 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyright © 2006-2018 Güzel Blog All rights reserved.
This site is using the Desk Mess Mirrored theme, v2.0.3, from BuyNowShop.com.