The ability to accurately estimate the time and/or cost taken for a project to come
in to its successful conclusion is a serious problem for software engineers. The use
of a repeatable, clearly defined and well understood software development process
has, in recent years, shown itself to be the most effective method of gaining useful
historical data that can be used for statistical estimation. In particular, the act of
sampling more frequently, coupled with the loosening of constraints between parts
of a project, has allowed more accurate estimation and more rapid development
Popular methods for estimation in software engineering include:
 Analysis Effort method
 Evidence-based Scheduling Refinement of typical agile estimating techniques
using minimal measurement and total time accounting.
 Function Point Analysis
 Parametric Estimating
 PRICE Systems Founders of Commercial Parametric models that estimates the
scope, cost, effort and schedule for software projects.
 Proxy-based estimating (PROBE) (from the Personal Software Process)
 Program Evaluation and Review Technique (PERT)
 SEER-SEM Parametric Estimation of Effort, Schedule, Cost, Risk. Mimimum
time and staffing concepts based on Brooks's law

 The Planning Game (from Extreme Programming)
 Weighted Micro Function Points (WMFP)
 Wideband Delphi
 The Use Case Points method (UCP)
The development of the IBM OS/360 operating system over 30 years ago was a
monumental undertaking. That effort spawned many technical innovations, now
widely copied. In spite of technical successes, the OS/360 was a management
failure. "The product was late, it took more memory than planned, the costs were
several times the estimate, and it did not perform well until several releases after
the first". Dr. Brooks published many of his lessons learned from managing this
project in the book "The Mythical Man-Month: Essays on Software Engineering".
The book remains one of the best-regarded texts on software project management.
Today, situations similar to the OS/360 remain all too familiar.
There are several techniques for cost estimation, but the 2 basic approaches are
top-down and bottom-up. In the top-down approach, cost is derived from a
business analysis of the major project components. In the bottom-up approach, cost
is derived by accumulating estimates from the people responsible for various
The primary techniques for cost estimation are:
1. Ask an expert in the domain of interest
2. Analogy to other projects

3. "Price-to-Win" strategy
4. Resource availability
5. Parametric models
Overview of Terminology for Cost Estimating Techniques:
Terminology: Brief Definition:
Factor Technique
The factor technique is an extension of the unit
technique, in which one sums the product of
several quantities or components and adds these to
any components estimated directly
An index is a dimensionless number used to
indicate how a cost has changed over time relative
to a base year.
Linear Regression
A statistical technique used to estimate the
relationship between two variables.
Parametric Cost
The use of historical cost data and statistical
techniques to predict future costs
A cost estimating technique that uses the
relationship between capacity and cost. It is
frequently used for estimating the cost of building
industrial plants and equipment.
Unit Technique
Cost estimating technique that involves using a per
unit factor that can be estimated effectively. Such
factors, when multiplied by the appropriate unit,
give a total estimate of cost savings, or revenue.


Techniques, methods, and tools for planning, estimating, and monitoring the cost,
budget, or schedule of a software project. Included in this discussion are Function
Point and Lines-of-Code cost estimation techniques.
 Best Practices
Best Practices for Cost Estimation and related areas
 Case Studies
Case Studies for Software Cost and Schedule Estimation
 Education and Training
Courses, training products and other resources for learning about cost
 Experts
Researchers, educators and experts in cost estimation.
 Literature
A collection of electronic and hardcopy articles, white papers, books,
conference proceedings, journals and technical reports on cost estimation.
 Programs and Organizations
Groups, programs and organizations that focus on cost estimation.
 Related Resources
Web sites related to cost estimation.

 Service Providers/Consultants
Companies, organizations and individuals that provide services related to
cost estimation.
 Standards, Policies, and Procedures
Standards, Policies, and Procedures for cost estimating.
 Tools
Software tools, spreadsheets and utilities that support cost estimation.
 Cost Estimating Techniques
