11/12/2024

Lecture Topic: COCOMO

By : Dr. Anjali
Assistant Professor
ABV-IIITM Gwalior

SOFTWARE PROJECT PLANNING

The Constructive Cost Model (COCOMO)
Constructive Cost model
(COCOMO)

Basic Intermediate Detailed

Model proposed by
B. W. Boehm’s
through his book
Software Engineering Economics in 1981
2

1
 11/12/2024

COCOMO applied to

Semidetached
Organic mode Embedded
mode mode

Mode Project size Nature of Project Innovation Deadline of Development

the project Environment

Organic Typically Small size project, experienced Little Not tight Familiar & In
developers in the familiar house
2-50 KLOC
environment. For example, pay
roll, inventory projects etc.

Semi Typically Medium size project, Medium Medium Medium Medium

detached size team, Average previous
50-300 KLOC
experience on similar project.
For example: Utility systems
like compilers, database
systems, editors etc.

Embedded Typically over Large project, Real time Significant Tight Complex
systems, Complex interfaces, Hardware/
300 KLOC customer
Very little previous experience.
For example: ATMs, Air Traffic Interfaces
Control etc. required

Table 4: The comparison of three COCOMO modes

4

2
 11/12/2024

BASIC MODEL
Basic COCOMO model takes the form

E  ab (KLOC) bb

D  cb (E) d b
where E is effort applied in Person-Months, and D is the development time in
months. The coefficients ab, bb, cb and db are given in table 4 (a).

Software ab bb cb db
Project

Organic 2.4 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Table 4(a): Basic COCOMO coefficients

3
 11/12/2024

When effort and development time are known, the average staff size to complete
the project may be calculated as:

E
Average staff size (SS)  Persons
D

When project size is known, the productivity level may be calculated as:

KLOC
Productivity (P)  KLOC / PM
E

EXAMPLE:
Suppose that a project was estimated to be 400 KLOC.
Calculate the effort and development time for each of the
three modes i.e., organic, semidetached and embedded.

4
 11/12/2024

Solution

The basic COCOMO equation take the form:

E  ab (KLOC) bb
D  cb (KLOC) d b
Estimated size of the project = 400 KLOC

(i) Organic mode

E = 2.4(400)1.05 = 1295.31 PM
D = 2.5(1295.31)0.38 = 38.07 PM

(ii) Semidetached mode

E = 3.0(400)1.12 = 2462.79 PM
D = 2.5(2462.79)0.35 = 38.45 PM

(iii) Embedded mode

E = 3.6(400)1.20 = 4772.81 PM
D = 2.5(4772.8)0.32 = 38 PM

10

10

5
 11/12/2024

EXAMPLE:
A project size of 200 KLOC is to be developed. Software development team has
average experience on similar type of projects. The project schedule is not very
tight. Calculate the effort, development time, average staff size and productivity of
the project.

11

11

Solution

The semi-detached mode is the most appropriate mode; keeping in view the size,
schedule and experience of the development team.

Hence E = 3.0(200)1.12 = 1133.12 PM

D = 2.5(1133.12)0.35 = 29.3 PM

E
Average staff size (SS)  Persons
D

1133.12
  38.67Persons
29.3
12

12

6
 11/12/2024

KLOC 200
Productivity    0.1765 KLOC / PM
E 1133.12

P  176 LOC / PM

13

13
PRESENTATION TITLE

INTERMEDIATE Cost drivers

MODEL • Product Attributes
• Required s/w reliability
• Size of application database
• Complexity of the product

Hardware Attributes

• Run time performance constraints

• Memory constraints
• Virtual machine volatility
• Turnaround time

14

14

7
 11/12/2024

15

15

INTERMEDIATE COCOMO
EQUATIONS
E  ai (KLOC) bi * EAF
D  ci (E) d i
Project ai bi ci di

Organic 3.2 1.05 2.5 0.38

Semidetached 3.0 1.12 2.5 0.35

Embedded 2.8 1.20 2.5 0.32

Table 6: Coefficients for intermediate COCOMO

16

16

8
 11/12/2024

Principle of the effort estimate

Size equivalent

As the software might be partly developed from software already existing (that is,
re-usable code), a full development is not always required. In such cases, the parts
of design document (DD%), code (C%) and integration (I%) to be modified are
estimated. Then, an adjustment factor, A, is calculated by means of the following
equation.

A = 0.4 DD + 0.3 C + 0.3 I

The size equivalent is obtained by

S (equivalent) = (S x A) / 100

Ep  pE
Dp   p D
17

