Software estimation
techniques
Lidia García Esparcia
Daniel Román Planas
Estefanía Caballero Ruiz
Victoria Blanco Alegría
Index
 Introduction
 Current situation
 Estimation techniques
 Function points
 Characteristic points
 Lines of code




Comparative
Conclusion
Future trends
Sources
Introduction
 Why we measure?
 Evaluate the productivity
 Evaluate the profits
 A previous stage before estimate
 Justify using new tools
 Software projects are typically controlled by four
major variables; time, requirements, resources
(people, infrastructure/materials, and money), and
risks.
 Overestimating needs can be very expensive for the
organization
 3 kinds of methods
Current situation
 All sw development companies use
planning techniques in order to
estimate the cost of a project.
 Break the project down into the different
tasks needed.
 Evaluate each task on two scales:
complexity and size of work
Function points
Index







Introduction
ISO/IEC 14143
IFPUG-FPA
MK II
COSMIC FFP
Method Evolution
Criticism
Introduction
 Functional Size Measurement Method





Simple
Independent of the technology
Based on functional user requirements
Consistent
Estandar
 Unit of measurement to express the
amount of business functionality an
information system provides to a user.
ISO/IEC 14143
 Define the concepts and features that
a method should satisfy in order to be
approved.
 Methods:




ISO/IEC 20926:2003 Software engineering -- IFPUG 4.1
Unadjusted functional size measurement method
ISO/IEC 24570. Software engineering -- NESMA -- Function
Point Analysis.
ISO/IEC 20968:2002 Software engineering -- Mk II Function
Point Analysis
ISO/IEC 19761:2003 Software engineering -- COSMIC-FFP -A functional size measurement method
IFPUG - FPA
“Standard method for measuring the development of software from
the user's point of view.

In 1986, Allan Albrecht found the International Function Point User
Group

Most famous and most used

Number of function points acording to the component type
(transaction functions, data files) and its complexity.

Adjustment of the result

Evaluates the size of the project, cost and development time .

Has limitations for measuring software in real time systems.
MK II
 Developed in 1986 by KPMG, defined and
published by Charles R. Symons in 1991.
Adopted by UKSMA (United Kingdom
Software Metrics Association.
 Method of continuous measurement
throughout the life cycle of an application
 Derivation of the Albrecht’s function Points .
 Logic discrete transactions consisting of
entry, process and exit
COSMIC-FFP

FFP (v. 1.0) was published in 1997 as an extension of IFPUG method to measure
the functional size of real-time software and control systems.

In 1998, a group of experts in software metrics, established the Common
Software Measurement International Consortium (COSMIC FFP).

Introduces additional data and transactional function types:


Control Data:
 Multiple occurrence logical group
 Single ocurrence logical group.

Transactions:
 Full Function Points enter into the calculation not only processes
but also includes subprocesses .
The other types of data and processes are counted with the standard FPA
technique
Method Evolution
Criticism

Additional dedication in the software development projects.

It is hard to train staff in their use.

The method of calculation is subjective.

Need to re-estimate the size as we have more product
knowledge.

Lacks precision when it comes to small projects.

Not applicable to all systems.
Feature points
Index




Introduction
Method
Example
Advantages
Feature points
Introduction
 Software estimation method designed by
Caper Jones.
 Very similar to function points, but more
accurate for estimating scientific and
complex software.
 Used specifically for CAD software,
embedded systems and real-time
applications.
Feature points
Introduction
 The differences between function points
and feature points are in the algorithm cost
estimation, that is new on feature points,
and the removal of the different complexity
levels, establishing just one for each
feature.
Feature points
Method
1. Count the number of the different
features.
2. Calculate the cost of these features.
Feature points
Count the number of different features
Features in this step are the same that function points define,
adding the count of the algorithms. This is:
 External inputs.
 External outputs.
 External queries.
 Internal logical files.
 External logical files.
 Algorithms.
Feature points
Calculate features’ cost
Each feature has an unique complexity value.
Cost estimation of that features is calculated by multiplying
complexity by the count of that feature.
Final estimation are done by applying this equation:
FPE = TOTAL_COUNT * (0.65 + 0.01 * SUM(Fi))
Fi => Result of question number i on information system
survey, also defined on function points estimation.
Feature points
Example
FUNCTION POINTS
Feature points
Example
FEATURE POINTS
Feature points
Advantages

More accurate when is applied to scientific, mathematic,
real-time or military software, which uses complex
algorithms.

Used on other kinds of software, feature points offers
similar results than function points calculate.
Lines of code
Index






Introduction
Types
Example
Estimating Effort
Advantages
Disadvantages
Lines of code
Introduction
Measures the size of a software project
counting the number of lines of code.
 Predict the amount of effort.
 Estimate programming productivity.
 Estimate effort once the software is produced.
Lines of code
Types
 Physical SLOC
 Count the lines of the program's
source code.
 Logical SLOC
 Measure the number of statements.
Lines of code
Example
Lines of code




Productivity = KLOC / person-month
Quality = defects / KLOC
Cost = Cost / KLOC
Documentation = pages of
documentation / LOC
Lines of code
Estimating effort
It is based on previous projects or on the
experience of the developer.
Lines of code
E = (a + 4m + b) / 6
a= ideal number of LOC
b= pessimistic number of LOC
m= most probable number of LOC
Lines of code
Advantages
 Easy method
 Many methods use LOC as an imput
Lines of code
Disadvantages
 Lack of Cohesion with Functionality
 Lack of Accountability
 Difference in Languages
 Lack of Counting Standards
 Psychology
Comparative
Method
Uses
Staff
During the project
Function points Not all systems and
lacks precision in
small projects
Hard to train
Need to re-estimate
the size as we have
more product
knowledge
Feature points
Software that uses
complex algorithms
Not easy to learn
Lines of code
Many methrics use
LOC as an imput
Easy
Based in other
projects or in own
experience
Conclusion
 The fundamental goals of software
estimation are to produce estimations of
effort and schedule for anticipated software
projects
 Increasingly, it is recognized that software
estimation techniques must reflect, and be
an integral part of, the technical and
managerial processes used to develop and
modify software.
 The preceding techniques can help one
achieve better estimates
Sources:




www.inf.udec.cl
www.monografias.com
www.willydev.net
www.wikipedia.com