Estimation techniques
Software size estimation or measurement (size, effort, schedule, defects, productivity, ...) is
essential for managing a software project. There are two general techniques.
- The common method of estimation is to look for experience on similar
projects in the past, either by consulting experts or looking at documentation
on previous projects.
- Another technique is to look at the functionality of a system to make
an estimate of the size.
Function Point Analysis (FPA) is probably the most well developed of these.
See Functional Size Measurement,
www.geocities.com/lbu_measure/fpa/fpa.htm,
for an overview of major variations on this technique.
There are programs that automate some of the, and do a better
job than the manual methods.
Measuring units of work
SLOC. The traditional measurement of program size (an amount of work)
is source lines of code (SLOC)
or just lines of code (LOC). This
is a very general and often ill-defined measurement. What exactly is a line
of code? The number of lines of code is dependent on the programming
language and on the expertise of the programmer.
Making an estimate of the number of lines of code in a new project
requires experience, and can be very difficult for new applications.
Function points. Function Point Analysis circumvents the LOC issues by using units of
function (input and output interactions, database tables, etc) to describe
programs. This is a well-developed system with considerable empirical data to
validate it. The International Function Point Users
Group (IFPUG, www.ifpug.org) offers manuals and certification.
A more general term for techniques of this type is Functional Size Measurement.
Adjustment factors
Function points don't solve the problems of team variation, programming tool
variation, type of application, etc. There are 14 adjustment factors in the
current IFPUG standard, but they may be eliminated from
an upcoming ISO standard.
Using function points to calculate effort
See FPA Effort Estimation for turning the
number function points into programming effort and schedule.
References
- David Garmus and David Herron, Function Point Analysis - Measurement
Practices for Successful Software Projects, Addison-Wesley, 2000.
This is a good introduction to FPA with worked examples and a practice test
for IFPUG certification. The calculation of function points is well covered,
but information on applying them, eg in estimation, is missing. It
would have benefitted from a couple of days of reorganization.
This book was the major source of information for these notes.
- International Fixed Point Analysis Users Group (IFPUG), www.ifpug.org.
This has additional information and official manuals, but little
information is available to non-members, with the exception
of www.ifpug.com/fpafund.htm,
Fundamentals of FPA by David Longstreet, as well as his free book
below.
- Longstreet, David. Function Point Training and Analysis Manual.
Longstreet Consulting Inc, Revision Dates : Feb. 2001, 30 Aug. 2001,
1 March 2002. http://www.SoftwareMetrics.Com/freemanual.htm.
- www.geocities.com/lbu_measure/fpa/fpa.htm
is an excellent overview of what's going on with FPA and similar techniques.
- Rapid Development: Taming Wild Software Schedules,
by Steve McConnell, Microsoft Press, 1996. ISBN 1-55615-900-5.
An excellent book in many respects, it only touches briefly on
Function Point Analysis.
- function-point estimation
- Articles by Capers Jones