Function Point Analysis (FPA) refers to the practice of using function points to size and estimate the cost of work on systems.  Function Points are a normalized unit of measure used to:

• Quantify the amount of business functionality a system provides business users

• Estimate the cost to develop a system or set of features based on the number of function points it supports

• Determine how costly a system is to maintain based on the number of function points it supports

To state things differently, Function Points are good for answering questions like:

• How big is system “A”? Is system “A” bigger than system “B” and by how much? (It answers these in terms of features)

• How much will it cost me to build system “A”?

• If I’m paying $500,000/yr to maintain system “B” is that cost effective?

Function Points, being a normalized unit of measure, provides an apples-to-apples comparison of systems and the costs associated with building and supporting them.

This method of measuring systems was first developed in 1979 by Allan Albrecht of IBM.  Today it is supported by a group called the International Function Point User Group (or IFPUG for short).

To count the number of function points that a system possesses, a skilled practitioner first categorizes each feature into one of five types (outputs, inquiries, inputs, internal files, and external interfaces).  Then a complexity is assigned to each feature.  Finally, a number of function points can be assigned to each feature.  Certain types of system also have additional function point adjustment factors that are used.  The end result is a single number for the entire system called a Function Point Index.  Based on this value and historical function point data, the cost to develop the system can be estimated.

FPA brings structure and rigor to a process that is often very subjective.  However, there are a number of potential challenges that are often voiced when discussing the merits of FPA.

• Counting Function Points can be a tricky task to do well.  Getting consistent results is a challenge unless you are a skilled practitioner at counting function points.  There is a sizable “Function Point Counting Practices Manual” available to direct the practitioner in this exercise.

• FPA tends to hide internal functions (e.g. algorithms), which also require resources to implement.

While not formally supported by the IFPUG, a number of other variations of FPA exist today, and some try to compensate for these challenges.