Chapter 3

Software Effort Estimation

Software Effort Estimation

In software engineering effort is used to denote measure of use of workforce
and is defined as total time that takes members of a development team to
perform a given task. It is usually expressed in units such as man-day, man-
month, man-year. This value is important as it serves as basis for estimating
other values relevant for software projects, like cost or total time required to
produce a software product. Software Development effort estimation is
the process of predicting the most realistic amount of effort (expressed in
terms of person-hours) required to develop or maintain software based on
incomplete, uncertain and noisy input. Effort estimates may be used as input
to project plans, iteration plans, budgets, and investment analyses, pricing
processes and bidding rounds. Estimation is based on
 Past Data/Past Experience
 Available Documents/Knowledge
 Assumptions
 Identified Risks

Need for Software Effort Estimation

Effort estimation is essential for many people and different departments in
an organization. Reasons for effort estimation vary, some of the most
frequent being:
 Project approval: There must be a decision on project launching on the
part of an organization, preceded by effort estimation required for
successful completion of the project.
 Project management: In order to plan a project and inform the project
owners about deadlines and milestones you have to know how much
effort the job requires.
  Pricing Product: Usually, software development is priced based on the
person days multiplied by a daily person day rate. Without effort
estimation pricing is impossible.
 Understanding by the development team members: In order that
development team could perform efficiently, it is necessary for its
members to understand their individual roles as well as overall
activities of the team as a whole.

Software Estimation Process

A software estimation process that is integrated with the software
development process can help projects establish realistic and credible plans
to implement the project requirements and satisfy commitments. Typically,
an estimate should be produced using the process depicted in figure below:
 Establish Estimate Scope: Define and document estimate
expectations. When all participants understand the scope and purpose
of the estimate, misunderstandings among the project group and
contradictory assumptions about what is expected becomes clear.
 Establish Ground Rules and Assumptions: If detailed functionality
is not known, ground rules and assumptions should clearly state what
is and isn’t included in the estimate. Issues of COTS, reuse, and other
assumptions should be documented as well.
 Collect Data: Certain core information must be obtained in order to
ensure a consistent estimate. Not all data will come from one source
and it will not all be available at the same time, so a comprehensive
data collection form will aid your efforts.
 Size Software: Size is generally the most significant (but certainly not
the only) cost and schedule driver. Overall scope of a software project
is defined by identifying not only the amount of new software that
must be developed, but also must include the amount of preexisting,
 COTS, and other software that will be integrated into the new
system. Product size is generally be expressed as source lines of code
(SLOC) or function points,
 Prepare Baseline Estimates: To prepare the baseline estimate there
are various approaches that can be used, including guessing (which is
not recommended), using existing productivity data exclusively (also
not recommended), the bottom-up approach, expert judgment, and
cost models.
 Quantify Risks & Risk Analysis: Risk is characterized by a loss of
time, or quality, money, control, understanding, and so on. The loss
associated with a risk is called the risk impact. For each risk, we must
determine what we can do to minimize or avoid the impact of the
event. Risk control involves a set of actions taken to reduce or
eliminate a risk.
 Review, verify, and Validate Estimate: There are many ways to
validate an estimate. Both the process used to build the estimate and
the estimate itself must be evaluated. Ideally, the validation should be
performed by someone who was not involved in generating the
estimate itself, who can view it objectively. When reviewing an
estimate you must assess the assumptions made during the estimation
process. Make sure that the adopted ground rules are consistently
applied throughout the estimate.
 Document Estimate and Lesson and Learned: Each time you
complete an estimate, you should document the pertinent information
that constitutes the estimate and record the lessons you learned. By
doing so, you will have evidence that your process was valid and that
you generated the estimate in good faith.

Software Estimation Techniques

There are many ways of categorizing estimation approaches. The top level
categories are the following:
 Expert estimation: In this technique the estimate is produced based
on judgmental processes. WBS-based bottom-up estimation, Delphi
technique etc. lies in this category.
 Formal estimation model: In this technique estimation is based on
the use of a formula derived from historical data. Analogy based
estimation, parametric models, size-based estimation falls in this
category.
 Combination-based estimation: in this technique estimation is
based on combination of judgmental and formal estimates from
different sources.

Expert Judgment Based Estimation

Expert judgment techniques 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. Expert judgment
has been considered particularly useful in
 Areas where empirical data is not easily available, and
 When estimating complex, ill defined or poorly understood problems

There are expert judgment based estimation techniques. Among them, a

group consensus technique, Delphi technique, is the best way to be used. To
provide a sufficiently broad communication for the experts to exchange the
volume of information necessary to calibrate their estimates with other
experts, a wideband Delphi technique is introduced. The estimating steps
using this method:
1. Coordinator presents each expert with a specification and an
estimation form.
 2. Coordinator calls a group meeting in which the experts discuss
estimation issues with the coordinator and each other.
3. Experts fill out forms anonymously
4. Coordinator prepares and distributes a summary of the estimation on
an iteration form.
5. Coordinator calls a group meeting, specially focusing on having the
experts discuss points where their estimates varied widely.
6. Experts fill out forms, again anonymously, and steps 4 and 6 are
iterated for as many rounds as appropriate.

