International Journal of Scientific Engineering and Technology

Volume No.5 Issue No.1, pp: 10-13

ISSN:2277-1581
01 Jan.2016

Difficulties in Software Cost Estimation: A Survey

M.R.Raja Ramesh, Ch.Satyananda Reddy
Department of Computer Science and Systems Engineering, College of Engineering,
Andhra University, Visakhaptnam-530003, India.
Abstract: It is proved fact that the success of software project
depends on the cost estimation done at initial stages of software
development process. The project acquisition stage is the one
where the detail available to estimator is minimal. The
confusion of estimation arises in this stage. All other stages,
progressively, increase the detail and hence reduce uncertainty
in estimation. However, it is necessary to estimate cost of the
software to be produced in the early stages itself. This paper
describes different approaches for software cost estimation and
their problems and the focus is on what the things that made the
estimation is so hard.
Keywords: Software, Cost estimation, Effort estimation.
1. INTRODUCTION
Software cost estimating has been an important but difficult task
since the beginning of the computer era in the 1940s. As software
applications have grown in size and importance, the need for
accuracy in software cost estimating[11] has grown, too. In the
early days of software, computer programs were typically less
than 1000 machine instructions in size (or less than 30 function
points), required only one programmer to write, and seldom took
more than a month to complete. The entire development costs[5]
were often less than $5000. Although cost estimating was
difficult, the economic consequences of cost-estimating errors
were not very serious.
Today some large software systems exceed 25 million
source code statements (or more than 300,000 function points),
may require technical staffs of 1000 personnel or more, and may
take more than five calendar years to complete. The development
costs for such large software systems can exceed $500 million;
therefore, errors in cost estimation can be very serious indeed.
Even more serious, a significant percentage of large software
systems run late, exceed their budgets, or are canceled outright
due to severe underestimating during the requirements phase. In
fact, excessive optimism in software cost estimation is a major
source of overruns[5], failures, and litigation. Software is now the
driving force of modern business, government, and military
operations. This means that a typical Fortune 500 corporation or a
state government may produce hundreds of new applications and
modify hundreds of existing applications every year. As a result
of the host of software projects in the modern world, software
cost estimating is now a mainstream activity for every company
that builds software.
This paper is structured as follows: Section 2 describes brief
literature survey. Section 3 presents software cost estimation
methods along with their demerits. Section 4 describes problems
in software cost estimation and section 5 concludes the paper with
trends and future work.
doi : 10.17950/ijset/v5s1/102

2. BRIEF LITERATURE SURVEY

Accurate software cost estimates [11] are critical to both
developers and customers. They can be used for generating
request for proposals, contract negotiations, scheduling,
monitoring and control[7]. Underestimating the costs may result
in management approving proposed systems that then exceed
their budgets, with underdeveloped functions and poor quality,
and failure to complete on time. Overestimating may result in too
many resources committed to the project, or, during contract
bidding, result in not winning the contract, which can lead to loss
of jobs.
Accurate cost estimation is important because:
It can help to classify and prioritize development
projects with respect to an overall business plan.
It can be used to determine what resources to commit to
the project and how well these Resources will be used.
It can be used to assess the impact of changes and
support replanning.
Projects can be easier to manage and control when
resources are better matched to real needs.
Customers expect actual development costs to be in line
with estimated costs.
Software cost estimation involves the determination of
one or more of the following estimates:
Effort (usually in person-months)
Project duration (in calendar time)
Cost (in dollars)
Practitioners have struggled with three fundamental
issues:
Which software cost estimation model to use?
Which software size measurement to use lines of code
(LOC), function points (FP), or feature point?
What is a good estimate?
3. Cost Estimation Methods and Their Difficulties
3.1. Expert Judgment Method
Expert judgment techniques[1] involve consulting with software
cost estimation expert or a group of the experts to use their
experience and understanding of the proposed project to arrive at
an estimate of its cost.
The disadvantages include:
1. This method cannot be quantified.
2. It is hard to document the factors used by the experts or
experts-group.
3. Expert may be some biased, optimistic, and pessimistic,
even though they have been decreased by the group
consensus.
Page 10

International Journal of Scientific Engineering and Technology

Volume No.5 Issue No.1, pp: 10-13

ISSN:2277-1581
01 Jan.2016

4.

