INTERNATIONAL JOURNAL OF

PROJECT
MANAGEMENT
International Journal of Project Management 23 (2005) 297–307
www.elsevier.com/locate/ijproman

Cost estimation of a software product using

COCOMO II.2000 model – a case study
R. Dillibabu *, K. Krishnaiah
Department of Industrial Engineering, College of Engineering, Anna University, Guindy, Chennai 600025, Tamilnadu, India

Received 25 May 2004; received in revised form 25 June 2004; accepted 10 November 2004

Abstract

This paper discusses the estimation cost in terms of effort spent on a software product (project). COCOMO II.2000 Model has
been employed for estimating the effort of an embedded system project. This study has been made in a software services company,
which is involved in software development for an embedded system, client-server and Internet environment. The embedded systems
group is involved in developing software for major car manufacturers. This study is based on a sample of ten projects, of which eight
are development projects and two are porting projects. The actual effort on the projects has been collected from the metrics database
of the company. The Lines of code for the various projects have been enumerated using ‘‘Code Count’’ tool to achieve the logical
source lines of code for each project. The standard questionnaire has been used to collect the required data to arrive at the various
scale factors and effort multipliers. The calibration of the COCOMO (Constructive Cost Model) has been done through Natural
Log approach and curve fitting approach. Statistical tools like MS-EXCEL 2000, SPSSv10, Curve Expert 1.3 and data fit have been
used for this purpose. The study shows that the curve fitting approach yields better estimates of the model parameters. The calibra-
tion of COCOMO Model helps the company estimate the effort that is to be spent on the software development projects.
Ó 2004 Elsevier Ltd and IPMA. All rights reserved.

Keywords: Embedded systems; Calibration; Scale factors and effort multipliers

1. Introduction Model) and other initiatives, the software companies

