Function point: Difference between revisions

Revision as of 21:15, 9 February 2022

Revision as of 07:59, 15 August 2022

Line 1:

{{Short description|Unit of measurement}}

The '''functionFunction pointPoint''' is a "unit of measurement" to express the amount of business functionality an [[information system]] (as a product) provides to a user. Function pointsPoints 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==

Line 21:

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 easyEasy functionFunction pointsPoints – 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 functionFunction pointsPoints – 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 pointsPoints – 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|last1=Lima|first1=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 ==

The use of functionFunction pointsPoints in favor of linesLines of codeCode seek to address several additional issues:

* The risk of "inflation" of the created lines of code, and thus reducing the value of the measurement system, if developers are incentivized to be more productive. FP advocates refer to this as measuring the size of the solution instead of the size of the problem.

* Lines of Code ([[Source lines of code|LOC]]) measures reward low level languages because more lines of code are needed to deliver a similar amount of functionality to a higher level language.<ref>Jones, C. and Bonsignour O. The Economics of Software Quality, Addison-Wesley, 2012. pp. 105-109.</ref> C. Jones offers a method of correcting this in his work.<ref>Jones, C. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill. June 1996.</ref>

Line 41:

* [[Comparison of development estimation software]]

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

* [[Object pointPoint]]

* [[Software development effort estimation]]

* [[Software Sizing]]

* [[Source lines of code]]

* [[Use Case Points]]

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

== References ==

Line 53 ⟶ 52:

== External links ==

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

* [http://www.cosmic-sizing.org/ The Common Software Measurement International Consortium (COSMIC)]

[[Category:Software metrics]]