Resources that describe or compare various techniques for performing cost
estimates such as parametric modeling, analogy estimating, and expert
 Earned Value
Earned Value is a management technique used extensively in the
management of Software Intensive Systems that relates resource planning to
schedules and to technical cost and schedule requirements. All work is
planned, budgeted, and scheduled in time-phased increments constituting a
cost and schedule measurement baseline. See the DACS Gold Practice
"http://www.goldpractices.com/practices/tev/index.php" Track Earned

Software Size Estimation and Measurement
This category includes tools and methods for estimating and measuring software
size, including function points, lines of code, and object points. Because of the
large amount of resources for function points, they compose a separate topic area
within software size estimation and measurement. The other topic area, Software
Sizing - General, contains information not unique to function points and either
addresses other sizing methods, such as lines of code or object points, or general
information about multiple sizing methods including function points.
"Cost does not scale linearly with size", is perhaps the most important principle in
estimation. Barry Boehm used a wide range of project data and came up the
following relationship of effort versus size:
effort = C x size

This is known as the Constructive Cost Model (COCOMO). C and M are always
greater than 1, but their exact values vary depending upon the organization and
type of project. Typical values for real-time projects utilizing very best practices
are: C=3.6, M=1.2. Poor software practices can push the value of M above 1.5. A
bit of plotting for various values of M should quickly reveal the value of utilizing
best practices! Other factors that can influence M are: application experience,
leadership capability, new environment and tools, requirements uncertainty,
software reuse.

One fall out of the COCOMO model is that it is more cost effective to partition a
project into several independent sub-projects - each with its own autonomous team.
This "cheats" the exponential term in the COCOMO model. Partition strategies
include domain analysis and partition by CPUs.
Cost estimation is an iterative process. Precisely predicting software cost on large
projects is an intractable problem - even within the most stable environments and
mature organizations. Thus, software estimation needs to be performed several
times as a project matures. Each rework of the estimate should be more accurate
because more information is known.
Software Development efforts estimation is the process of predicting the most
realistic use of effort required to develop or maintain software based on
incomplete, uncertain and/or noisy input. Effort estimates may be used as input to
project plans, iteration plans, budgets, investment analyses, pricing processes and
bidding rounds.
Published surveys on estimation practice suggest that expert estimation is the
dominant strategy when estimating software development effort.

Typically, effort estimates are over-optimistic and there is a strong over-confidence
in their accuracy. The mean effort overrun seems to be about 30% and not
decreasing over time. For a review of effort estimation error surveys, see.

However, the measurement of estimation error is not unproblematic, see Assessing
and interpreting the accuracy of effort estimates. The strong over-confidence in the
accuracy of the effort estimates is illustrated by the finding that, on average, if a
software professional is 90% confident or “almost sure” to include the actual effort

in a minimum-maximum interval, the observed frequency of including the actual
effort is only 60-70%.
Currently the term “effort estimate” is used to denote as different concepts as most
likely use of effort (modal value), the effort that corresponds to a probability of
50% of not exceeding (median), the planned effort, the budgeted effort or the effort
used to propose a bid or price to the client. This is believed to be unfortunate,
because communication problems may occur and because the concepts serve
different goals .Software researchers and practitioners have been addressing the
problems of effort estimation for software development projects since at least the
1960s; see, e.g., work by Farr and Nelson.
Most of the research has focused on the construction of formal software effort
estimation models. The early models were typically based on regression analysis or
mathematically derived from theories from other domains. Since then a high
number of model building approaches have been evaluated, such as approaches
founded on case-based reasoning, classification and regression trees, simulation,
neural networks, Bayesian statistics, lexical analysis of requirement specifications,
genetic programming, linear programming, economic production models, soft
computing, fuzzy logic modeling, statistical bootstrapping, and combinations of
two or more of these models. The perhaps most common estimation products
today, e.g., the formal estimation models COCOMO and SLIM have their basis in
estimation research conducted in the 1970s and 1980s. The estimation approaches
based on functionality-based size measures, e.g., function points, is also based on
research conducted in the 1970s and 1980s, but are re-appearing with modified size
measures under different labels, such as “use case points” in the 1990s and
COSMIC in the 2000s.

