|
Advanced
The function point metric was devised in 1977 by A. J. Albrecht, then of IBM,
as a means of measuring software size and
productivity. It uses functional, logical
entities such as inputs, outputs, and inquiries that tend to relate more
closely to the functions performed by the software as compared to other
measures, such as
lines of code. Marciniak provides a good capsule
introduction to the application of function point measurement
[Marciniak 94].
Function point definition and measurement have evolved substantially; the
International Function Point User Group (IFPUG), formed in 1986, actively
exchanges information on function point analysis (FPA)
[IFPUG 96]. The original metric has been augmented and refined to cover more than the original emphasis on business-related data processing. FPA has become generally accepted as an effective way to
However, uniformity of application and results are still issues (see Usage
Considerations). For reasons explained below in Technical Detail, FPA has been
renamed
functional size measurement, but FPA remains the more commonly used term.
Basic function points are categorized into five groups: outputs, inquiries, inputs, files, and Interfaces. A function point is defined as one end-user business function, such as a query for an input. This distinction is important because it tends to make a function point map easily into user-oriented requirements, but it also tends to hide internal functions, which also require resources to implement. To make up for this (and other) weaknesses, some refinements to and/or variations of the basic Albrecht definition have been devised, including
-
Early and easy function points. Adjusts for problem and data complexity with two questions that yield a somewhat subjective complexity measurement; simplifies measurement by eliminating the need to count data elements.
-
Engineering function points.
Elements (variable names) and operators (e.g., arithmetic,
equality/inequality, Boolean) are counted. This variation highlights
computational function
[Umholtz 94]. The intent is similar to that of the
operator/operand-based
Halstead measures (see Halstead Complexity Measures).
- Bang measure. Defines a function metric based on
twelve primitive (simple) counts that affect or show Bang, defined as "the
measure of true function to be delivered as perceived by the user"
[DeMarco 82]. Bang measure may be helpful in evaluating a software unit's value in
terms of how much useful function it provides, although there is little
evidence in the literature of such application. The use of Bang measure could
apply when reengineering (either complete or piecewise) is being considered,
as discussed in Maintenance of Operational Systems--An Overview.
-
Feature points. Adds changes to improve applicability to systems with significant internal processing (e.g., operating systems, communications systems). This allows accounting for functions not readily perceivable by the user, but essential for proper operation.
There is a very large user community for function points; IFPUG has more than
1200 member companies, and they offer assistance in establishing a FPA
program. The standard practices for counting and using function points are
found in the IFPUG Counting Practices Manual
[IFPUG 96]. Without some standardization of how the function points are enumerated and interpreted, consistent results can be difficult to obtain. Successful application seems to depend on establishing a consistent method of counting function points and keeping records to establish baseline productivity figures for your specific systems. Function measures tend to be independent of language, coding style, and software architecture, but environmental factors such as the ratio of function points to source lines of code will vary.
The proliferation of refinements and variations of FPA noted in Technical
Detail has led to fragmentation. To remedy this, a Joint Technical Committee
(JTC1) of the
International Standards Organization (ISO) has been working
since 1993 to develop ISO standards for sizing methods
[Rehesaar 96]. This standardization effort is now called Functional Size Measurement.
Counting the function points needed for FPA remains largely a manual
operation. This is an impediment to use. Wittig offers an approach to partial
automation of function point counting
[Wittig 94].
There are continuing concerns about the reliability and consistency of function point counts, such as
- whether two trained human counters will produce the same result for the same system
- the lack of inter-method reliability resulting from the variations described in Technical Detail
These reliability questions are addressed in a practical research effort
described in Kemerer
[Kemerer
93]. Siddiqee presents FPA as a good measure of productivity in a large
software production environment in Lockheed Corporation
[Siddiqee 93].
Any systematic FPA effort should collect the information into a database for ongoing analysis as the code is developed and/or modified.
FPA is in use in many industrial software companies; IFPUG is large, with more than 1200 member companies, and offers many resources. As noted above, however, an ISO-level standard is still in the making.
Currently, function point counting is a time-consuming and largely manual
activity unless tools are built to assist the process. Wittig and Kemerer cite
that it took more than five days to count a 4,000 function point system
[Wittig
94,
Kemerer
93]. However, the level of acceptance by software companies indicates that
FPA is useful. Training in FPA is highly recommended; IFPUG can assist in
securing training and locating FPA tools
[IFPUG 96].
For estimation of effort, approaches based on
lines of code (LOC) are an
alternative. The now-classic COCOMO (constructive cost model) method and its
REVIC (revised intermediate COCOMO) implementation provide a discipline for
using LOC as a software size estimator
[Boehm 81].
LOC can also be used in a complementary sense as a check on results. There is
also a technique called
Backfiring that consists of a set of bidirectional
equations for converting between function points and LOC
[Jones 95]. This is reportedly useful when using sizing data from a combination of projects, some with metrics in LOC and some in function points. However, generalizing the Backfiring technique to yield a simple LOC-per-function point ratio is not advisable.
This technology is classified under the following categories. Select a
category for a list of related topics.
|
Name of technology
|
Function Point Analysis
|
|
Application category
|
Cost Estimation (AP.1.3.7)
|
|
Quality measures category
|
Productivity (QM.5.2)
|
|
Computing reviews category
|
Software Engineering Metrics (D.2.8)
Software Engineering Management (D.2.9)
|
|
[Boehm 81]
|
Boehm, Barry W. Software Engineering Economics. Englewood Cliffs, NJ:
Prentice-Hall, 1981.
|
|
[DeMarco 82]
|
DeMarco, Tom. Controlling Software Projects: Management, Measurement, and
Estimation. New York, NY: Yourdon Press, 1982.
|
|
[Dreger 89]
|
Dreger, J. Brian. Function Point Analysis. Englewood Cliffs, NJ:
Prentice Hall, 1989.
|
|
[Heller 95]
|
Heller, Roger. "An Introduction to Function Point Analysis," Crosstalk,
Journal of Defense Software Engineering 8, 11 (November/December 1995):
24-26.
|
|
[IFPUG 96]
|
The International Function Point Users' Group (IFPUG) Web site
[online]. Available WWW
<URL:
http://www.ifpug.org/>
(1996).
|
|
[Jones 95]
|
Jones, Capers. "Backfiring: Converting Lines of Code to Function Points."
IEEE Computer 28, 11 (November 1995): 87-8.
|
|
[Kemerer 93]
|
Kemerer, Chris. "Reliability of Function Points Measurement: A Field
Experiment." Communications of the ACM 36, 2 (February 1993):
85-97.
|
|
[Marciniak 94]
|
Marciniak, John J., ed. Encyclopedia of Software Engineering,
518-524. New York, NY: John Wiley & Sons, 1994.
|
|
[Rehesaar 96]
|
Rehesaar, Hugo. "ISO/IEC Functional Size Measurement Standards,"
311-318. Proceedings of the GUFPI/IFPUG Conference on Software Measurement
and Management. Rome, Italy, February 5-9, 1996. Westerville, OH:
International Function Point Users Group, 1996.
|
|
[Siddiqee 93]
|
Siddiqee, M. Waheed. "Function Point Delivery Rates Under Various
Environments: Some Actual Results," 259-264. Proceedings of the Computer
Management Group's International Conference. San Diego, CA, December
5-10, 1993. Chicago, IL: Computer Management Group, 1993.
|
|
[Umholtz 94]
|
Umholtz, Donald C. & Leitgeb, Arthur J. "Engineering Function Points and
Tracking Systems."Crosstalk, Journal of Defense Software Engineering
7, 11 (November 1994): 9-14.
|
|
[Wittig 94]
|
Wittig, G. E. & Finnie, G. R. "Software Design for the Automation of
Unadjusted Function Point Counting," 613-623. Business Process
Re-Engineering Information Systems Opportunities and Challenges, IFIP TC8 Open
Conference. Gold Coast, Queensland, Australia, May 8-11, 1994. The
Netherlands: IFIP, 1994.
|
Edmond VanDoren, Kaman Sciences, Colorado Springs
10 Jan 97 (original)
The Software
Engineering Institute (SEI) is a federally funded research and
development center sponsored by the U.S. Department of Defense
and operated by Carnegie Mellon University.
Copyright
2007
by Carnegie Mellon University
Terms of Use
URL: http://www.sei.cmu.edu/str/descriptions/fpa_body.html
Last Modified: 11 January 2007
|
