The function point is a "unit of measurement" to express the amount of business functionality an information system (as a product) provides to a user. Function points are used to compute a functional size measurement (FSM) of software. The cost (in dollars or hours) of a single unit is calculated from past projects.[1]

Standards

There are several recognized standards and/or public specifications for sizing software based on Function Point.

1. ISO Standards

The first five standards are implementations of the over-arching standard for Functional Size Measurement ISO/IEC 14143.[2] The OMG Automated Function Point (AFP) specification, led by the Consortium for IT Software Quality, provides a standard for automating the Function Point counting according to the guidelines of the International Function Point User Group (IFPUG) However, the current implementations of this standard have a limitation in being able to distinguish External Output (EO) from External Inquiries (EQ) out of the box, without some upfront configuration.[3]

Introduction

Function points were defined in 1979 in Measuring Application Development Productivity by Allan J. Albrecht at IBM.[4] The functional user requirements of the software are identified and each one is categorized into one of five types: outputs, inquiries, inputs, internal files, and external interfaces. Once the function is identified and categorized into a type, it is then assessed for complexity and assigned a number of function points. Each of these functional user requirements maps to an end-user business function, such as a data entry for an Input or a user query for an Inquiry. This distinction is important because it tends to make the functions measured in function points map easily into user-oriented requirements, but it also tends to hide internal functions (e.g. algorithms), which also require resources to implement.

There is currently no ISO recognized FSM Method that includes algorithmic complexity in the sizing result. Recently there have been different approaches proposed to deal with this perceived weakness, implemented in several commercial software products. The variations of the Albrecht-based IFPUG method designed to make up for this (and other weaknesses) include:

Contrast

The use of function points in favor of lines of code seek to address several additional issues:

Criticism

Albrecht observed in his research that Function Points were highly correlated to lines of code,[9] which has resulted in a questioning of the value of such a measure if a more objective measure, namely counting lines of code, is available. In addition, there have been multiple attempts to address perceived shortcomings with the measure by augmenting the counting regimen.[10][11][12][13][14][15] Others have offered solutions to circumvent the challenges by developing alternative methods which create a proxy for the amount of functionality delivered.[16]

See also

References

  1. ^ Thomas Cutting, Estimating Lessons Learned in Project Management – Traditional, Retrieved on May 28, 2010
  2. ^ ISO/IEC JTC 1/SC 7 Software and systems engineering (2007-02-01). "ISO/IEC 14143". International Standards Organization. Retrieved 2019-02-26.((cite web)): CS1 maint: numeric names: authors list (link)
  3. ^ OMG/CISQ Specification "Automated Function Points", February 2013, OMG Document Number ptc/2013-02-01 http://www.omg.org/spec/AFP/1.0
  4. ^ A. J. Albrecht, "Measuring Application Development Productivity," Proceedings of the Joint SHARE, GUIDE, and IBM Application Development Symposium, Monterey, California, October 14–17, IBM Corporation (1979), pp. 83–92.
  5. ^ Engineering Function Points and Tracking System, Software Technology Support Center Archived 2010-11-11 at the Wayback Machine, Retrieved on May 14, 2008
  6. ^ Lima, Osias de Souza; Farias, Pedro Porfírio Muniz; Belchior, Arnaldo Dias (2003-06-01). "Fuzzy Modeling for Function Points Analysis". Software Quality Journal. 11 (2): 149–166. doi:10.1023/A:1023716628585. ISSN 1573-1367. S2CID 19655881.
  7. ^ Jones, C. and Bonsignour O. The Economics of Software Quality, Addison-Wesley, 2012. pp. 105-109.
  8. ^ Jones, C. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill. June 1996.
  9. ^ Albrecht, A. Software Function, Source Lines of Code, and Development Effort Estimation – A Software Science Validation. 1983.
  10. ^ Symons, C.R. "Function point analysis: difficulties and improvements." IEEE Transactions on Software Engineering. January 1988. pp. 2-111.
  11. ^ Hemmstra, F. and Kusters R. "Function point analysis: evaluation of a software cost estimation model." European Journal of Information Systems. 1991. Vol 1, No 4. pp 229-237.
  12. ^ Jeffery, R and Stathis, J. "Specification-based software sizing: An empirical investigation of function metrics." Proceedings of the Eighteenth Annual Software Engineering Workshop. 1993. p 97-115.
  13. ^ Symons, C. Software sizing and estimating: Mk II FPA (Function Point Analysis). John Wiley & Sons, Inc. New York, 1991
  14. ^ Demarco, T. "An algorithm for sizing software products." ACM Sigmetrics Performance Evaluation Review. 1984. Volume 12, Issue 2. pp 13-22.
  15. ^ Jeffrey, D.R, Low, G.C. and Barnes, M. "A comparison of function point counting techniques." IEEE Transactions on Software Engineering. 1993. Volume 19, Issue 5. pp 529-532.
  16. ^ Schwartz, Adam. "Using Test Cases To Size Systems: A Case Study." 2012 Ninth International Conference on Information Technology- New Generations. April 2012. pp 242-246.

External links

Categories