Function point: Difference between revisions

Revision as of 20:36, 24 July 2019

Latest revision as of 15:36, 11 April 2025

(19 intermediate revisions by 19 users not shown)

Line 1:

{{Short description|Unit of measurement}}

AThe '''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.<ref>Thomas Cutting, [http://www.pmhut.com/estimating-lessons-learned-in-project-management-traditional Estimating Lessons Learned in Project Management – Traditional], Retrieved on May 28, 2010</ref>

==Standards==

{{As of|2013}}, thereThere are several recognized standards and/or public specifications for sizing software based on Function Point.

'''1. ISO Standards'''

Line 11 ⟶ 12:

* Nesma: ISO/IEC 24570:2018 Software engineering – Nesma functional size measurement method version 2.3 – Definitions and counting guidelines for the application of Function Point Analysis

* [[COSMIC functional size measurement|COSMIC]]: ISO/IEC 19761:2011 Software engineering. A functional size measurement method.

* [[Object Management Group|OMG]]: ISO/IEC 19515:2019 Information technology — Object Management Group Automated Function Points (AFP), 1.0

The first five standards are implementations of the over-arching standard for [[Object ManagementSoftware Groupmeasurement|OMGFunctional Size Measurement]], anISO/IEC open14143.<ref membershipname="ISO/IEC 14143">{{cite web |url=https://www.iso.org/standard/38931.html |title=ISO/IEC 14143 |author=ISO/IEC JTC 1/SC 7 Software and notsystems engineering |date=2007-for02-profit01 computer|publisher=International industryStandards standardsOrganization consortium,|access-date=2019-02-26}}</ref> hasThe adopted theOMG Automated Function Point (AFP) specification, led by the [[CISQ|Consortium for IT Software Quality]]. It, 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.<ref>OMG/CISQ Specification "Automated Function Points", February 2013, OMG Document Number ptc/2013-02-01 http://www.omg.org/spec/AFP/1.0</ref>

'''2. OMG Specification for Automated Function Point'''

[[Object Management Group|OMG]], an open membership and not-for-profit computer industry standards consortium, has adopted the Automated Function Point (AFP) specification led by the [[CISQ|Consortium for IT Software Quality]]. It 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.<ref>OMG/CISQ Specification "Automated Function Points",February 2013, OMG Document Number ptc/2013-02-01 http://www.omg.org/spec/AFP/1.0</ref>

== Introduction ==

Function points were defined in 1979 in ''Measuring Application Development Productivity'' by Allan J. Albrecht at [[IBM]].<ref>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.</ref> The [[functional requirements|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:

* 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.<ref>Engineering Function Points and Tracking System, [http://www.stsc.hill.af.mil/crosstalk/1994/11/xt94d11e.asp Software Technology Support Center] {{Webarchive|url=https://web.archive.org/web/20101111062857/http://www.stsc.hill.af.mil/crosstalk/1994/11/xt94d11e.asp |date=2010-11-11 }}, Retrieved on May 14, 2008</ref> The intent is similar to that of the operator/operand-based [[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." 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 re-engineering (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.

* [[Weighted Micro Function Points]] – One of the newer models (2009) which adjusts function points using weights derived from program flow complexity, operand and operator vocabulary, object usage, and algorithm.

*Fuzzy Function Points - Proposes a fuzzy and gradative transition between low x medium and medium x high complexities<ref>{{Cite journal|lastlast1=Lima|firstfirst1=Osias de Souza|last2=Farias|first2=Pedro Porfírio Muniz|last3=Belchior|first3=Arnaldo Dias|date=2003-06-01|title=Fuzzy Modeling for Function Points Analysis|journal=Software Quality Journal|language=en|volume=11|issue=2|pages=149–166|doi=10.1023/A:1023716628585|s2cid=19655881|issn=1573-1367}}</ref>

== Contrast ==

Line 35:

== Criticism ==

Albrecht observed in his research that Function Points were highly correlated to lines of code,<ref>Albrecht, A. Software Function, Source Lines of Code, and Development Effort Estimation – A Software Science Validation. 1983.</ref> 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.<ref>Symons, C.R. "Function point analysis: difficulties and improvements." IEEE Transactions on Software Engineering. January 1988. pp. 2-111.</ref><ref>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.</ref><ref>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.</ref><ref>Symons, C. Software sizing and estimating: Mk II FPA (Function Point Analysis). John Wiley & Sons, Inc. New York, 1991</ref><ref>Demarco, T. "An algorithm for sizing software products." ACM Sigmetrics Performance Evaluation Review. 1984. Volume 12, Issue 2. pp 13-22.</ref><ref>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. </ref> Others have offered solutions to circumvent the challenges by developing alternative methods which create a proxy for the amount of functionality delivered.<ref>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.</ref><ref>Fischman, L. [http://www.crosstalkonline.org/storage/issue-archives/2001/200102/200102-Fischman.pdf "Evolving Function Points" Crosstalk: The Journal of Defense Software Engineering. 2001. Volume 14, Issue 2. pp 24-27.] Retrieved on July 2, 2014.</ref>

== See also ==

* [[COCOMO]] (Constructive Cost Model)

* [[Comparison of development estimation software]]

* [[COSMIC functional size measurement]]

* [[MK II FPA|Mark II method]]

* [[Object point]]

Line 46 ⟶ 47:

* [[Source lines of code]]

* [[Use Case Points]]

* [[The Simple Function Point (SFP) method|The Simple Function Point method]]

== References ==

Line 52 ⟶ 54:

== External links ==

* [http://www.ifpug.org/ The International Function Point Users Group (IFPUG)]

[[Category:Software metrics]]