COCOMO Model

• COCOMO Model
• Types of COCOMO
Model
• COCOMO – II
 Software Project
Planning
The Constructive Cost Model
(COCOMO)
Constructive Cost model
(COCOMO)

Basic Intermediate Detailed

Model proposed by
B. W.
Boehm’s
through his 3
 Software Project
Planning
COCOMO applied
to

Semidetach
Organi ed Embedde
c mode d
mode mode

4
In COCOMO, projects are categorized into three types:
• Organic
• Semidetached
• Embedded
1.Organic: A development project can be treated of the organic type,
if the project deals with developing a well-understood application
program, the size of the development team is reasonably small, and
the team members are experienced in developing similar methods of
projects.
Examples of this type of projects are simple business systems,
simple inventory management systems, and data processing
systems.
2. Semidetached: A development project can be treated with
semidetached type if the development consists of a mixture of
experienced and inexperienced staff. Team members may have finite
experience in related systems but may be unfamiliar with some
aspects of the order being developed.
Example of Semidetached system includes developing a new
operating system (OS), a Database Management System (DBMS),
and complex inventory management system.
3. Embedded: A development project is treated to be of an
embedded type, if the software being developed is strongly coupled
to complex hardware, or if the stringent regulations on the
operational method exist.
For Example: ATM, Air Traffic control.
For three product categories, Bohem provides a different set of
expression to predict effort (in a unit of person month)and
development time from the size of estimation in KLOC(Kilo Line of
code) efforts estimation takes into account the productivity loss due
to holidays, weekly off, coffee breaks, etc.
Software projects under COCOMO model strategies are classified into
3 categories, organic, semi-detached, and embedded.
Organic: A software project is said to be an organic type if-
Project is small and simple.
Project team is small with prior experience.
The problem is well understood and has been solved in the past.
Requirements of projects are not rigid, such a mode example is
payroll processing system.
Semi-Detached Mode: A software project is said to be a Semi-
Detached type if-
Project has complexity.
Project team requires more experience,better guidance and creativity.
The project has an intermediate size and has mixed rigid
requirements such a mode example is a transaction processing system
which has fixed requirements.
It also includes the elements of organic mode and embedded mode.
Few such projects are- Database Management System(DBMS), new
unknown operating system, difficult inventory management system.
Embedded Mode: A software project is said to be an Embedded
mode type if-
A software project has fixed requirements of resources .
Product is developed within very tight constraints.
A software project requiring the highest level of complexity, creativity,
and experience requirement fall under this category.
Such mode software requires a larger team size than the other two
models.
 Software Project
Mode Project size
Planning Nature of Project Innovation Deadline of Development
the
project Environment

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

Semi Typically Medium size project, Medium Medium Medium

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

Embedde Typically Large project, Real time Significant Tight Complex

d systems, Complex
over 300 interfaces, Very little Hardwar
previous experience. For e/
KLOC
example: ATMs, Air Traffic custome
Control r
Table 4: The etc.
comparison of three COCOMO Interface
modes s 11
 Software Project
Planning
Basic Model

Basic COCOMO model takes the

form
bb
E  ab (KLOC)
db
D  cb (E)
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).

12
 Software Project
Planning
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

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

Average staff E
size (SS)  D
Persons
When project size is known, the productivity level may be
calculated as:

Productivi KLOC
ty (P)  E KLOC / PM

14
 Software Project
Planning
Example: 4.5

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.

15
 Software Project
Solution
Planning
The basic COCOMO equation take the
form:
E  ab (KLOC)bb
db
D  cb (KLOC)
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

16
 Software Project
