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
3.
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");
}
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
10.
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
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
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
25.
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
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
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)
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
39.
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