According to Gartner Report [20], one of the main
challenges the Indian software industry is facing, espe-
cially in the aftermath of sept 11th is the intense down-
ward pressure on pricing and offshore billing rates for
low-end work (e.g., maintenance and coding) have
dropped from
$80 to $40 per hour to
$12 to $20
for smaller vendors. This has forced the companies to
look into their practice of estimating the cost for soft-
ware development. Until now, most companies have re-
lied on experience and ‘‘Price-to-win’’ strategies for
getting past competitors to win projects. With the emer-
gence of concepts like CMM (Capability Maturity
adopted formal techniques like Work Breakdown Struc-
ture (WBS) based cost estimation and parametric esti-
mation. One can never rely completely on experience-
based estimation in the software industry because of
the rapidly changing technology, which renders the
experience-based estimates ineffective. Further, price-
to-win strategy is not very favorable for any company
in the long run. Hence, there is a need to come up with
a suitable cost model to account for the effort spent on
developing software, right from requirements specifica-
tion to delivery and maintenance.
1.1. Software cost estimation and project management

*
Corresponding author. Tel.: +91 44 22203187. As software industry is very competitive, it is indis-
E-mail address: prdillibabu@rediffmail.com (R. Dillibabu). pensable, to establish the market with the right pricing.

0263-7863/$30.00 Ó 2004 Elsevier Ltd and IPMA. All rights reserved.

doi:10.1016/j.ijproman.2004.11.003
298 R. Dillibabu, K. Krishnaiah / International Journal of Project Management 23 (2005) 297–307

This makes software cost estimation as one of the very
important issues in the software development process.
For a software project, estimation comprises size, effort,
and schedule estimate. Size estimate is the measure of
the size of the final work product. It gives a measure
of the ground to be covered in order to achieve the
end result. Effort estimate is the effort, in person-
months, to produce the work product. Schedule estimate
is the calendar time it would take to accomplish the ef-
fort, taking into account the resource constraints of an
organization and the extent of parallelism that can be
derived. Eventually, both the customer and the organi-
sation are interested in the cost of the project in its dol-
lar value. Cost estimate [18] in dollar value is given by
Cost estimate ¼ No: of person months
 Cost per person-months of effortð$Þ:
The size, effort and schedule estimates get translated
into cost estimates. The purpose of going through the
size, effort and schedule estimates is to analyse factors
that contribute to the overall software development cost
in the final dollar value of the estimate.
1.2. Software cost estimation in embedded system
This paper discusses the software cost estimation in
terms of effort spent for the embedded systems group
of a company. Initially the existing system for software
cost estimation has been studied and the following
observations are made:
(i) The projects in the embedded system group are of
short duration.
(ii) The projects are up to 4K in size.
(iii) More number of completed projects is available for
the study.
(iv) The waterfall model has been used in these projects.
(v) The present effort (cost) estimation procedure lacks
scientific approach.
Based on these observations, the following objectives
are listed:
1. To study the COCOMO model and its increments.
2. To come up with suitable estimates for the scale driv-
ers and effort multipliers for the COCMO II.2000
model using data from industries.
3. To fit COCOMO II.2000 Model for practical data in
a software company.
4. To evaluate the model using ConteÕs criteria [5].
2. Literature
From literature it was found that the following pa-
pers are more relevant for software cost estimation.
‘‘Software cost estimation’’ by Danfeng Hang [6] and
‘‘Estimating software cost’’ by Lawrence H Putnam
and Ann Fitzsimmons [17]. The authors have reviewed
the literature and presented the major software cost esti-
mation models with their strengths and weaknesses. The
abstract from these two papers has been presented in
Table 1.
The following conclusions can be drawn from the re-
view of literature:
(i) None of the alternatives is better than the others in
all aspects.
(ii) The Parkinson and Price-to-win methods are not
widely accepted and do not produce satisfactory
cost estimates.
(iii) The strength and weakness of other techniques are
complementary (particularly the algorithmic model
versus expert judgment and top-down versus bot-
tom-up).
Since most of the researchers have used the algorith-
mic model, it has been selected for applying in this
study. Algorithmic models are the most formal amongst

Table 1
Abstract from review papers on software cost estimation models
Models and authors Strengths Weakness
1. Algorithmic Model, Putnam [23] Objective, repeatable, analogy formula, Subjective inputs, calibrated to past, not the future &
efficient, good for sensitivity analysis & assessment of exceptional circumstances
objectively calibrated to experience
2. Expert Judgment Delphi Techniques [12] Assessment of representativeness, No better than participants, biases & incomplete recall
interactions, exceptional circumstances
3. Analogy Norden, Peter [16] Based on representative experience Representativeness of experience
4. Parkinson, Parkinson [17] Correlates to some experience Reinforces poor practice
5. Price-to-win, Boehm [4] Often gets the contract Generally produces large overruns
6. Top-down, Albrecht and Gaffney [1] System level focus and efficient Less detailed basis. Fewer stables
7. Bottom-up, Albrecht and Gaffney [1] More detailed basis and more stable May overlook system level cost & requires more effort
8. Dynamic Modeling, Putnam [23] More detailed basis More time and data required for validating &
developing a model
 R. Dillibabu, K. Krishnaiah / International Journal of Project Management 23 (2005) 297–307
the various techniques. Fenton and Pfleeger [8] describes
two types of algorithmic model:
(a) Cost Models: These models provide direct estimates
of effort. Most cost models are based on empirical
data reflecting factors that contribute to the overall
cost. Often, they have a primary cost factor such as
size and a number of secondary adjustment factors
or cost drivers.
(b) Constraint Models: Constraint models demonstrate
the relationship over time between two or more
parameters of effort, duration or staffing levels.
The Rayleigh curve [14] is used as a constraint in
several commercial proprietary models like Put-
namÕs SLIM [17] and RCA Price-S [13]. Sufficient
material is not available for evaluating these
models.
2.1. Function points
(i) Function point [7] counts do not depend on the
source languages used. It can be obtained early in
the development cycle.
(ii) Function Point counts are oriented toward the cus-
tomerÕs view rather than the producerÕs view, this
emphasis the focus on value received, rather than
on the particular design that is employed.
(iii) Function point counts are not equally applicable to
all kinds of software. Although effective in business
environments, they have not enjoyed widespread
success in embedded systems or heavily computa-
tional applications.
3. Current estimation process
The Case Company has an elaborate metrics system
to capture data from the projects executed. This is
summarized in the form of Project ManagerÕs (PM)
workbook and Software Quality Analysts (SQA)
Workbook. The PM workbook concentrates on captur-
ing the various metrics for various milestones of the
projects, like project start date, end date, modules
included, estimated effort, actual effort, LOC, etc. The
details available in this report enable the reader to visu-
alize the project. The SQA Workbook contains details
regarding the quality related activities like number of
defects, severity of defect, defect injection, defect detec-
tion, etc.
The cost (effort) is estimated using combination of
function points and WBS. The process of estimation be-
gins once the Request For Purpose (RFP) and the scope
change are finalised. The estimation process uses two
models for the purpose of size estimation:
299
(i) System Software Sizing (SSS).
(ii) Business Application Software Sizing (BASS).
Depending on the nature of the project, i.e., a sys-
tems project or a business application project, the rel-
evant model is chosen for the purpose of estimation.
The function points are counted based on the stan-
dardized template for SSS/BASS. The factors that
influence the general system characteristics are consid-
ered to arrive at adjusted function points. This forms
the basis for arriving at the suitable effort estimate.
The process adopted is as proposed by the Interna-
tional Function Point Users Group (IFPUG [10])
for BASS and is a variant of the IFPUG process
for SSS. The WBS for the project is designed simul-
taneously once the RFPÕs and scope change docu-
ments are finalized. An estimate of effort based on
the WBS is made, which is then crosschecked with
the function point [7] based estimate. The estimation
group does this review, which also gives correction
factors to the assumptions made. The estimate is
finalized once the corrections are made to the
assumptions, in which a revised WBS is designed.
This revised WBS forms the basis for the scheduling
and phase wise breakdown of effort. These details
go into schedule document and the project proposal.
Once the proposal is accepted, the project managerÕs
workbook and the SQA workbook become active.
These are updated as and when each phase or module
is completed.
3.1. Weakness in the current estimation process
The WBS based approach towards effort estimation
has many drawbacks. Some of them are listed below:
(i) The WBS based estimate involves experience-based
estimates at the module/phase level. This estimate
can be biased. The nature of the bias may range
from Availability bias, Representative bias, Over-
confidence bias, Precedence bias, etc. [15].
(ii) Even though WBS biased estimate may be easier, it
is based on the assumption that the person doing
the estimate has had adequate domain experience
in the company and he/she will remain in the com-
pany forever. These assumptions can change at any
point of time.
Hence, there is a need for an estimating process,
which is predictable and not dependent on a single indi-
vidual. Further, it should be easy to use and reproduc-
ible. The COCOMO II.2000 model integrated with
function points will meet these requirements. Further,
this model can be calibrated for other development envi-
ronments in the company.
300 R. Dillibabu, K. Krishnaiah / International Journal of Project Management 23 (2005) 297–307
4. The COCOMO II.2000 model
The model is defined in terms of scale factors (SFj)
and effort multipliers (EMi), which are used for estimat-
ing effort (cost) that is required to develop software pro-
ject. The response obtained from Project Managers
through a standard questionnaire is made use of for esti-
mating the parameters of the model.
4.1. Overview of the COCOMO II.2000 model
The Constructive Cost Model (COCOMO II [2]) for
cost estimation is based on three major stages of any
development project. It acknowledges the fact that the
lines of code are impossible to know early in the devel-
opment cycle. In stage I, the project usually builds pro-
totypes to resolve high-risk issues that involve user
interfaces, software and system interaction, perfor-
mance, or technical maturity. In this stage, COCOMO
II estimates size using object points. This technique cap-
tures size in terms of high-level effort, generates such as
number of server data tables, number of client data ta-
bles and the percentage of screens and reports reused
from previous projects.
In stage 2, COCOMO II employs function points as a
size measure. Function Points estimate the functionality
captured in the requirements, thereby offering a richer
system description than object points. By stage 3, devel-
opment would have begun and more information would
be made available. Sizing is done in terms of lines of
code and many cost factors can be estimated with some
degree of comfort.
4.2. Sizing and counting source lines of code (SLOC)
A good size estimate is very important for any good
model estimation. COCOMO II model uses size data
that influences effort, i.e., new code and code that is re-
used and modified. All the projects analyzed in this
study are considered to have new code, since the projects
have very negligible or no reused code.
For new and reused code, a method is used to
make them equivalent so that they can be rolled up
into an aggregate size estimate. The baseline size in
COCOMO II is a count of new lines of code. The
adjustment takes into account the amount of design,
code and testing that has to be changed. It also con-
siders the understandability of the code and the pro-
grammer familiarity with the code. Code size is
expressed in thousands of source lines of code
(KSLOC). The goal is to measure the amount of intel-
lectual work that is put into program development.
Defining a line of code is difficult because of concep-
tual differences involved in accounting for executable
statements and data declarations in different lan-
guages. Difficulties arise while trying to define consis-
tent measures across different programming languages.
In COCOMO II, the logical source statement has been
chosen as standard line of code.
4.3. Effort estimation
The COCOMO II effort estimation model is shown in
Eq. (1). This model is used for both the Early Design
and Post-Architecture cost models to estimate effort
for the Waterfall lifecycle models. The inputs are the
Size of software development, a constant ÔAÕ, an expo-
nent ÔEÕ, and a number of values called effort multipliers
(EM). The number of effort multipliers depends on the
model
PMns ¼ A  SizeE  Pni¼1 EMi ;
where ns ¼ nominal schedule & A ¼ 2:94
ðfor COCOMO II:2000Þ: ð1Þ
The constant, ÔAÕ, approximates a productivity constant
in PM/KSLOC for the case where PM = Person Months
& E = 1.0 Productivity changes as ÔEÕ increases because
of the non-linear efforts on size. The constant ÔAÕ is ini-
tially set when the model is calibrated to the project
database reflecting a global productivity average. The
COCOMO model should be calibrated to local data,
which then reflects the local productivity and improves
the modelÕs accuracy.
4.4. Scale drivers
The scale drivers in the exponent, E, are used only at
the project level. The exponent E in Eq. (2) is an aggre-
gation of five scale drivers that account for the relative
economies or diseconomies of scale encountered for
software projects of different sizes. Software projects
generally exhibit diseconomies of scale because of two
main factors:
1. Growth of interpersonal communication overhead.
2. Growth of large-system integration overhead.
Eq. (2) defines the exponent, E, used in Eq. (1).
Each scale driver has a range of rating levels, from
very low to extra high. Each rating level has a weight.
The specific value of the weight is called a scale factor
(SF). The projectÕs scale factors, the selected scale dri-
ver ratings, are summed and used to determine a scale
exponent, E
X
E ¼ B þ 0:01  SFj ;
where B ¼ 0:91 ðfor COCOMO II:2000Þ: ð2Þ
 R. Dillibabu, K. Krishnaiah / International Journal of Project Management 23 (2005) 297–307
5. Methodology, fitting and calibration to the local
environment
5.1. Methodology
To achieve the objectives proposed, the following
methodology is proposed. The COCOMO II software
cost and schedule model will be used to estimate the effort
of projects. These estimates will then be compared with
actual values of effort. The results will be analysed to
determine the overall effectiveness of the model. To aid
in understanding the process, the step-by-step description
of the proposed calibration of the model is described.
5.2. Model calibration by natural log approach
COCOMO II will be calibrated using the COCOMO
Equation (Eq. (3)). The number of data points consid-
ered is ten. In this approach, only the multiplicative cal-
ibration variable ‘‘A’’ will be calibrated
PMns ¼ A  SizeE  Pni¼1 Emi
X
s
where E ¼ B þ 0:01  SFj :
j¼1
5.3. Analysis by curve fitting
Most software cost models can be abstracted into a
function of five basic parameters: size, process, person-
nel, environment and required quality [19]. The relation
among these parameters and the estimate effort can be
written as follows:
Effort ¼ ðPersonnelÞðEnvironmentÞðQualityÞSizeðprocessÞ :
Eq. (4) describes a power equation of the form
Y ¼ L  XM;
where Y = effort, X = size and L and M are constants.
When compared with the COCOMO II.2000 model
equation (Eq. (3)), we arrive at the following:
X X
L¼A EMi and M ¼ B þ 0:01  SFj : ð6Þ
By fitting a power curve between the Logical SLOC
and the Actual Effort, by using Eqs. (5) and (6), a bet-
ter calibrated COCOMO II model can be arrived at.
These values of ÔAÕ and ÔBÕ will help in analysing the
software development process in the company in a
better manner.
5.4. Validation of methodology
The validation of the above analysis is done using
ConteÕs Criteria [5], to determine the accuracy of the cal-
301
ibrated and uncalibrated model. This will be achieved
using Eqs. (7)–(11).
5.5. ConteÕs criteria
Here the Magnitude of Relative Error (MRE) is com-
puted (degree of estimating error in an individual esti-
mate) for each data point. This step is a precedent to
the next step and is also used to calculate PRED (e).
An MRE of 25% or less indicates satisfactory results
MRE ¼ jðEstimate  ActualÞ=Actualj: ð7Þ
Calculate the mean magnitude of relative error (average
degree of estimating error in a data set) for each data
set. According to Conte, the MMRE should also have
a value of 25% or less
MMRE ¼ ðRMREÞ=n; ð8Þ
where n = total number of estimates.
Calculate the root mean square (ModelÕs ability to
accurately forecast the individual actual effort) for each
data set. This step is a precedent to the next step only.
ð3Þ
Again, satisfactory results are indicated by a value of
25% or less
2 0:5
RMS ¼ ½1=n  RðEstimate  ActualÞ  : ð9Þ
Calculate the relative root mean square (modelÕs abil-
ity to accurately forecast the average actual effort) for
each data set. According to Conte, the RRMS should
have a value of 25% or less
RRMS ¼ RMS=½RðActualÞ=n: ð10Þ
A model should also be within 25% accuracy, 75% of the
time. To find this accuracy rate PRED (e), divide the to-
ð4Þ tal number of points within a data set that has an
MRE = 0.25 or less (represented by n). The equation
then is
ð5Þ
PRED ðeÞ ¼ k=n; ð11Þ
where e equals 0.25.
This methodology seems to be sound since it is based
on proven and accepted mathematical and statistical
analysis.
5.6. Fitting of the COCOMO model
The following steps are used in fitting the model to
the practical data applicable for a software service
company:
1. Mining and normalizing of project data from the pro-
ject database.
2. Counting the lines of code.
3. Arriving at values for scale factors and effort
multipliers.
302 R. Dillibabu, K. Krishnaiah / International Journal of Project Management 23 (2005) 297–307

4. Formulation of the uncalibrated COCOMO Effort Table 2

Equation. LOC count using ‘‘Code Count’’ tool in KLOC
5. Calibrating the values of multiplicative constants to Project name Project type KLOC
arrive at a customised calibrated COCOMO Effort PROJ1 Development 12.58
Equation. PROJ2 Development 13.324
6. Validation of the calibrated and the uncalibrated PROJ3 Development 5.286
PROJ4 Development 31.03
COCOMO equation. PROJ5 Development 10.902
PROJ6 Development 7.749
PROJ7 Development 5.58
5.7. Mining and normalizing of project data from the PROJ8 Development 7.223
project database PROJ9 Porting 33.568
PROJ10 Porting 38.861

Data mining from 10 Embedded System Projects (8

Development Projects and 2 Porting Projects) are under-
taken in two phases. In the first phase, preliminary data
from SQA workbook and PM workbook was explored
for each of the 10 projects and normalized. This pro-
vided an insight into various modules in a particular
project and details like the planned effort, actual effort,
size (module-wise). Other data about the projects are
collected into a Master Table Form. This master table
facilitates in finding data that is missed from the two
workbooks.
In the second phase, data for each of the project was
further explored and missing data was mined from the
various databases in the company, with the aid of this
master table. The data was normalized because of the
huge differences in configuration management across
various projects.
5.8. Counting the lines of code
The lines of code for all projects are available in the
metrics database in the company in the form of physical
LOC. It is found that the company has used a code
counting utility called ‘‘Measure’’. This utility followed
certain rules for counting, which are not in conformance
with the rules specified by the authors of the COCOMO
model.
For this purpose, the authors of the model have
also developed ‘‘Code Count’’, a utility for counting
the lines of code as per the requirements of the CO-
COMO suite of models. This utility has been down-
loaded [21] and applied to all the projects (Table 2).
Shows the LOC count.
5.9. Scale factors and effort multipliers
The scale factors and effort multiplier have to be ob-
tained for each of the 10 projects. Due to limitation of
resources, it has been decided to administer a question-
naire based on various criteria such as spreadsheet soft-
ware package.
The responses have been analyzed using spreadsheet
software and the results arrived at are listed in Tables
3–5.
5.10. Formulation of the COCOMO equation
Based on these responses, the original COCOMO II
equation (Eq. (1)) is transformed as shown below
Effort ¼ 49:12  Size1:08 : ð12Þ
The estimate of the effort for the 10 projects, based
on the above equation is shown in Table 6. It is seen that
the error between the estimated effort and actual effort is
very high for porting projects. This may introduce a very
serious error during the process of calibration. Hence,
the porting projects are not considered for the purpose
of calibration and calibration is done using eight devel-
opment projects only.
5.11. Calibration of the COCOMO equation
5.11.1. Natural log approach
The generic COCOMO II model discussed previously
has been used to estimate software development efforts
for a variety of project types. However, this model can
be tailored to a particular organisation or project do-
main to arrive at more accurate estimates. The COCO-
MO II Post-Architecture model is significantly more
accurate when calibrated to an organization. All that
needs to be done is to calibrate the constants, ÔAÕ and/
or ÔBÕ, in the effort estimation equation. The intent of
calibration is to take the productivity and activity distri-
butions of the local development environment into
account.
Local calibration improves predication accuracies
because:
 The rating scale is subjective, leading to inconsisten-
cies across different organizations.
 The lifecycle activities as covered by COCOMO II
may be slightly different from the lifecycle activities
as covered by the company.
The definitions as used by COCOMO II may differ
from those being used by the company. For, e.g., CO-
COMO II defines 1 person-month (PM) as 152 per-
 R. Dillibabu, K. Krishnaiah / International Journal of Project Management 23 (2005) 297–307 303

Table 3
Scale factors
Project name Project type PRECa FLEXb RESLc TEAMd PMATe
PROJ1 Development 2.48 4.05 5.65 3.29 1.56
PROJ2 Development 2.48 4.05 2.83 1.10 3.12
PROJ3 Development 2.48 4.05 5.65 3.29 1.56
PROJ4 Development 2.48 4.05 5.65 3.29 1.56
PROJ5 Development 2.48 4.05 5.65 3.29 1.56
PROJ6 Development 2.48 4.05 5.65 3.29 1.56
PROJ7 Development 2.48 4.05 5.65 3.29 1.56
PROJ8 Development 2.48 4.05 2.83 2.19 1.56
PROJ9 Porting 4.96 5.07 2.83 0.00 3.12
PROJ10 Porting 0.00 5.07 2.83 2.19 7.8
a
Precedentedness.
b
Development flexibility.
c
Architecture/risk resolution.
d
Team.
e
SW-CMM level 1–5.

Table 4
Effort multipliers (product and platform factors)
RELYa DATAb CPLXc RUSEd DOCUe TIMEf STORg PVOLh
0.82 0.90 0.87 1.00 1.00 1.11 1.00 0.87
1.00 0.90 0.87 1.00 1.00 1.11 1.05 0.87
0.82 0.90 0.87 1.00 1.00 1.11 1.00 0.87
0.82 0.90 0.87 1.00 1.00 1.11 1.00 0.87
0.82 0.90 0.87 1.00 1.00 1.11 1.00 0.87
0.82 0.90 0.87 1.00 1.00 1.11 1.00 0.87
0.82 0.90 0.87 1.00 1.00 1.11 1.00 0.87
1.00 1.00 0.87 1.15 1.00 1.63 1.00 0.87
0.92 0.90 1.74 1.24 1.00 1.63 1.00 0.87
0.82 0.90 1.74 0.95 1.00 1.00 1.00 0.87
a
Required software reliability.
b
Database size.
c
Product complexity.
d
Developed for reusability.
e
Documentation match to life-cycle needs.
f
Execution time constraint.
g
Major storage constraint.
h
Platform volatility.

son-hours. But the company evaluates one person-
month as 176 person-hours (8 h/day * 22 days/month).
The simplest way to account for these variations is to
calibrate the multiplicative constants, A and B.
First, the calibration is done using the Natural Log
Approach as described by Boehm et al. [4]. This is done
on the multiplicative constant ÔAÕ using data from com-
pleted projects. The authors of the model have recom-
mended at least 5 data point for the calibration of the
constant ÔAÕ where as here data from 8 projects have
been used (Table 7). Shows the outcome of this exercise.
The value of the multiplicative constant ÔAÕ is obtained
from Table 7. Its value is 2.79. The estimated effort for
the 8 projects is shown in Table 8.
5.11.2. Curve fitting approach
Another approach adopted for the calibration of the
constants is the curve fitting method. Power curves are
fitted with the help of the following statistical tools using
Eqs. (13) and (14):
 Excel 2000 from Microsoft.
 SPSS v10 from SPSS Corporation.
 Datafit 8.0 from Oakdale Engineering.
 Curve Expert 1.3.
It is found that the curve fit given by Excel and SPSS
explains the dependency of actual effort on the LOC to
the extent of 43%. The other statistical tools have given
304 R. Dillibabu, K. Krishnaiah / International Journal of Project Management 23 (2005) 297–307

Table 5
Effort multipliers (personnel and product factors)
ACAPa PCAPb PCONc APEXd LTEXe PLEXf TOOLg SITEh SCEDi
0.85 0.88 1.29 1.00 1.00 1.09 1.17 0.86 1.00
0.71 0.76 1.00 0.88 0.91 1.00 0.90 1.00 1.43
0.85 0.88 1.29 1.00 1.00 1.09 1.17 0.86 1.00
0.85 0.88 1.29 1.00 1.00 1.09 1.17 0.86 1.00
0.85 0.88 1.29 1.00 1.00 1.09 1.17 0.86 1.00
0.85 0.88 1.29 1.00 1.00 1.09 1.17 0.86 1.00
0.85 0.88 1.29 1.00 1.00 1.09 1.17 0.86 1.00
0.85 0.88 1.00 1.00 1.00 1.00 0.90 1.00 1.00
0.71 0.76 1.00 0.88 0.84 0.91 0.78 1.09 1.43
1.00 0.88 1.00 1.00 1.00 1.00 1.17 0.86 1.14
a
Analyst capability.
b
Programmer capability.
c
Personnel continuity.
d
Applications experience.
e
Language and tool experience.
f
Platform experience.
g
Use of software tools.
h
Multi-site development.
i
Required development schedule.

Table 6
Effort estimation with original COCOMO Equation
Project name Project type KLOC Actual effort Actual effort (PM) COCOMO effort (PM)
PROJ1 Development 12.58 249.56 11.34375 12.37
PROJ2 Development 13.324 324.03 14.728693 33.79
PROJ3 Development 5.286 144.50 6.5713636 13.12
PROJ4 Development 31.03 466.50 21.204545 5.11
PROJ5 Development 10.902 466.22 21.191761 31.07
PROJ6 Development 7.749 476.15 21.643239 10.69
PROJ7 Development 5.58 45.00 2.0454545 7.55
PROJ8 Development 7.223 77.94 3.5426136 5.18
PROJ9 Porting 33.568 762.73 34.669318 7.29
PROJ10 Porting 38.861 208.63 9.4829545 36.19

Table 7
Calibration using the natural log approach
Project name Project type PMActual KSLOC Unadjusted estimate Ln(PMActual) Ln(UE) Ln(Diff)
PROJ1 Development 249.56 12.58 757.37 5.52 6.63 1.11
PROJ2 Development 324.03 13.32 805.87 5.78 6.69 0.91
PROJ3 Development 144.57 5.286 296.84 4.97 5.70 0.72
PROJ4 Development 466.50 31.03 2008.61 6.15 7.61 1.46
PROJ5 Development 466.22 10.902 648.85 6.14 6.48 0.33
PROJ6 Development 476.15 7.749 448.72 6.17 6.11 0.06
PROJ7 Development 45.00 5.58 314.71 3.81 5.75 1.94
PROJ8 Development 77.94 7.223 415.91 4.36 6.03 1.67
Average = 1.03
Effort = 2.79

an equation with the coefficient of determination as
36%. And the error between the estimated effort and
the actual effort is same for both the equations. Table
9. Shows the resulted equations.
5.12. Validation of the calibrated models
Tables 10 and 11 shows the effort estimation using
the Eqs. (13) and (14). Studies have shown that soft-
ware development activity shows diseconomy of
scale, when a relation is considered between the soft-
ware size and development effort [19]. The equation
arrived at by the tools Data fit and Curve Expert
shows economies of scale, whereas the equation given
by Excel and SPSS shows diseconomies of scale.
Hence, the equation given by Excel and SPSS (Eq.
(12)) is taken as the outcome of the curve fitting
approach.
 R. Dillibabu, K. Krishnaiah / International Journal of Project Management 23 (2005) 297–307 305

Table 8
Effort estimation using the natural log approach
Project name Actual effort COCOMO effort MRE MMRE RMS RRMS Pred(0.25)
PROJ1 249.56 834.65 2.34 2.34 585.09 2.34 0
PROJ2 324.03 888.10 1.74 2.04 574.63 2.00 0
PROJ3 144.57 327.13 1.26 1.78 480.91 2.00 0
PROJ4 466.50 2213.57 3.75 2.27 967.74 3.27 0
PROJ5 466.22 715.05 0.53 1.92 872.70 2.64 0
PROJ6 476.15 494.51 0.04 1.61 796.70 2.25 0.10
PROJ7 45.00 346.82 6.71 2.34 746.37 2.41 0.10
PROJ8 77.94 458.35 4.88 2.66 711.00 2.53 0.10

Table 9 It is found that:

Equations from the curve fitting approach
Tool Equation Correlation coefficient (i) Of the three criteria, this model satisfies only one,
Microsoft Excel 2000 Y = 0.933x1.0197 R2 = 0.4307 (13) viz., the relative root mean square of the error
SPSSv10 (RRMS), which is less than 0.25.
Data fit Y = 3.534x0.543 R2 = 0.3600 (14) (ii) It fails on the other two criteria:
Curve expert
(a) Mean magnitude of relative error is greater
than 0.25.
Therefore, Eq. (13) is the final COCOMO II.2000
(b) The estimated effort is not within 25% of the
equation for the purpose of cost (effort) estimation in
actual estimates for atleast 75% of the time.
the company:
Pred(0.25) is less than 0.75.
Effort ¼ 0:93Size1:0197 ðReproducedÞ: ð13Þ This is to be expected for a company going in for such
This model has been validated using ConteÕs Criteria as a model-based approach for the first time. The project
described already. metrics data that has been presently is not sufficient
Outcome of model validation: for the purpose of effort estimation. Fine-tuning of the
project metrics programme should be carried out so as
(i) MMRE = 0.57, to make the COCOMO effort equation satisfy the Con-
(ii) RRMS = 0.20, teÕs criteria. This equation is recommended to the com-
(iii) Pred(0.25) = 0.38, pany for the purpose of effort estimation. Further
(iv) Pred(0.5) = 0.63. calibration needs to be done using more project data

Table 10
Effort estimation using the curve fitted equation (Eq. (13))
Project name Actual effort PM COCOMO effort MRE Eq. (13) MMRE RMS RRMS Pred(0.25) Pred(0.5)
PROJ1 11.34 12.37 0.09 0.09 1.03 0.09 0.13 0.13
PROJ2 14.73 13.12 0.11 0.10 0.41 0.03 0.30 0.30
PROJ3 6.57 5.11 0.22 0.14 1.18 0.11 0.38 0.38
PROJ4 21.20 31.07 0.47 0.22 3.92 0.29 0.38 0.50
PROJ5 21.19 10.69 0.50 0.28 1.19 0.08 0.38 0.63
PROJ6 21.64 7.55 0.65 0.34 6.84 0.42 0.38 0.63
PROJ7 2.05 5.18 1.53 0.51 5.15 0.36 0.38 0.63
PROJ8 3.54 7.03 0.98 0.57 3.58 0.20 0.38 0.63

Table 11
Effort estimation using the curve fitted equation (Eq. (14))
Project name Actual effort PM COCOMO effort MRE Eq. (14) MMRE RMS RRMS Pred(0.25) Pred(0.5)
PROJ1 11.34 14.01 0.23 0.23 2.67 0.24 0.13 0.13
PROJ2 14.73 14.45 0.02 0.13 1.69 0.13 0.30 0.30
PROJ3 6.57 8.74 0.33 0.19 2.63 0.24 0.38 0.38
PROJ4 21.20 22.88 0.08 0.17 3.12 0.23 0.38 0.50
PROJ5 21.19 12.96 0.39 0.21 0.89 0.06 0.38 0.63
PROJ6 21.64 10.76 0.50 0.26 5.17 0.32 0.38 0.63
PROJ7 2.05 8.64 3.22 0.68 2.30 0.16 0.38 0.63
PROJ8 3.54 10.36 1.92 0.84 0.30 0.03 0.38 0.63
306 R. Dillibabu, K. Krishnaiah / International Journal of Project Management 23 (2005) 297–307
and for various types of projects like porting projects,
maintenance projects, etc.
6. Conclusions and recommendations
6.1. Conclusions
The project data from the project database in the
company are studied and the COCOMO Model applied
to the past data. It is then calibrated using two
approaches:
 Natural log approach.
 Curve fitting approach.
Calibrating with these approaches and analyzing the
outcome has resulted the following conclusions:
1. The calibrated COCOMO Equation for which the
error is the least is obtained by the curve fitting
approach (Eq. (13)). The equation is
Effort ¼ 0:933Size1:0197 :
This equation has a coefficient of determination (R2) va-
lue of 43%.
2. The scale factors, effort multipliers and the multipli-
cative constants ÔAÕ and ÔBÕ, are estimated using curve
fitting approach, based on the average of the
responses from the Project Managers. These are:
X X
I SFj ¼ 16:27 I EMi ¼ 16:893
IA ¼ 0:056 IB ¼ 0:857:
3. The value of the multiplicative constant ÔAÕ arrived at
by Eq. (4) is 0.056, which is very low. This implies
that there might be some other factors that have an
impact on the actual software development effort.
This aspect requires more study.
4. The model has been validated using ConteÕs Criteria
and observed the following:
(a) Of the three criteria, this model satisfies only one
criterion, viz., the RRMS for which the error is less
than 0.25.
(b) It fails on the other two criteria.
This is to be expected for a company going in for such a
model-based approach for the first time. The project met-
rics data being collected presently is not sufficient for the
purpose of effort estimation. Fine-tuning of the project
metrics data should be carried out so as to make the CO-
COMO effort equation satisfy the ConteÕs Criteria.
6.2. Recommendations
The company is presently not using any model-
based approach for arriving at an effort estimate. It
is recommended that the company may apply the pop-
ular and well-known model, COCOMO II.2000, for
the purpose of effort estimation. It would be particu-
larly helpful to the company to have a better idea
about the actual effort spent in developing software.
This would, in turn, form the basis for further process
improvement initiatives in the organization. The fol-
lowing initiatives have been recommended to the
company:
1. Recording of the actual effort spent on the software
development should be done in a systematic manner,
where, even if a programmer works overtime and/or
weekends, it would be duly recorded.
2. The use of Code Count tool for the purpose of count-
ing the Logical SLOC is recommended if the organi-
zation uses COCOMO II.2000 model.
3. The scale factors and effort multipliers that form a
part of the COCOMO Equation should be used as
a benchmark or baseline for process improvement
initiatives.
4. The present method of arriving at Scale Factors and
Effort Multipliers through the process of question-
ð14Þ naire should be done away with and the rating scales
for the various scale and cost drivers must be equated
to the similar metrics that are in use. This will reduce
the bias in the evaluation of the various factors by the
project managers. For example, the existing processes
for employee evaluation can be linked to the rating
scale of Analyst Capability and ProgrammerÕs
Capability.
6.3. Scope for future work
1. This case study is based on a database of 10
projects only. Even though these projects represent
the nature of the software being developed, the accu-
racy of the multiplicative constant ÔAÕ can be
increased by considering all the projects in the com-
panyÕs database.
2. The factors, which affect the development effort and
cost apart from the factors listed by the COCOMO
model, can be studied and accounted for to arrive
at more accurate estimates.
References
[1] Albrecht AJ, Gaffney JE. Software function, source lines of codes,
and development effort prediction: a software science validation.
IEEE Trans Software Eng 1983;SE-9:639–48.
[2] Bernheisel Wayne A. Calibration and validation of the
COCOMO II cost/schedule estimating model to the space and
missile systems centre database. Master thesis, Ohio, Air Force
Institute of Technology; 1997.
 R. Dillibabu, K. Krishnaiah / International Journal of Project Management 23 (2005) 297–307
[3] Boehm BW, Abts C, Clark B, Devnani-Chulani S. COCOMO II
model definition manual, The University of Southern California;
1997.
[4] Boehm BW et al.. Software cost estimation using COCOMO II.
1st ed. Englewood Cliffs, NJ: Prentice-Hall; 2000.
[5] Conte SD, Dunsmore HE, Shen VY. Software engineering metrics
and models. California: Benjamin Cummings; 1986.
[6] Danfeng Hong. Software cost estimation. Department of Com-
puter Science, University of Calgary. Available from: http://
pages.cpsc.ucalgary.ca/~hangd/SENG/621/report.html.
[7] David Longstreet. Function Point Analysis Training Course;
2002. Available from: http://www.softwaremetrics.com/fpafund.
htm.
[8] Fenton NE, Pfleeger SL. Software metrics: a rigorous and
practical approach. PWS Publishing Company; 1997.
[9] Hughes RT. Expert judgement as an estimating method. Inform
Software Technol 1996;38(2):67–75.
[10] IFPUG Counting Practices Committee, Function Point Counting
Practices Manual. Release 4.1; 1999. Available from: http://
www.carfield.com.hk/document/software.engine/fpa.pdt.
[11] Norden Peter V. Curve fitting for a model of applied research and
development scheduling. IBM J Res Develop 1958;2(3).
307
[12] Parkinson GN. ParkinsonÕs law and other studies in administra-
tion. Boston: Haughton-Miffin; 1957.
[13] Park R. The Central Equations of the PRICE software cost
model. 4th COCOMO UsersÕ Group Meeting, November;
1988.
[14] Parr NA. An alternative to the raleigh curve model for software
development effort. IEEE Software Eng 1980(May).
[15] Peeters David, Dewey Gerorge. Reducing bias in software project
estimates. Crosstalk – J Defense Software Eng 2000.
[16] Putnam LH. A general empirical solution to the macro software
sizing and solution to the macro software sizing and estimating
problem. IEEE Trans Software Eng 1978;4(4):345–61.
[17] Putnam LH, Ann Fitzsimmons. Estimating software cost, Dat-
amation; 1979.
[18] Ramesh Gopalaswamy. Managing global software projects. 1st
ed. New Delhi: Tata McGraw Hill; 2001. p. 226-7.
[19] Royce W. Software project mangement: a unified frame-
work. Reading, MA: Addison Wesley; 1998.
[20] Terdiman R, Datar R, Chohan S. Emerging offshore trends: a
view from India. Markets – Gartner Report M-15-1087; 2001.
[21] Available from: http://sunset.usc.edu/reserch/CODECOUNT/
instructions.html.