This document provides an overview of several software estimation techniques: lines of code estimation, function point estimation, three point estimation, work breakdown structure based estimation, use case based estimation, and estimation in agile projects. It discusses the basics of each technique, including counting lines of code, function points types, the three point estimation formula, how to create a work breakdown structure, and use case point estimation. Examples are provided to illustrate various techniques.

1. TanTran – June 2013

2.  EstimationTechniques
 Lines of Code estimation
 Function Point Estimation
 Three Point Estimation
 Work break down structure based estimation
 Use case based estimation
 Estimation in Agile Projects
 Q&A
2

4.  Source lines of code (SLOC) 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.
 SLOC is typically used to predict the amount of
effort that will be required to develop a
program, as well as to estimate programming
productivity or maintainability once the
software is produced.
4

5.  Physical SLOC (LOC): count of lines in the
text of the program's source code including
comment lines and blank lines (blank lines in
excess of 25% are not counted).
 Logical SLOC: attempts to measure the
number of executable "statements“
 There are several cost, schedule, and effort
estimation models which use SLOC as an
input parameter.
5

6. 6
for (i = 0; i < 100; i++) printf("hello"); /* How many lines of code is this? */
In this example we have:
• 1 | 5 Physical Lines of Code (LOC)
• 2 | 2 Logical Line of Code (LLOC) (for statement and printf statement)
/* Now how many lines of code is this? */
for (i = 0; i < 100; i++)
{
printf("hello");
}

7. 7
Operating systems in Microsoft's Windows NT
Version of Linux

8. 8
Scope for Automation of
Counting
An Intuitive Metric
(trực giác)

9. 9
 Lack of Accountability: coding phase accounts
for only 30% to 35% of the overall effort
 Lack of Cohesion with Functionality: develop the
same functionality with far less code
 Difference in Languages
 Advent of GUITools
 Problems with Multiple Languages
 Psychology:A programmer whose productivity
is being measured in lines of code will have an
incentive to write unnecessarily verbose code

11.  Function Point Analysis (FPA) is an ISO
recognized method to measure the
functional size of an information system. The
functional size reflects the amount of
functionality that is relevant to and
recognized by the user in the business. It is
independent of the technology used to
implement the system.
11

12.  Following functionalities are counted while
counting the function points of the system.
 Data Functionality
▪ Internal Logical Files (ILF)
▪ External Interface Files (EIF)
 Transaction Functionality
▪ External Inputs (EI)
▪ External Outputs (EO)
▪ External Queries (EQ)
12

13. 13

14.  Development Project Function Point Count
measures the application functions delivered when the
project is complete, and is associated with the initial
installation or complete rewrite of new software.
 Application Function Point Count
sizes the current functions the application provides to
the end-user.
 Enhancement Project Function Point Count
sizes the functionality added, changed or deleted to an
existing application plus any conversion functionality
needed
14

15.  Internal Logical Files (ILF) are logically related, user
identifiable data or control information used by the
application. The primary intent of an ILF is to hold data to
be maintained (modified) and stored within the
boundaries of the application being counted.
 External Interface Files (EIF) are logically related, user
identifiable data or control information used by the
application, but maintained (modified) and stored by
another application outside the boundaries of the system.
The primary intent of an EIF is to hold data to be
referenced by the application being counted. An EIF in the
application being counted must be an ILF in a different
application.
15

16.  External Inputs (EI) are transactions representing an application’s data
maintenance and control processing requirements. It is data that enters
the application from outside its boundaries, is unique in its format or in
the processing logic it initiates.
 External Outputs (EO) are transactions representing an application’s
output processing requirements. The data is sent outside the boundaries
of the application, where the format or the logic creating the output is
unique.
 External Inquiries (EQ) are unique transactions representing an
application’s inquiry or data retrieval processing requirements. The
primary intent of an EQ is to present information to a user through a
retrieval process.
16

17.  The overall characteristics of a system must be assessed and
factored in to get the total number of Adjusted Function Points.
This is done by examining 14 general system characteristics of the
system, such as the transaction rate, performance, and
installation ease. Each characteristic is evaluated as to its degree
of influence on the system. The Total Degree of Influence is used
in a formula to give the Adjusted Function Point Count, commonly
called the Function Point Count.
17

18.  A tool to determine the size of a purchased
application package by counting all the
functions included in the package
 A tool to help users determine the benefit of
an application package to their organization
by counting functions that specifically match
their requirements
18

19.  A tool to measure the units of a software
product to support quality and productivity
analysis
 A vehicle to estimate cost and resources
required for software development and
maintenance
 A normalization factor for software
comparison
19

20.  Refer to the excel tool…
20