Planning
(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

17
 Software Project
Planning
Example: 4.6

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.

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

Henc E = 3.0(200)1.12 = 1133.12

e PM
D = 2.5(1133.12)0.35 = 29.3
PM

Average staff E
size (SS)  D
Persons
1133.12
 29.3  38.67Persons
19
 Software Project
Planning

Productivi KLOC  0.1765 KLOC /

ty  E 1133.12 PM
200

P  176 LOC /
PM

20
 Software Project
Planning
Intermediate Model
Cost drivers
(i) Product Attributes
 Required s/w reliability

 Size of application database

 Complexity of the product

(ii) Hardware Attributes

 Run time performance

constraints

 Memory constraints

 Virtual machine volatility

 Turnaround time
21
 Software Project
(iii
Planning
Personal Attributes
)
 Analyst capability

 Programmer capability

 Application experience

 Virtual m/c experience

Programming language

(iv experience Project Attributes

)
 Modern programming
practices
 Use of software tools
 Required development
Schedule
22
 Software Project
Planning
Multipliers of different cost
drivers
Cost Drivers RATINGS
Very low Low Nominal High Ver Extra
y
high high
Product Attributes

RELY 0.75 0.88 1.00 1.15 1.40 --

DATA -- 0.94 1.00 1.08 1.16 --

CPLX 0.70 0.85 1.00 1.15 1.30 1.65

Computer Attributes

TIME -- -- 1.00 1.11 1.30 1.66

STOR -- -- 1.00 1.06 1.21 1.56

VIRT -- 0.87 1.00 1.15 1.30 --

TURN -- 0.87 1.00 1.07 1.15 --

23
 Software Project
Cost Drivers Planning RATINGS
Very low Low Nominal High Ver Extra
y
high high
Personnel Attributes

ACAP 1.00 0.86 0.71

1.46 1.19 --

AEXP --
1.29 1.13 1.00 0.91 0.82
PCAP 0.86 0.70 --
1.42 1.17 1.00
VEXP 1.00 0.90 -- --
1.21 1.10
LEXP 1.14 1.07 1.00 0.95 -- --
Project Attributes

MODP --
1.24 1.10 1.00 0.91 0.82
TOOL 1.24 1.10 1.00 0.91 0.83 --
SCED
1.23 1.08 1.00 1.04 1.10 --
Table 5: Multiplier values for effort
calculations 24
Intermediate COCOMO
equations

EAF = It is an Effort Adjustment Factor, which is calculated by

multiplying the parameter values of different cost driver
parameters. For ideal, the value is 1.b
E  ai i
*
(KLOC)
c (E) d i EAF
i
D
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
25
Example: For a given project was estimated with a size of 300 KLOC.
Calculate the Effort, Scheduled time for development by considering the
developer having very high application experience and very low
experience in programming.
Solution –
Given the estimated size of the project is: 300 KLOC
Developer having very high application experience: 0.82 (as per above
table)
Developer having very low experience in programming: 1.14(as per
above table)
EAF = 0.82 *1.14 = 0.9348
Effort (E) = a(KLOC)b EAF = 3.0(300)1.12 *0.9348 = 1668.07 MM
Scheduled Time (D) = c(E)d = 2.5*(1668.07)0.35 = 33.55 Months(M)
Intermediate Model: Example

Project A is to be a 32,000 DSI semi-detached software. It

is in a mission critical area, so the reliability is high
(RELY=high=1.15).

Then we can estimate:

Effort = 1.15*3.0*(32)1.12 = 167 man-months
Schedule = 2.5*(167)0.35= 15 months
Productivity = (DSI / MM) = 32,000 DSI/167 MM
= 192 DSI/MM
Average Staffing = = 167 MM/15 months
MM/Schedule Months = 11 FSP
 Software Project
Planning
Detailed COCOMO Model
Detailed
COCOMO

Phase- Three level

Sensitive product
effort hierarchy
Cost multipliers
desig Modules
subsyste
driv n & m
System
er s
Manpower test
allocation level
for each phase
29
Detailed COCOMO Model
 Software Project
Planning
Development Phase
Plan / Requirements
EFFORT : 6% to 8%
DEVELOPMENT : 10% to
40%
TIME
% depend on mode &
size

31
 Software Project
Planning
Desig
n : 16% to
: 18%
Effor
19% to
t
Programmi
Tim
38%

ngeEffor : 48% to
t : 68%
Tim 24% to
Integration
e & Test
64%
Effort : 16%
to 34%

Time : 18%
to 34%

32
 Software Project
Principle of Planning
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 
 p E Dp
33
 Software Project
Lifecycle Phase Planning
Values p
of
Mode & Code Plan & System Detailed Module Integration
Size Requirements Design Code & Test & Test
Design
Organic
0.06 0.16 0.26 0.42 0.16
Small S≈2
Organic
0.06 0.16 0.24 0.38 0.22
medium
S≈32
Semidetach
0.07 0.17 0.25 0.33 0.25
ed medium
S≈32
Semidetach
0.07 0.17 0.24 0.31 0.28
ed large
S≈128
Embedded
0.08 0.18 0.25 0.26 0.31
large
S≈128
Embedde
d extra 0.08 0.18 0.24 0.24 0.34
Table
large 7 : Effort and schedule fractions occurring in each
phase of the
S≈320 lifecycl 34
 Software Project
Lifecycle Phase Planning
Values p
of
Mode & Code Plan & System Detailed Module Code Integration
Size Requirements Design & Test & Test
Design
Organic
0.10 0.19 0.24 0.39 0.18
Small S≈2
Organic
0.12 0.19 0.21 0.34 0.26
medium
S≈32
Semidetach
0.20 0.26 0.21 0.27 0.26
ed medium
S≈32
Semidetach
0.22 0.27 0.19 0.25 0.29
ed large
S≈128
Embedded
0.36 0.36 0.18 0.18 0.28
large
S≈128
Embedde
d extra 0.40 0.38 0.16 0.16 0.30
Table
large 7 : Effort and schedule fractions occurring in each
phase of the
S≈320 lifecycl 35
 Software Project
Planning
Distribution of software life cycle:

1. Requirement and product

design
(a)Plans and
requirements
(b)System design

2. Detailed Design
(a) Detailed design

3. Code & Unit test

(a) Module code & test

4. Integrate and Test

(a) Integrate & Test
36
 Software Project
Planning
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 ?

37
 Software Project
Solution
Planning
This is the case of embeddedmode and model is
intermediate
di
COCOMO.
Henc Ea i
e (KLOC)
= 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
38
 Software Project
Planning
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.

39
 Software Project
Example: 4.8 Planning
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
2. Cost & Schedule estimates for different 30
being different from 1.0)
 Software Project
