SlideShare a Scribd company logo
TanTran – June 2013
 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
Software estimation techniques
 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
 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
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
Operating systems in Microsoft's Windows NT
Version of Linux
8
Scope for Automation of
Counting
An Intuitive Metric
(trực giác)
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
Software estimation techniques
 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
 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
 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
 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
 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
 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
 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
 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
 Refer to the excel tool…
20
Software estimation techniques
 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
 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
 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
Software estimation techniques
 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
 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
Task List should be S.M.A.R.T
Software estimation techniques
 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
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
Analyse the complexity of your actors. The level
of complexity is divided into 3 ActorTypes:
33
Σ(Number of each Actor type * Appropriate Factor)
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
UUCP = Actor weighting + Use Case Weighting
36
Tfactor = Σ(Rating * Factor)
TCF = 0.6 + (0.01 *TFactor)
Technical Complexity Factor
37
Efactor = Σ(Rating * Appropriate Factor)
Environmental Factor (EF) = 1.4 + (-0.03 * EFactor)
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
Software estimation techniques
 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
 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.
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
 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
 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

More Related Content

PPT
Software estimation
PPTX
Agile Business Value
KEY
Introduction to Google App Engine
PDF
Winning competition through organizational agility
PPT
Introduction to computerised accounting
PDF
cinema-management-system[1]
PPTX
Hospital information system for Nurses
PPTX
Software testing ppt
Software estimation
Agile Business Value
Introduction to Google App Engine
Winning competition through organizational agility
Introduction to computerised accounting
cinema-management-system[1]
Hospital information system for Nurses
Software testing ppt

What's hot (20)

PPT
Software Engineering (Project Scheduling)
PPT
Risk management(software engineering)
PDF
What is Web Testing?
PDF
Software project management
PDF
Chapter 6 software metrics
PPT
Software Estimation Techniques
PPTX
Software project estimation
PPTX
SRS(software requirement specification)
PPT
Rad model
PPTX
Ch 3 software quality factor
PPT
Risk management in software engineering
PPTX
Function Point Analysis
PPTX
Software Risk Management
PPTX
Sanity testing and smoke testing
PPTX
Checkpoints of the Process
PPTX
Error detection recovery
PPT
Putnam Resource allocation model.ppt
PPTX
Code Smell, Software Engineering
PPTX
Software requirement and specification
Software Engineering (Project Scheduling)
Risk management(software engineering)
What is Web Testing?
Software project management
Chapter 6 software metrics
Software Estimation Techniques
Software project estimation
SRS(software requirement specification)
Rad model
Ch 3 software quality factor
Risk management in software engineering
Function Point Analysis
Software Risk Management
Sanity testing and smoke testing
Checkpoints of the Process
Error detection recovery
Putnam Resource allocation model.ppt
Code Smell, Software Engineering
Software requirement and specification
Ad

Similar to Software estimation techniques (20)

PPT
software engineering software development life cycle
PDF
Adobe Scan 22-Aug-2024-1167527822678.pdf
PPTX
Group-5-presentation_SPM, here is deatiled version.pptx
PPT
Cost effort.ppt
PPTX
Cost estimation techniques
PPT
Cost effort in softwrae project management.ppt
PPTX
Estimation sharbani bhattacharya
PPTX
Decomposition technique In Software Engineering
PPTX
Software Engineering Fundamentals in Computer Science
PPT
Software metrics
PPTX
Loc and function point
PPTX
PPT
Hard work matters for everyone in everytbing
PDF
Extreme software estimation (xsoft estimation)
PDF
Extreme software estimation (xsoft estimation)
PDF
IJSRED-V2I4P8
PPTX
Functional point analysis
PPTX
Software cost estimation
PPTX
Cost xpert
PPT
software project management.lpu.slide.ansh.gupta
software engineering software development life cycle
Adobe Scan 22-Aug-2024-1167527822678.pdf
Group-5-presentation_SPM, here is deatiled version.pptx
Cost effort.ppt
Cost estimation techniques
Cost effort in softwrae project management.ppt
Estimation sharbani bhattacharya
Decomposition technique In Software Engineering
Software Engineering Fundamentals in Computer Science
Software metrics
Loc and function point
Hard work matters for everyone in everytbing
Extreme software estimation (xsoft estimation)
Extreme software estimation (xsoft estimation)
IJSRED-V2I4P8
Functional point analysis
Software cost estimation
Cost xpert
software project management.lpu.slide.ansh.gupta
Ad

