6.3 Basic principles of COCOMO II

Lecture



The COCOMO method allows to estimate the complexity and development time of a software product. It was first published by Bari Boehme [3] in 1981 as the result of an analysis of 63 projects of TRW Aerospace. In 1997, the technique was improved and received the name COCOMO II. Parameters were calibrated according to 161 development projects. The model uses a regression formula with parameters determined on the basis of industry data and characteristics of a specific project.

Two stages of project evaluation are distinguished: a preliminary assessment at the initial phase and a detailed assessment after the elaboration of the architecture.

The formula for estimating the complexity of the project in people * months. has the form:

  6.3 Basic principles of COCOMO II

Where

  • SIZE - product size in KSLOC
  • EMi - labor multipliers
  • SFj - scale factors
  • n = 7 - for preliminary evaluation
  • n = 17 - for detailed evaluation

The main feature of the technique is that in order to assess the complexity, you need to know the size of the software product in thousands of source code lines (KSLOC, Kilo Source Lines Of Code). The size of a software product can, for example, be estimated by experts using the PERT method.

If we have analyzed the product using the method of functional points, then its size can be calculated using our own statistical data or using industry statistics [5] (Table 13).

Table 13. Estimation of the number of lines required to implement one unaligned functional point for some common programming languages.

Programming language Row count estimate
Most likely Optimistic Pessimistic
Assembler 172 86 320
C 148 9 704
C ++ 60 29 178
C # 59 51 66
J2ee 61 50 100
Javascript 56 44 65
PL / SQL 46 14 110
Visual basic 50 14 276

Scale factors

The methodology uses five factors of scale SF ;, which are determined by the following project characteristics:

  1. PREC - precedence, experience of similar developments (Very Low - no experience in the product and platform; Extra High - the product and platform are completely familiar)
  2. FLEX - development process flexibility (Very Low - the process is strictly deterministic; Extra High - only common goals are defined).
  3. RESL - architecture and risk resolution (Very Low - risks unknown / not analyzed; Extra High - risks 100% allowed)
  4. TEAM - team harmony (Very Low - formal interactions; Extra High - complete trust, interchangeability and mutual assistance).
  5. PMAT - process maturity (Very Low - CMM Level 1; Extra High - CMM Level 5)

The value of the scale factor, depending on the assessment of its level, is given in Table 14

Table 14. The value of the scale factor, depending on the assessment of its level

Scale factor Factor level assessment
Very low Low Nominal High Very high Extra high
PREC 6.20 4.96 3.72 2.48 1.24 0.00
Flex 5.07 4.05 3.04 2.03 1.01 0.00
RESL 7.07 5.65 4.24 2.83 1.41 0.00
TEAM 5.48 4.38 3.29 2.19 1.10 0.00
PMAT 7.80 6.24 4.68 3.12 1.56 0.00

Labor intensity multipliers

Our task does not include a detailed description of the COCOMO II method, so we will only consider the case of a preliminary assessment of the complexity of a software project. For this assessment, it is necessary to estimate for the project the level of the seven factors of labor intensity M, -:

  1. PERS - staff qualifications (Extra Low - analysts and programmers have lower qualifications, turnover more than 45%; Extra High - analysts and programmers have the highest qualification, flow less than 4%)
  2. RCPX - complexity and reliability of the product (Extra Low - product is simple, there are no special requirements for reliability, the database is small, documentation is not required; Extra High is a very complex product, requirements for reliability are stringent, database is extra large, documentation is required in full)
  3. RUSE - development for reuse (Low - not required; Extra High - reuse in other products required)
  4. PDIF - the complexity of the development platform (Extra Low - there are no special restrictions on memory and speed, the platform is stable; Extra High - severe restrictions on memory and speed, the platform is unstable)
  5. PREX - staff experience (Extra Low - new application, tools and platform; Extra High - application, tools and platform are well known)
  6. FCIL - equipment (Extra Low - simple tools, communication difficult; Extra High - integrated means of life cycle support, interactive multimedia communications)
  7. SCED - schedule compression (Very Low - 75% of the nominal duration; Very High - 160% of the nominal duration)

The influence of labor intensity factors depending on their level is determined by their numerical values, which are presented in the matrix below, (Table 15).

Table 15. The values ​​of labor intensity multipliers, depending on the assessment of their level

Estimation of the level of labor intensity

Extra low Very low Low Nominal High Very high Extra high
PERS 2.12 1.62 1.26 1.00 0.83 0.63 0.5
Rcpx 0.49 0.60 0.83 1.00 1.33 1.91 2.72
RUSE n / a n / a 0.95 1.00 1.07 1.15 1.24
PDIF n / a n / a 0.87 1.00 1.29 1.81 2.61
Prex 1.59 1.33 1.22 1.00 0.87 0.74 0.62
FCIL 1.43 1.30 1.10 1.0 0.87 0.73 0.62
Sced n / a 1.43 1.14 1.00 1.00 1.00 n / a

From this table, in particular, it follows that if in our project low qualification of analysts, then its labor intensity will increase approximately 4 times in comparison with the project, in which top-class analysts participate. And this is not the invention of theorists, and industry statistics!

Multicomponent product evaluation

As we noted earlier (see Lecture 4. Project planning), in order to adequately plan a project and evaluate its complexity, it is necessary to perform a preliminary design of the software product. As a result of decomposition, we get a number of components (N) that make up the software product.

It should be understood that the total complexity of the project is not equal to the simple sum of the complexity of the development of each of the components:

  6.3 Basic principles of COCOMO II

The simple amount does not take into account the relationship of components and labor costs for their integration.

The COCOMO II methodology determines the following sequence for calculating the project's labor input for multi-component development.

  1. The total size of the product is calculated as the sum of the sizes of its components:

      6.3 Basic principles of COCOMO II

  2. The basic complexity of the project is calculated by the formula:

      6.3 Basic principles of COCOMO II

  3. Then calculated the basic complexity of each component:

      6.3 Basic principles of COCOMO II

  4. In the next step, an estimate of the complexity of the components is calculated, taking into account all the factors of labor intensity, except for the SCED factor .

      6.3 Basic principles of COCOMO II

  5. And finally, the final complexity of the project is determined by the formula:

  6.3 Basic principles of COCOMO II

Estimation of project duration

The project duration in the COCOMO II method is calculated by the formula:

  6.3 Basic principles of COCOMO II

Where

  • C = 3.67; D = 0,28;
  • PMNS - project labor intensity without taking into account the SCED multiplier , which determines the schedule compression.

findings

Evaluation of labor should be a probabilistic statement. This means that for it there is a certain probability distribution, which can be very wide, if the uncertainty is high, or narrow enough, if the uncertainty is low.

Using your own experience or the experience of colleagues obtained in similar projects is the most pragmatic approach that allows you to get quite realistic estimates of the complexity and duration of the implementation of a software project, quickly and without high costs.

If there is no own experience of similar projects, and expert colleagues are not available, then it is necessary to use formal methods based on generalized industry experience. Among them, the most common are two approaches:

  • FPA IFPUG - function point method,
  • COCOMO II method, Constructive Cost Model.

Non-realistic assessments are one of the most serious demotivating factors for members of the project team. Underestimation leads to planning errors and inefficient interaction. Aggressive deadlines, constant pressure, overtime, rush jobs cause the project costs to grow exponentially and indefinitely.


Comments


To leave a comment
If you have any suggestion, idea, thanks or comment, feel free to write. We really value feedback and are glad to hear your opinion.
To reply

software project management

Terms: software project management