The expert judgment method always compliments the 1. It may overlook many of the system-level costs (integration,
other cost estimating methods such as algorithmic
configuration management, quality assurance, etc.)
method.
associated with software development.
2. It may be inaccurate because the necessary information may
not available in the early phase.
3.2. Estimating by Analogy
Estimating by analogy[2]means comparing the proposed project 3. It tends to be more time-consuming.
to previously completed similar project where the project 4. It may not be feasible when either time or personnel are
development information id known. Actual data from the
limited
completed projects are extrapolated to estimate the proposed
project. This method can be used either at system-level or at the 3.4. Algorithmic Methods
component-level.
The algorithmic method[5] is designed to provide some
Estimating by analogy is relatively straightforward[2]. Actually in mathematical equations to perform software estimation. These
some respects, it is a systematic form of expert judgment since mathematical equations are based on research and historical data
experts often search for analogous situations so as to inform their and use inputs such as Source Lines of Code (SLOC), number of
opinion.
functions to perform, and other cost drivers such as language,
However there are also some problems with this method,
design methodology, skill-levels, risk assessments, etc. The
1. Using this method, we have to determine how best to algorithmic methods have been largely studied and there are a lot
describe projects. The choice of variables must be of models have been developed, such as COCOMO models[3],
restricted to information that is available at the point that Putnam model, and function points based models.
the prediction required.
General disadvantages are:
2. Even once we have characterized the project, we have to 1.
It is unable to deal with exceptional conditions, such as
determine the similarity and how much confidence can exceptional personnel
in any software cost estimating
we place in the analogies.
exercises, exceptional teamwork, and an exceptional
match
3. We have to derive an estimate for the new project by between skill-levels and tasks.
using known effort values from the analogous projects. 2.
Poor sizing inputs and inaccurate cost driver rating will
Possibilities include means and weighted means which result in inaccurate estimation.
will give more influence to the closer analogies.
3.
Some experience and factors cannot be easily quantified.
3.3. Top-Down and Bottom-Up Methods
3.3.1 Top-Down Estimating Method
Top-down estimating method is also called Macro Model. Using
top-down estimating method[9], an overall cost estimation for the
project is derived from the global properties of the software
project, and then the project is partitioned into various low-level
components. The leading method using this approach is Putnam
model[3]. This method is more applicable to early cost estimation
when only global properties are known. In the early phase of the
software development, It is very useful because there are no
detailed information available.
The disadvantages are:
1. It often does not identify difficult low-level problems
that are likely to escalate costs and sometime tends to
overlook low-level components.
2. It provides no detailed basis for justifying decisions or
estimates.
Because it provides a global view of the software project, it
usually embodies some effective features such as cost-time trade
off capability that exists in Putnam model.
3.3.2 Bottom-up Estimating Method
Using bottom-up estimating method[9], the cost of each software
components is estimated and then combine the results to arrive at
an estimated cost of overall project. It aims at constructing the
estimate of a system from the knowledge accumulated about the
small software components and their interactions. The leading
method using this approach is COCOMO's detailed model.
The disadvantages are:
doi : 10.17950/ijset/v5s1/102

3.4.1 COCOMO Models

One very widely used algorithmic software cost model is the
Constructive Cost Model (COCOMO). The basic COCOMO
model[3] has a very simple form:
MAN-MONTHS = K1* (Thousands of Delivered Source
Instructions) K2
Where K1 and K2 are two parameters dependent on the
application and development environment.
Estimates from the basic COCOMO 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[5] of the development team, and the
software development environment. Some of these factors are:
1. Complexity of the software
2. Required reliability
3. Size of data base
4. Required efficiency
5. Analyst and programmer capability
6. Experience of team in the application area
7. Experience of team with the programming language and
computer
8. Use of tools and software engineering practices
Many of these factors affect the person months required by an
order of magnitude or more. COCOMO assumes that the system
and software requirements have already been defined, and that
these requirements are stable. This is often not the case.
COCOMO model is a regression model. It is based on the
analysis of 63 selected projects. The primary input is KDSI. The
problems are:

Page 11

International Journal of Scientific Engineering and Technology

Volume No.5 Issue No.1, pp: 10-13
1.

In early phase of system life-cycle, the size is estimated

with great uncertainty value. So, the accurate cost
estimate cannot be arrived at.
2. The cost estimation equation is derived from the analysis
of 63 selected projects. It usually has some problems
outside of its particular environment. For this reason, the
recalibration is necessary.
According to Kemerer's research, the average error for all
versions of the model is 601%. The detailed model and
Intermediate model seem not much better than basic model.
The first version of COCOMO model was originally developed in
1981. Now, it has been experiencing increasing difficulties in
estimating the cost of software developed to new life cycle
processes and capabilities including rapid-development process
model, reuse-driven approaches, object-oriented approaches and
software process maturity initiative.
For these reasons, the newest version, COCOMO 2.0, was
developed. The major new modeling capabilities of COCOMO
2.0 are a tailorable family of software size models, involving
object points, function points and source lines of code; nonlinear
models for software reuse and reengineering; an exponent-driver
approach for modeling relative software diseconomies of scale;
and several additions, deletions, and updates to previous
COCOMO effort-multiplier cost drivers. This new model is also
serving as a framework for an extensive current data collection
and analysis effort to further refine and calibrate the model's
estimation capabilities.

ISSN:2277-1581
01 Jan.2016

function points offer several significant advantages over SLOC

