The document discusses methods for estimating the effort required for software tasks and projects. It describes traditional methods like estimating based on lines of code or function points. It provides details on estimating the life cycle based on the development stage and calculating lines of code through direct estimation or function point analysis with backfiring to convert to lines of code. Factors and tables are given for estimating effort based on lines of code and programming languages.

1. Software Task Estimation
Copy Number _____
Copyright © All Rights Reserved. Page 1

2. Document Control
Change Record
Date Author Version Change Reference
7th June 2010 Venkat Alagarsamy Draft No previous document
Reviewers
Name Position
Distribution
Copy No. Name Location
1 Library Master
2
3
4
Connect
Type Location
Linkedin https://www.linkedin.com/in/venkatalagarsamy
Scribd http://www.scribd.com/VenkatAlagarsamy
Slideshare http://www.slideshare.net/VenkatAlagarsamy
Blog http://venkatalagarsamy.blogspot.in/
Facebook https://www.facebook.com/Venkatachalapathi.alagarsamy
Copyright © All Rights Reserved. Page 2

3. Contents
Document Control ............................................................................................................. 2
Overview ............................................................................................................................ 4
Traditional Methods ................................................................................................... 4
Estimating Life Cycle.................................................................................................. 4
Estimating Program Volume ..................................................................................... 4
How to estimate the project based on KSLOC? ............................................................... 4
How to calculate KSOLC? ................................................................................................ 5
Copyright © All Rights Reserved. Page 3

4. Overview
Though everyone has a favourite theory as to why software failures occur. In my view projects are failed because
poor cost and incorrect estimates than by technical, political, or team problems. Software cost estimation is not an
art. It is a science. Only few organizations and individuals understand this science.
It is possible to accurately and consistently predict development life cycle costs and schedules for a wide range of
projects. Using this concept, to estimate the cost, the only tool required is spredsheet.
Traditional Methods
The traditional methods that are used to estimate the size and/or volume of the program/task are:
 Code size in kilo bytes (Program Volume)
 Function points
Estimating Life Cycle
Accuracy of cost estimates varies based on the software development stage. Early uncertainty is largely based on
variances in the input parameters to the estimate. Later uncertainty in the estimate is based on the variance to the
estimating models. Initially, at the concept stage, you may be presented with high-level definition of the project.
Though the requirements may not yet be fully understood, the general purpose of the new software can be
recognized. At this point estimates with an accuracy of plus or minus 50% are typical for an experienced estimator
using informal techniques such as historical comparisons and/or group consensus.
The key to accuracy lies in making periodic reestimates through out the project life cycle, there by identifying the
problems rarely enough to take corrective action.
Estimating Program Volume
The first step in preparing an estimate is to characterize the project volume. One measure is the number of source
lines of code or SLOC. A SLOC is a human return line of code that is not a blank line or commen. Same line
should not be counted more than once, even if the code appears several times in an application. Normally the
workload is estimated in terms of KSLOC.
How to estimate the project based on KSLOC?
Person months of effort required for the project is arrived by multiplying estimated quantity of KSLOC and
the effort required per KSLOC. This is the bease of all estimating models.
Table: Common Values for linear productivity factor#
The values in the table below are derived from work by Barry Boehm(COCOMO), Raymond Kyle and the
U.S. Air Force Cost Analysis Agency’s revised COCOMO (REVIC), and firms or organizations working
directly with the Cost Xpert Group.
Exponential Size Penalty
Project Type Linear Productivity Factor
Factor
Default 2.94 1.052
Embedded Development 2.58 1.110
eCommerce Development 3.6 1.030
Web Enabling 3.3 1.030
Military Development 2.77 1.072
ERP 3.96 1.926
Enterprise Application Integration 4.08 2.136
Man months for the smaller projects are calculated as:
The Person Man-day = KSLOC * Linear Productivity Factor * 30
For example,
To web enable an exsisting application of size 10,000 SOLC it would take, 10 * 3.3 * 30 = 990 Man-day.
Copyright © All Rights Reserved. Page 4

5. The above equation could be used only for smaller projects. Productivity varies with project size. In fact,
large projects are significantly less productive than small projects- probably because they require increased
coordination and communication time, plus more rework due to misunderstandings. This would lead to
penalize large projects for decreased efficiency. The exponential size penalty factor column in above table
helps with penalty adjustments.
Man months for the larger projects are calculated as:
The Person Man-Day = KSLOC * Linear Productivity FactorExponential Sise Penalty Factor * 30
For the same above example (Web enabling an exsisting application) and the project is big,
The new estimated time would be, 10 * 3.31.030 * 30 = 1,026 Man-days.
The above examples are applicable only when the number of KSLOC is known.
How to calculate KSOLC?
There are two approaches to this. They are:
 Direct Estimation
 Function points with backfiring
For both approaches the fundamental input variables are the experts and developers opinion.
Direct Estimation:
Normally, the first step in estimating the number of lines of code is the break the project down into modules
or some other logical grouping.
For example, a very high-level breakdown might be front-end process, middle-tier process, Database code
and Reports. Then the developers use their experience in building similar systems to estimate the number of
source lines of code required.
It is suggested to get three different types of estimate from every input resource. They are:
 Best case estimate (BEST)
 Worst case estimate (WORST)
 Expected case estimate (EXPECTED)
Based on these estimates calculate the Mean and Standard Deviation as,
Mean = (BEST + WORST + (4 * EXPECTED)) / 6
Standard Deviation = (WORST – BEST) / 6
Standard Deviation is a measure of how much deviation can be expected in the final number. For example,
the mean plus three times the Standard Deviation will ensure that there is a 99% probability that the project
would be completed as estimated.
Function point estimation with backfiring:
An alternative to direct SLOC estimating is to start with function points, and then use a process called
backfiring to convert them to SLOC.
To determine the number of function points, start by estimating the number of external inputs, external
interface files, external outputs, external queries and logical internal tables.
 External inputs are largely data entry screens. If a screen contains a tabbed notebook or similar
metaphor, each tab counted as a separate external input.
 External interface files are file-based inputs or outputs. Each record format within the file, or, in the
case of XML, each data object type, would count as a separate interface file even if residing in the
same physical file.
 External outputs are reports.
Copyright © All Rights Reserved. Page 5

6.  External queries are message or external function-based communication “into” or ”out” of
application.
 Logical internal tables are the number of tables in the database, assuming the database was third
normal form or better.
Table: Factors for coverting raw values into factor points
Raw Type Function Point Conversion Factor
External Inputs 4
External Interface Files 7
External Outputs 5
External Queries 4
Logical Internal Tables 10
To convert from these raw values into an actual count of function points, the raw numbers must be
multiplied by a conversion factor from above table.
For example, if there is a eCommerce system consisting of ten data entry screens, five interface files, thirty
reports, twenty queries and ten logical internal tables, then the total function points are:
(10 * 4) + (5 * 7) + (30 * 5) + (20 * 4) + (10 * 10) = 405 Function Points
By converting this function points into SOLC using the following table rule.
Table: Lines of code per function point by programming language
Language SLOC per fun ction point
C++ 53
COBOL 107
Oracle 25
SQL 13
VB 24
Java 43
.NET Framework 70
J2EE Framework 70
HTML 14
For example,
To implement 405 Function Points using J2EE frame work,
it requires 405 * 70 = 30,375 SLOC.
To implement a eCommerce systems using J2EE frame work,
it takes about 30,375 * 3.31.030 * 30 = 3,316 Man-days.
Copyright © All Rights Reserved. Page 6