17

Lifecycle Phase Values of p

Mode & Code Plan & System Detailed Module Integration
Size Requirements Design Design Code & Test & Test

Organic Small
0.06 0.16 0.26 0.42 0.16
S≈2
Organic
0.06 0.16 0.24 0.38 0.22
medium S≈32
Semidetached
0.07 0.17 0.25 0.33 0.25
medium S≈32
Semidetached
0.07 0.17 0.24 0.31 0.28
large S≈128
Embedded
0.08 0.18 0.25 0.26 0.31
large S≈128
Embedded
extra large 0.08 0.18 0.24 0.24 0.34
S≈320

Table 7 : Effort and schedule fractions occurring in each phase of the

lifecycle 18

18

9
 11/12/2024

Lifecycle Phase Values of p

Mode & Code Plan & System Detailed Module Code Integration
Size Requirements Design Design & Test & Test

Organic Small
0.10 0.19 0.24 0.39 0.18
S≈2
Organic
0.12 0.19 0.21 0.34 0.26
medium S≈32
Semidetached
0.20 0.26 0.21 0.27 0.26
medium S≈32
Semidetached
0.22 0.27 0.19 0.25 0.29
large S≈128
Embedded
0.36 0.36 0.18 0.18 0.28
large S≈128
Embedded
extra large 0.40 0.38 0.16 0.16 0.30
S≈320

Table 7 : Effort and schedule fractions occurring in each phase of the

lifecycle 19

19

Example: 4.7
A new project with estimated 400 KLOC embedded system has to
be developed. Project manager has a choice of hiring from two
pools of developers: Very highly capable with very little experience
in the programming language being used
Or
Developers of low quality but a lot of experience with the
programming language. What is the impact of hiring all developers
from one or the other pool ?

20

20

10
 11/12/2024

Solution
This is the case of embedded mode and model is intermediate
COCOMO.
Hence E  ai (KLOC) d i
= 2.8 (400)1.20 = 3712 PM

Case I: Developers are very highly capable with very little experience
in the programming being used.

EAF = 0.82 x 1.14 = 0.9348

E = 3712 x .9348 = 3470 PM
D = 2.5 (3470)0.32 = 33.9 M
21

21

Case II: Developers are of low quality but lot of experience with the
programming language being used.

EAF = 1.29 x 0.95 = 1.22

E = 3712 x 1.22 = 4528 PM
D = 2.5 (4528)0.32 = 36.9 M

Case II requires more effort and time. Hence, low quality developers
with lot of programming language experience could not match with
the performance of very highly capable developers with very litter
experience.

22

22

11
 11/12/2024

Example: 4.8
Consider a project to develop a full screen editor. The major
components identified are:
I. Screen edit
II. Command Language Interpreter
III. File Input & Output
IV. Cursor Movement
V. Screen Movement
The size of these are estimated to be 4k, 2k, 1k, 2k and 3k
delivered source code lines. Use COCOMO to determine
1. Overall cost and schedule estimates (assume values for
different cost drivers, with at least three of them being
different from 1.0)
2. Cost & Schedule estimates for different phases. 30

23

Solution

Size of five modules are:

Screen edit = 4 KLOC

Command language interpreter = 2 KLOC
File input and output = 1 KLOC
Cursor movement = 2 KLOC
Screen movement = 3 KLOC
Total = 12 KLOC

24

24

12
 11/12/2024

Let us assume that significant cost drivers are

i. Required software reliability is high, i.e.,1.15

ii. Product complexity is high, i.e.,1.15

iii. Analyst capability is high, i.e.,0.86

iv. Programming language experience is low,i.e.,1.07

v. All other drivers are nominal

EAF = 1.15x1.15x0.86x1.07 = 1.2169

25

25

(a) The initial effort estimate for the project is obtained from the
following equation

E = ai (KLOC)bi x EAF
= 3.2(12)1.05 x 1.2169 = 52.91 PM
Development time D = Ci(E)di
= 2.5(52.91)0.38 = 11.29 M
(b) Using the following equations and referring Table 7, phase wise
cost and schedule estimates can be calculated.
Ep  pE
Dp   p D
26

26

13
 11/12/2024

Since size is only 12 KLOC, it is an organic small model. Phase wise