counts of size measurement.
The collection of function point data[10] has two primary
motivations. One is the desire by managers to monitor levels of
productivity. Another use of it is in the estimation of software
development cost.
Disadvantages are:
1. It needs subjective evaluations with a lot of judgment
involved.
2. Many effort and cost models are based on LOC, so
function points need to be converted.
3. Less research data is available on function points as
compared to LOC.
4. It is performed after creation of design specifications.
4. Problems in Software cost Estimation
There are different factors that make the cost estimation so
difficult. The problematic areas that effect the cost estimation are:
Software skills shortage and best use of existing skills.
Optimum use of COTS components.
Software measurement.
System of systems, in particular security issues.
Interoperability.
Requirements capture.
Obsolescence.
Software engineering

Software cost estimation is so hard because:

Disadvantages are:
Software really is much harder. Consider the number of
1. COCOMO model ignores requirements and all
orders of magnitude involved. Time scale 24x7 down to 100
documentation.
nanosecond clock cycles is a LOT of orders of magnitude:
2. It ignores customer skills, cooperation, knowledge and
too many to fully comprehend. Hence the inherent difficulty.
other parameters.
Hence the uncertainty.
3. It oversimplifies the impact of safety/security aspects.

Because you have potentially infinite variables to estimate

4. It ignores hardware issues
against and you have users that don't really know what they
5. It ignores personnel turnover levels
want (or can't accurately express what they want).
6. It is dependent on the amount of time spent in each

The problem is that customers don't know what they want".

phase.
Worse, they can't know until they start to work with the
solution technology which then changes the nature of the
3.4.2 Putnam model
problem.
Another popular software cost model is the Putnam model[4].

We predict the future by looking at the past. So I think there

The form of this model is:
1/3
4/3
are two main problems with estimation:
Technical constant C= size * B * T
4
3
If were asked to do something weve never done before,
Total Person Months B=1/T *(size/C)
we cant know how long itll take, because weve never
T= Required Development Time in years
done it before.
Size is estimated in LOC
If we dont keep a record of how long things took, even
when were asked to do something similar again, we
Disadvantage:
wont have the data upon which to estimate.
Problem with the PUTNAM model is that it is based on knowing,
or being able to estimate accurately[6], the size (in lines of code)
5. CONCLUSION
of the software to be developed. There is often great uncertainty
Even though Software Cost Estimation is a difficult task, it
in the software size. It may result in the inaccuracy of cost
estimation. According to Kemerer's research, the error percentage should be done at the early phase of a project development by
taking precautions like selecting appropriate method for cost
of SLIM, a Putnam model based method, is 772.87%.
estimation with good accuracy and history of that method.
Initially it should be applied on small projects and based on the
3.4.3 Function Point Analysis Based Methods
The function point measurement method [8]was developed by performance the same should be done on projects with more
Allan Albrecht at IBM and published in 1979. He believes complexity.
doi : 10.17950/ijset/v5s1/102

Page 12

International Journal of Scientific Engineering and Technology

Volume No.5 Issue No.1, pp: 10-13
6. REFERENCES
i. S.-W. Lin and V. M. Bier, A study of expert overconfidence,
Reliability Engineering & System Safety,vol. 93, no. 5, pp. 711-721, May
2008.
ii. Martin Shepperd and Chris Schofield, Estimating Software
Project Effort Using Analogies, IEEE TRANSACTIONS ON
SOFTWARE ENGINEERING, VOL. 23, NO. 12, NOVEMBER 1997.
iii. T.N.Sharma, Anil Bhardwaj, Anita Sharma ,A Comparative
study of COCOMO II and Putnam models of Software Cost Estimation,
International Journal of Scientific & Engineering Research, Volume 2,
Issue 11, November-2011 1 ISSN 2229-5518
iv. Anuj Khuttan1, Archana Singh,Proposing a New Estimation
Model Based On Putnam Model, International Journal of Science and
Research (IJSR) ISSN (Online): 2319-7064
v. Vahid Khatibi, Dayang N. A. Jawawi,
Software Cost
Estimation Methods: A Review, Volume 2 No. 1 ISSN 2079-8407 Journal
of Emerging Trends in Computing and Information Sciences.

doi : 10.17950/ijset/v5s1/102

ISSN:2277-1581
01 Jan.2016

vi. Jyoti G. Borade, Software Project Effort and Cost Estimation

Techniques,
Volume 3, Issue 8, August 2013 ISSN: 2277
128X ,International Journal of Advanced Research in Computer Science
and Software Engineering.
vii. Dr. Randall W. Jensen, Lawrence H. Putnam Sr., William
Roetzheim, Software Estimating Models: Three Viewpoints, Software
Engineering Technology, February 2006.
viii. Roberto Meli, Luca Santillo, FUNCTION POINT
ESTIMATION METHODS: A COMPARATIVE OVERVIEW, Data
Processing Organization, http://web.tin.it/dpo.
ix. M. Jrgensen (2004), Top-down and bottom-up expert
estimation of software development effort. Information and Software
Technology, vol. 46, no. 1,pp. 316.
x. Bundschuh M. - Function Point Prognosis - FESMA 98 Procs,
May, 1998
xi. Boehm B. W. Software Engineering Economics,Englewood
Cliffs, NJ, Prentice-Hall, 1981.

Page 13