LOC Based Software Effort Estimation

Lines of code (LOC), is a software metric used to measure the size of
a computer program by counting the number of lines in the text of the
program's source code. LOC is typically used to predict the amount of effort
that will be required to develop a program, as well as to
estimate programming productivity once the software is produced. There are
many effort estimation methods based on LOC. One of the widely used
model is Putnam estimation model, given below
S= C*K1/3*td 4/3
Where
S= software size in LOC
C= Parameter dependent on the development environment
K=Total effort for the overall project in person-years
td=Delivery time constraint in years
Rearranging above equation we get

[ ]
3
S
C∗t 4 /3
Effort (k)= d

C is determined on the basis of historical data of the past projects. Rating:

C=2,000 (poor), C=8000 (good) C=12,000 (excellent).
In this model the relationship between size and effort is non-linear. The
Putnam model is highly sensitive to delivery time. According to
Putnam model, relatively small extensions in the delivery schedule can result
in substantial savings of effort.

One significant problem with the PUTNAM model is that it is based on

knowing, or being able to estimate accurately, the size (in lines of code) of
the software to be developed. There is often great uncertainty in the
software size. It may result in the inaccuracy of effort estimation.

Function Point Based Software Effort Estimation

The Function Point is another method of quantifying the size and complexity
of a software system in terms of the functions that the system delivers to the
user.
Function points are computed by completing the table shown below:

Once these data have been collected, a complexity value is associated with
each count. Organizations that use function point methods develop criteria
for determining whether a particular entry is simple, average, or complex.
Then,to compute function points (FP), the following relationship is used:
The Fi (i = 1 to 14) are "complexity adjustment values" based on responses
to 14 different questions.

The advantages of function point analysis based model are:

1. Function points can be estimated from requirements specifications or
design specifications, thus making it possible to estimate development
cost in the early phases of development.
2. Function points are independent of the language, tools, or
methodologies used for implementation.
3. non-technical users have a better understanding of what function
points are measuring since function points are based on the system
user's external view of the system

Object Point Software Effort Estimation

Object points are an approach used in software development estimation.
Object points are a way of estimating effort size, similar to LOC or Function
Point. They are not necessarily related to objects in Object Oriented
Programming, the objects refer to screens, reports, and modules of the
language. Each object instance (e.g., a screen or report) is classified into
one of three complexity levels (i.e., simple, medium, or difficult). Once
complexity is determined, the number of screens, reports, and components
are weighted according to the table shown below. The object point count is
then determined by multiplying the original number of object instances by
the weighting factor and summing to obtain a total object point count.
When component-based development or general software reuse is to be
applied, the percent of reuse (%reuse) is estimated and the object point
count is adjusted as follows:
NOP = (object points) × [(100 - %reuse)/100]
Where, NOP is new object point

To derive an estimate of effort based on the computed NOP value, a

“productivity rate” must be derived. The following table presents the
productivity rate for different levels of developer experience and
development environment maturity.

Fig: Productivity rates for object points

Once the productivity rate has been determined, an estimate of project effort
can be derived as
estimated effort = NOP/PROD

COCOMO cost Estimation Method

The Constructive Cost Model (COCOMO) is a procedural software cost
model. The model parameters are derived from fitting a regression formula
using data from historical projects (61 projects for COCOMO I and 163
projects for COCOMO II).

Basic COCOMO computes software development effort (and cost) as a

function of program size. Program size is expressed in estimated thousands
of source lines of code (KLOC). COCOMO applies to three classes of software
projects:
 Organic projects - "small" teams with "good" experience working
with "less than rigid" requirements
 Semi-detached projects - "medium" teams with mixed experience
working with a mix of rigid and less than rigid requirements
 Embedded projects - developed within a set of "tight" constraints. It
is also combination of organic and semi-detached projects.(hardware,
software, operational, ...)
The basic COCOMO equations take the form
Effort Applied (E) = ab(KLOC)bb [effort in person-months]
Development Time (D) = cb(Effort Applied)db [in months]
Where, KLOC is the estimated number of delivered lines (expressed in
thousands) of code for project. The coefficients ab, bb, cb and db coefficients,
which are given in the following table:

Software
ab b b cb db
project

2. 1.0 2. 0.3
Organic
4 5 5 8

Semi- 3. 1.1 2. 0.3

detached 0 2 5 5

3. 1.2 2. 0.3
Embedded
6 0 5 2

Basic COCOMO is good for quick estimate of software costs. However it does
not account for differences in hardware constraints, personnel quality and
experience, use of modern tools and techniques, and so on. Intermediate
COCOMO computes software development effort as function of program size
and a set of cost drivers that include subjective assessment of product,
hardware, personnel and project attributes. The Intermediate Cocomo
formula now takes the form:
E=ai(KLoC)(bi)(EAF)
Where E is the effort applied in person-months, KLoC is the estimated
number of thousands of delivered lines of code for the project, and EAF is
the factor calculated from product, hardware, personnel and project.