Estimation approaches
There are many ways of categorizing estimation approaches, see for example.

The top level categories are the following:
 Expert estimation: The quantification step, i.e., the step where the estimate is
produced based on judgmental processes.
 Formal estimation model: The quantification step is based on mechanical
processes, e.g., the use of a formula derived from historical data.
 Combination-based estimation: The quantification step is based on a
judgmental or mechanical combination of estimates from different sources.
Selection of estimation approach
The evidence on differences in estimation accuracy of different estimation
approaches and models suggest that there is no “best approach” and that the
relative accuracy of one approach or model in comparison to another depends
strongly on the context. This implies that different organizations benefit from
different estimation approaches. Findings, summarized in, that may support the
selection of estimation approach based on the expected accuracy of an approach
 Expert estimation is on average at least as accurate as model-based effort
estimation. In particular, situations with unstable relationships and information
of high importance not included in the model may suggest use of expert
estimation. This assumes, of course, that experts with relevant experience are
 Formal estimation models not tailored to a particular organization’s own
context, may be very inaccurate. Use of own historical data is consequently

crucial if one cannot be sure that the estimation model’s core relationships (e.g.,
formula parameters) are based on similar project contexts.
 Formal estimation models may be particularly useful in situations where the
model is tailored to the organization’s context (either through use of own
historical data or that the model is derived from similar projects and contexts),
and/or it is likely that the experts’ estimates will be subject to a strong degree of
wishful thinking.
The most robust finding, in many forecasting domains, is that combination of
estimates from independent sources, preferable applying different approaches, will
on average improve the estimation accuracy
In addition, other factors such as ease of understanding and communicating the
results of an approach, ease of use of an approach, cost of introduction of an
approach should be considered in a selection process.
Assessing and interpreting the accuracy of effort estimates
The most common measures of the average estimation accuracy is the MMRE
(Mean Magnitude of Relative Error), where MRE is defined as:
MRE = |actual effort − estimated effort| / |actual effort|
This measure has been criticized and there are several alternative measures, such as
more symmetric measures, Weighted Mean of Quartiles of relative errors (WMQ)
and Mean Variation from Estimate (MVFE). A high estimation error cannot
automatically be interpreted as an indicator of low estimation ability. Alternative,
competing or complementing, reasons include low cost control of project, high
complexity of development work, and more delivered functionality than originally

estimated. A framework for improved use and interpretation of estimation error
measurement is included in.
Psychological issues related to effort estimation
There are many psychological factors potentially explaining the strong tendency
towards over-optimistic effort estimates that need to be dealt with to increase
accuracy of effort estimates. These factors are essential even when using formal
estimation models, because much of the input to these models is judgment-based.
Factors that have been demonstrated to be important are: Wishful thinking,
anchoring, planning fallacy and cognitive dissonance. It's easy to estimate what
you know.
 It's hard to estimate what you know you don't know.
 It's very hard to estimate things that you don't know you don't know.



The human factor is the dominant parameter in cost estimation. Cost can be
driven down substantially by utilizing quality analysts and programmers.
Based up his parametric studies of 63 projects at TRW, Boehm was able to
obtain a quantitative advantage for utilizing quality analysts and
programmers: having a very low skill level among analysts or programmers
will cost twice as much as having a very high skill level. If both analysts and
programmer have a very low skill level, costs can quadruple. (Hint: training
is good.)
Other factors that have a large cost impact are: required reliability, and
complexity. Stringent reliability requirements can double costs as can high
complexity. If both high complexity and reliability are required costs can



www. thedacs.com

Sign up to vote on this title
UsefulNot useful