22.  The three-point estimation technique is used in
management and information systems applications
for the construction of an approximate probability
distribution representing the outcome of future
events, based on very limited information.
 In three-point estimation, three values are produced
initially for every task based on prior experience or
best-guesses:
a = the best-case estimate
m = the most likely estimate
b = the worst-case estimate.
22

23.  Weighted Average Distribution
E = (a + 4m + b) / 6
 Standard Deviation
SD = (b − a)/6
SD value is usually represented with the Greek letter sigma (σ).
23

24.  Task A:
a = 3 days
m = 5 days
b = 10 days
24
E = (3 + (4 x 5) + 10) / 6 = 5.5
SD = (10 – 3) / 6 = 1.67
5.5 days would be our estimation for the given task
With confidence of 68% we need
from 3.83 to 7.17 days (5.5 +- 1.67) to finish the task

26.  The WBS provides the foundation for all project
management work, including, planning, cost
and effort estimation, resource allocation, and
scheduling.
 Dividing complex projects to simpler and
manageable tasks is the process identified as
Work Breakdown Structure (WBS).
 It defines and groups a project's discrete work
elements in a way that helps organize and define
the total work scope of the project.
26

27. 27

28.  Accurate and readable project organization.
 Accurate assignment of responsibilities to the
project team.
 Indicates the project milestones and control
points.
 Helps to estimate the cost, time, and risk.
 Illustrate the project scope, so the stakeholders
can have a better understanding of the same.
28

29. 29
Task List should be S.M.A.R.T

31.  Use cases are an excellent way of capturing our
user requirements. It makes sense to base that
estimation on those use cases, given they are
the requirements we are going to implement.
 The Karner method which was developed on
1993 by Gustav Karner. This method involves
the studying of the system actors and use
cases, weighting them according to complexity
and then applying technical and environment
factors.
31

32. 1.Weight the actors
2.Weight the use cases
3. Calculate the unadjusted use case points (UUCP)
4. Determine the technical complexity factors
5. Determine the environmental factors
6. Calculate the Use Case Points (UCP)
32

33. Analyse the complexity of your actors. The level
of complexity is divided into 3 ActorTypes:
33
Σ(Number of each Actor type * Appropriate Factor)

34. 34
Analyse the complexity of your actors.The level of
complexity is divided into 3 use case types:
Σ(Number of each use case type * Appropriate Factor)

35. 35
UUCP = Actor weighting + Use Case Weighting

36. 36
Tfactor = Σ(Rating * Factor)
TCF = 0.6 + (0.01 *TFactor)
Technical Complexity Factor

37. 37
Efactor = Σ(Rating * Appropriate Factor)
Environmental Factor (EF) = 1.4 + (-0.03 * EFactor)

38. 38
UCP = UUCP *TCF * EF
We can use this value to estimate how long the project should
take to develop. The Karner process suggests a value of 20
man hours per UCP for this estimation, so to estimate project
duration use this formula:
Project man-hours = 20 * UCP

40.  http://www.planningpoker.com
 Consensus-based estimation
technique for estimating
 First described by James
Grenningand later popularized
by Mike Cohn in the book Agile
Estimating and Planning
40

41.  Estimated in story points for
user stories *
 It is most commonly used in
agile software development
41
* User stories are user requirements of form "As a <Some Role> I want <Some
Need> so that <Some Benefit>”
 For Eg: the deck contains the following
cards: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.

42. 1. Each person gets a deck of cards.
2. The story to be estimated is read to all.
3. Attendants ask clarifications for the item.
4. Each person selects a card and puts it on the table facing down.
5. When everyone is done, cards are exposed.
6. If the estimations do not match a short discussion is done.
7. Timer is started for discussion and discussion must cease when it
runs out -> Goto 4.
8. Handle next item.
42

43.  Those who do the work estimate it.
 Emphasizes relative estimation
 Reduces anchoring - Everyone's opinion is
heard.
 Modeled for open discussion – forces
thinking.
 It’s quick & fun !
43

44.  ProjectCodeMeter - Source lines of code
http://www.projectcodemeter.com/cost_estimation/help/GL_sloc.htm
 Wikipedia
 Three-point estimation technique
 http://www.agile-code.com/blog/easy-task-estimation-with-three-point-estimation-
technique/
 Function Point Counting Practices Manual
 http://perun.pmf.uns.ac.rs/old/repository/research/se/functionpoints.pdf
 Use Case Based Project Estimation
 http://the-technical-diaries.blogspot.com/2011/06/use-case-based-project-
estimation.html
 Agile Software Estimation - Sunil Kumar
 http://www.slideshare.net/jssunil/agile-software-estimation
44

45. 45