More from Tan Tran (16)

PDF
Mật thư trò chơi lớn (tóm tắt)
PPT
Managing for results
PPTX
Personal task management
PPTX
Jira in action
PPTX
Hadoop at a glance
PPTX
Beautifying Data in the real world
PDF
BIS Vietnamese-German University
PPSX
Phac thao compendium
PPTX
Management skills in IT - Communication
PPTX
Internet governance and the filtering problems
PDF
C# conventions & good practices
PDF
Tổng hợp Dâng Ngài - nhạc sĩ Thy Yên
PDF
Flash coding convention for action script 3
PDF
Java convention
PPTX
VGU - BIS2010: Integrated Information Management
PPTX
Scrum introduction
Mật thư trò chơi lớn (tóm tắt)
Managing for results
Personal task management
Jira in action
Hadoop at a glance
Beautifying Data in the real world
BIS Vietnamese-German University
Phac thao compendium
Management skills in IT - Communication
Internet governance and the filtering problems
C# conventions & good practices
Tổng hợp Dâng Ngài - nhạc sĩ Thy Yên
Flash coding convention for action script 3
Java convention
VGU - BIS2010: Integrated Information Management
Scrum introduction

Recently uploaded (20)

PDF
STATICS OF THE RIGID BODIES Hibbelers.pdf
PDF
2.FourierTransform-ShortQuestionswithAnswers.pdf
PDF
Pre independence Education in Inndia.pdf
PDF
ANTIBIOTICS.pptx.pdf………………… xxxxxxxxxxxxx
PDF
Abdominal Access Techniques with Prof. Dr. R K Mishra
PDF
Module 4: Burden of Disease Tutorial Slides S2 2025
PDF
Microbial disease of the cardiovascular and lymphatic systems
PDF
grade 11-chemistry_fetena_net_5883.pdf teacher guide for all student
PPTX
school management -TNTEU- B.Ed., Semester II Unit 1.pptx
PPTX
master seminar digital applications in india
PPTX
Week 4 Term 3 Study Techniques revisited.pptx
PPTX
Pharmacology of Heart Failure /Pharmacotherapy of CHF
PPTX
Microbial diseases, their pathogenesis and prophylaxis
PDF
The Lost Whites of Pakistan by Jahanzaib Mughal.pdf
PDF
Chapter 2 Heredity, Prenatal Development, and Birth.pdf
PDF
102 student loan defaulters named and shamed – Is someone you know on the list?
PDF
Physiotherapy_for_Respiratory_and_Cardiac_Problems WEBBER.pdf
PPTX
PPT- ENG7_QUARTER1_LESSON1_WEEK1. IMAGERY -DESCRIPTIONS pptx.pptx
PPTX
Renaissance Architecture: A Journey from Faith to Humanism
PPTX
PPH.pptx obstetrics and gynecology in nursing
STATICS OF THE RIGID BODIES Hibbelers.pdf
2.FourierTransform-ShortQuestionswithAnswers.pdf
Pre independence Education in Inndia.pdf
ANTIBIOTICS.pptx.pdf………………… xxxxxxxxxxxxx
Abdominal Access Techniques with Prof. Dr. R K Mishra
Module 4: Burden of Disease Tutorial Slides S2 2025
Microbial disease of the cardiovascular and lymphatic systems
grade 11-chemistry_fetena_net_5883.pdf teacher guide for all student
school management -TNTEU- B.Ed., Semester II Unit 1.pptx
master seminar digital applications in india
Week 4 Term 3 Study Techniques revisited.pptx
Pharmacology of Heart Failure /Pharmacotherapy of CHF
Microbial diseases, their pathogenesis and prophylaxis
The Lost Whites of Pakistan by Jahanzaib Mughal.pdf
Chapter 2 Heredity, Prenatal Development, and Birth.pdf
102 student loan defaulters named and shamed – Is someone you know on the list?
Physiotherapy_for_Respiratory_and_Cardiac_Problems WEBBER.pdf
PPT- ENG7_QUARTER1_LESSON1_WEEK1. IMAGERY -DESCRIPTIONS pptx.pptx
Renaissance Architecture: A Journey from Faith to Humanism
PPH.pptx obstetrics and gynecology in nursing

Software estimation techniques

  • 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