Planning
Solution

Size of five modules

are:
Screen edit = 4 KLOC
Command language = 2 KLOC
interpreter File input and = 1 KLOC
output = 2 KLOC
Cursor = 3 KLOC
movement = 12 KLOC
Screen
movement
Total
45
 Software Project
Planning
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 46
 Software Project
Planning
(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
Development PM
time D = Ci(E)di
= 2.5(52.91)
(b) Using the following equations0.38
and= 11.29 M Table 7,
referring
phase wise cost and schedule estimates can be
calculated.
Ep  p E
Dp   pD 47
 Software Project
Planning
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
Detailed Design PM
Module Code & = 0.26 x 52.91 = 13.756
PM
Test Integration
= 0.42 x 52.91 = 22.222
& Test
Now Phase wise development time
PM
duration is
System Design == 0.19
0.16 xx 11.29
52.91== 8.465
Detailed Design 2.145
Pm M
Module Code & = 0.24 x 11.29 =
2.709 M
Test Integration
= 0.39 x 11.29 =
& Test 4.403 M 48
Software Project Estimation
Techniques
What are project estimation techniques?
An estimate is a rough calculation of something. For example, a project cost
estimate is a general idea of the price model for a project.
Estimation techniques are ways to create project estimates. When your
client or another project stakeholder asks you to estimate an aspect of the
project, these techniques help you come up with a realistic number to give
them.
Why are project estimates important?
Without accurate estimates, it’s impossible to plan your project. If you don’t
have an idea of how long the project will take or what resources you will
need, there is no way to ensure you’ll have the right people, materials, or
tools available when you need them.
What types of estimations take place during a project?
There are six key areas of a project that benefit from the use of project estimating
techniques:
1. Cost
Cost is one of the three main constraints in project management. If you don’t have enough
money to complete the project, it will fail. If you can accurately estimate project costs early
on, you can help set client expectations and ensure you have enough money to get the work
done.
Cost estimation involves predicting how much money you will need for the project as well as
when you will need the funds.
2. Time
Time is another of the three main project constraints. Being able to estimate both the overall
project duration and when individual tasks will take place is vital to project planning.
Estimating your project schedule enables you to arrange for people and resources to be
available when you need them. It also allows you to manage client expectations around when
they should receive key deliverables.
3.Scope
Scope is the third key project constraint. Project scope is all the work that must be
done to finish the project or deliver a product. By estimating how much work is
involved and exactly what tasks need to occur, you can ensure that you have the
right materials and expertise for the project.
The three main constraints are often referred to as three sides of a triangle. This is
because whatever changes are made to one constraint will inevitably impact the
other two. To accurately estimate the budget, you must know the scope and
schedule. If one of the three ends up being greater or less than you expected, it
will likely result in the other two estimates being off as well.
4. Risk

Project risk is an unexpected event that could impact your project, for better or
for worse. Estimating risk involves predicting what events may occur during the
project’s life cycle and how seriously they could impact the project.
By estimating what risks could impact your project and how they will affect it, you
are better able to plan for potential issues and create risk management plans.
5. Resources
Project resources are the assets you need to get the project done.
Resources can be tools, people, materials, subcontractors,
software, and more. Resource management helps you ensure you
have all the resources you need and use them as efficiently as
possible.
Without estimating what resources you will need, and when, it’s
challenging to plan how you will manage them. This can lead to
6. Quality

Quality focuses on how well the project deliverables are

completed. Products that have to meet demanding quality
regulations, such as environmental restrictions, may require more
money, time, and other resources than a product with lower-level
requirements.
Estimating the level of quality that the customer requires helps
you plan and estimate the other five aspects of your project.
All six project factors are interrelated, so predictions for one can
impact the estimates for the other five. For this reason, using the
same project estimate techniques in all six areas can improve
your accuracy.
1.Top-down estimate
A top-down estimating technique assigns an overall time for
the project and then breaks it down into discrete phases,
work, and tasks — usually based on your project’s
work breakdown structure (WBS).
If a client tells you the project has to be done within six
months, a top-down approach allows you to take that overall
timeline and estimate how much time you can take for each
activity within the project and still complete it on time.
2. Bottom-up estimate
A bottom-up estimate is the reverse of top-down. Using
this estimation technique, you start by estimating each
individual task or aspect of the project. Then you combine
all those separate estimates to build up the overall project
estimate.
Since each activity is being assessed individually, this type
of estimate tends to be more accurate than the top-down
approach. But it also takes more time.
3. Expert judgment
Expert judgment is one of the most popular estimation techniques, as
it tends to be quick and easy. This technique involves relying on the
experience and gut feel of experts to estimate projects.
It’s most useful when you’re planning a standard project that is similar
to projects your team has completed before. Expert judgment can be
used for creating top-down or bottom-up estimates.
Several experts on the proposed software development techniques
and the application domain are consulted. They each estimate the
project cost. These estimates are compared and discussed. The
estimation process iterates until an agreed estimate is reached.
4. Comparative or analogous estimation
Comparative estimation uses past project data combined with a top-
down approach to estimate project duration.
If the average completion time of similar projects was eight months,
you’d assume the current one will take eight months.
Then you can break those eight months down across tasks and
activities to get your lower-level work estimates.
Estimation by analogy :
This technique is applicable when other projects in the same
application domain have been completed. The cost of a new project is
estimated by analogy with these completed projects. Myers (Myers
1989) gives a very clear description of this approach.
Algorithmic cost modelling
A model based on historical cost information that relates some
software metric (usually its size) to the project cost is used. An
estimate is made of that metric and the model predicts the effort
required.
Parkinson’s Law :
 Parkinson’s Law states that, work expands to fill the time
available.
 The cost is determined by available resources rather
than by objective assessment.
 If the software has to be delivered in 12 months and 5
people are available, the effort required is estimated to
be 60 person-months.
According to Parkinson's Law,
• A person will spent all of the available time to complete a task
regardless of the tasks size.
• This tendency leads to inefficient use of time and resources and
affects project performance.
• Project managers can use Parkinson's Law to understand how
people work and to ensure productivity and efficiency.
• Project scheduling is the main driver to mitigate Parkinson's Law.
Pricing to win :
Price-to-Win is about choosing the most affordable alternative
that fulfills the customer need and that also will be successful
against competition.
The software cost is estimated to be whatever the customer has
available to spend on the project. The estimated effort depends on
the customer’s budget and not on the software functionality.
This approach may seem unethical and unbusinesslike.
● However, when detailed information is lacking it may be the only
appropriate strategy.
● The project cost is agreed on the basis of an outline proposal and
the development is constrained by that cost.
● A detailed specification may be negotiated or an evolutionary
approach used for system development.
Step 1: Gather market intelligence: Marketing personnel
identify competitor’s possible strategies.
Step 2: Then Determine requirements & features
Step 3: Sketch out Architecture Design
Step 5. Determine possible alternatives
Step 6: Cost Analysis & Estimation of Alternatives
Step 7: Select best alternative
Step 8: Establish price