# Software Engineering: Function Point Analysis: Introduction

Intro | Counting | Data FPs | Transactional FPs | Estimation

## Estimation techniques

Software size estimation or measurement (size, effort, schedule, defects, productivity, ...) is essential for managing a software project. There are two general techniques.

1. 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.
2. 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