effort distribution is given below:
System Design = 0.16 x 52.91 = 8.465 PM
Detailed Design = 0.26 x 52.91 = 13.756 PM
Module Code & Test = 0.42 x 52.91 = 22.222 PM
Integration & Test = 0.16 x 52.91 = 8.465 PM
Now Phase wise development time duration is
System Design = 0.19 x 11.29 = 2.145 M
Detailed Design = 0.24 x 11.29 = 2.709 M
Module Code & Test = 0.39 x 11.29 = 4.403 M
Integration & Test = 0.18 x 11.29 = 2.032 M

27

27

STRENGTHS OF COCOMO
PRESENTATION TITLE

• Empirically-Based: COCOMO is based on data collected from real software projects,

making it a reliable model for estimation.
• Flexible: With three levels of complexity (Basic, Intermediate, Detailed), COCOMO can
be adapted to different levels of project knowledge and available information.
• Adjustable to Various Project Types: It offers tailored formulas for different types of
software projects (organic, semi-detached, embedded), improving its accuracy.
• Breakdown by Phases: Detailed COCOMO allows for precise control over different
phases of development, helping manage large-scale projects.

28

28

14
 11/12/2024

LIMITATIONS OF COCOMO
PRESENTATION TITLE

• Outdated for Modern Practices: While useful in the 1980s and 1990s, COCOMO 81
does not fully account for modern software development practices like Agile, DevOps,
or object-oriented programming.
• Line of Code-Based: The reliance on KLOC for size estimation is limiting, as early-
stage projects often do not have accurate code size estimates.
• Complexity in Intermediate and Detailed Models: The addition of multiple effort
multipliers and cost drivers makes COCOMO more accurate but also more complex to
use, requiring extensive data collection.
• Limited in Handling Iterative Development: COCOMO is designed for traditional
waterfall-like models and is less applicable to iterative and incremental development
methodologies.
29

29

SUMMARY OF COCOMO
The Constructive Cost Model (COCOMO)
Constructive Cost model
(COCOMO)

Basic Intermediate Detailed

Model proposed by
B. W. Boehm’s
through his book
Software Engineering Economics in 1981
30

30

15
 11/12/2024

COCOMO II

31

KEY FEATURES OF COCOMO II

PRESENTATION TITLE

Adaptation to Modern Software Practices:

COCOMO II was introduced to account for Support for Different Development
the rapid changes in software engineering, Approaches: It provides estimations for
such as object-oriented programming, projects using different software life cycle
reusability, and the emergence of new models, including waterfall, iterative, and
development environments like Rapid agile approaches.
Application Development (RAD) and Agile.

32

32

16
 11/12/2024

KEY FEATURES OF COCOMO II

PRESENTATION TITLE

Three Stages of Estimation: COCOMO II breaks down the estimation process into three stages to handle projects at
different stages of development

Applications Composition Model: Used in the early stages of development (like prototyping or
using fourth-generation languages). It estimates effort based on object points, which measure
the number of screens, reports, and components.

Early Design Model: Used when the project's overall architecture and requirements are known
but details are still to be worked out. This model uses function points or a similar size metric,
along with seven scale drivers and seventeen effort multipliers to estimate the cost.

Post-Architecture Model: Used when the project has a well-defined architecture and detailed
33
design. This is the most detailed estimation model and uses size metrics (lines of code, function
points) and cost drivers to compute the final estimates.

33

Application Composition Estimation Model (COCOMO II | Stage 1)

Fig.5: Steps for the estimation of effort in person months

34

17
 11/12/2024

Application Composition Estimation Model (COCOMO II | Stage 1)

i. Assess object counts: Estimate the number of screens, reports and third-
generation (3GL) components that will comprise this application.

ii. Classification of complexity levels: We have to classify each object instance

into simple, medium and difficult complexity levels depending on values of its
characteristics.

Table9 (a): For screens

35

35

Application Composition Estimation Model (COCOMO II | Stage 1)

Table 9(b): For reports

36

36

18
 11/12/2024

Application Composition Estimation Model (COCOMO II | Stage 1)

iii. Assign complexity weight to each object : The weights are used
for three object types i.e., screen, report and 3GL components using
the Table 10.

Table10: Complexity weights for each level

37

37

Application Composition Estimation Model (COCOMO II | Stage 1)

iv. Determine object points: Add all the weighted object instances to
get one number and this known as object-point count.

v. Compute new object points: We have to estimate the percentage

of reuse to be achieved in a project. Depending on the percentage
reuse, the new object points (NOP) are computed.

(object points) * (100-%reuse)

NOP =
100

NOP are the object points that will need to be developed and differ from
the object point count because there may be reuse.

38

38

19
 11/12/2024

Application Composition Estimation Model (COCOMO II | Stage 1)

vi. Calculation of productivity rate: The productivity rate can be

calculated as:
Productivity rate (PROD) = NOP/Person month

Table 11: Productivity values

39

39

Application Composition Estimation Model (COCOMO II | Stage 1)

vii. Compute the effort in Persons-Months: When PROD is known,

we may estimate effort in Person-Months as:

NOP
Effort in PM = ------------
PROD

40

40

20
 11/12/2024

Example:
Consider a database application project with the following
characteristics:
I. The application has 4 screens with 4 views each and 7 data
tables for 3 servers and 4 clients.
II. The application may generate two report of 6 sections each
from 07 data tables for two server and 3 clients. There is
10% reuse of object points.

The developer’s experience and capability in the similar

environment is low. The maturity of organization in terms of
capability is also low. Calculate the object point count, New object
points and effort to develop such a project.
41

41

Solution
This project comes under the category of application composition
estimation model.
Number of screens = 4 with 4 views each
Number of reports = 2 with 6 sections each

From Table 9 we know that each screen will be of medium

complexity and each report will be difficult complexity.
Using Table 10 of complexity weights, we may calculate object point
count.
= 4 x 2 + 2 x 8 = 24
24 * (100 -10)
NOP = = 21.6
100
42

42

21
 11/12/2024

Table 11 gives the low value of productivity (PROD) i.e. 7.

NOP
Efforts in PM = -----------
PROD

21.6
Efforts = ----------- = 3.086 PM
7

43

43

EARLY DESIGN MODEL : COCOMO-II

PRESENTATION TITLE

• The early design model uses Unadjusted Function Points (UFP) as

measure of size.
PMnominal = A * (size)B

where PMnominal = Effort for the project in person months

A = constant representing the nominal productivity where A = 2.5
B = Scale Factor
Size = size of the Software

If B = 1.0, there is linear relationship between effort and size of product. If the
value of B is not equal to 1, there will be non-linear relationship between size
of product and effort. If B < 1.0, rate of increase of effort decreases as the size
44 of product increases. If B > 1.0, rate of increase of effort increase as the size of
product is increased.

44

22
 11/12/2024

EARLY DESIGN MODEL : COCOMO-II

PRESENTATION TITLE

• Here the basic assumption stands as effort on project usually

increases faster than size of product. However, value of ‘B’ is
computed on basis of scaling factors that may cause loss of
productivity corresponding to an increase in the size as follows
–
1. Precedentness-It reflects the experience on similar projects
previously.
• The value for scale factor is 6.20(Very Low),
• 4.96(Low),
• 3.72(Average),
• 2.48(High),
45 • 1.25(Very High)
• and 0.00(Extra High).

45

EARLY DESIGN MODEL : COCOMO-II

PRESENTATION TITLE

2. Development Flexibility : It reflects degree of flexibility in

development process.
Value for the scale factor is
5.07(Very Low),
4.05(Low),
3.04(Average),
2.03(High),
1.02(Very High)
and 0.00(Extra High).
46

46

23
 11/12/2024

EARLY DESIGN MODEL : COCOMO-II

PRESENTATION TITLE

3. Architecture Risk and Resolution : It represents degree of risk

analysis being carried out during course of project.
Value for the scale factor is
7.07(Very Low),
5.65(Low),
4.24(Average),
2.83(High),
1.41(Very High)
and 0.00(Extra High).

47

47

EARLY DESIGN MODEL : COCOMO-II

PRESENTATION TITLE

4. Team Cohesion : Reflects the team management skills of the

employees developing the project.
The value for scale factor is
5.48(Very Low),
4.38(Low),
3.29(Average),
2.19(High),
1.10(Very High)
and 0.00(Extra High).
48

48

24
 11/12/2024

EARLY DESIGN MODEL : COCOMO-II

PRESENTATION TITLE

Process maturity :Reflects process maturity of organization (SEI-CMM)

The value for scale factor is
7.80(Very Low),
6.24(Low),
4.68(Average),
3.12(High),
1.56(Very High)
and 0.00(Extra High).

49

49

EARLY DESIGN MODEL : COCOMO-II

PRESENTATION TITLE

• The value of B can be calculated as -

• B = 0.91 + 0.01 * (Sum of rating scaling factors for project)

• When all scaling factors of project are rated as extra high, best value
of B is obtained which is equal to 0.91.
• When all scaling factors are very low worst case values of B is
obtained as 1.23.
• Hence value of B varies from 0.91 to 1.23.

50

50

25
 11/12/2024

THANK YOU

51

26