Function point

Last updated December 03, 2024

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

FiSMA: ISO/IEC 29881:2010 Information technology – Systems and software engineering – FiSMA 1.1 functional size measurement method.
IFPUG: ISO/IEC 20926:2009 Software and systems engineering – Software measurement – IFPUG functional size measurement method.
Mark-II: ISO/IEC 20968:2002 Software engineering – Ml II Function Point Analysis – Counting Practices Manual
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: ISO/IEC 19761:2011 Software engineering. A functional size measurement method.
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 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:

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.^[5] 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^[6]

Contrast

The use of function points in favor of lines of code 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 (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.^[7] C. Jones offers a method of correcting this in his work.^[8]
LOC measures are not useful during early project phases where estimating the number of lines of code that will be delivered is challenging. However, Function Points can be derived from requirements and therefore are useful in methods such as estimation by proxy.

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]

Related Research Articles

The Object Management Group (OMG) is a computer industry standards consortium. OMG Task Forces develop enterprise integration standards for a range of technologies.

Maintainability is the ease of maintaining or providing maintenance for a functioning product or service. Depending on the field, it can have slightly different meanings.

In software engineering and development, a software metric is a standard of measure of a degree to which a software system or process possesses some property. Even if a metric is not a measurement, often the two terms are used as synonyms. Since quantitative measurements are essential in all sciences, there is a continuous effort by computer science practitioners and theoreticians to bring similar approaches to software development. The goal is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in schedule and budget planning, cost estimation, quality assurance, testing, software debugging, software performance optimization, and optimal personnel task assignments.

Source lines of code (SLOC), also known as lines of code (LOC), is a software metric used to measure the size of a computer program by counting the number of lines in the text of the program's source code. SLOC is typically used to predict the amount of effort that will be required to develop a program, as well as to estimate programming productivity or maintainability once the software is produced.

In the context of software engineering, software quality refers to two related but distinct notions:

ISO/IEC 9126Software engineering — Product quality was an international standard for the evaluation of software quality. It has been replaced by ISO/IEC 25010:2011.

This is an alphabetical list of articles pertaining specifically to software engineering.

SEER for Software (SEER-SEM) is a project management application used to estimate resources required for software development.

Software safety is an engineering discipline that aims to ensure that software, which is used in safety-related systems, does not contribute to any hazards such a system might pose. There are numerous standards that govern the way how safety-related software should be developed and assured in various domains. Most of them classify software according to their criticality and propose techniques and measures that should be employed during the development and assurance:

The International Function Point Users Group (IFPUG) is a US-based organization with worldwide chapters of Function point analysis metric software users. It is a non-profit, member-governed organization founded in 1986.

Software sizing or software size estimation is an activity in software engineering that is used to determine or estimate the size of a software application or component in order to be able to implement other software project management activities. Size is an inherent characteristic of a piece of software just like weight is an inherent characteristic of a tangible material.

Programming productivity describes the degree of the ability of individual programmers or development teams to build and evolve software systems. Productivity traditionally refers to the ratio between the quantity of software produced and the cost spent for it. Here the delicacy lies in finding a reasonable way to define software quantity.

Software measurement is a quantified attribute of a characteristic of a software product or the software process. It is a discipline within software engineering. The process of software measurement is defined and governed by ISO Standard ISO 15939.

The MK II Method is one of the software sizing methods in functional point group of measurements. This is a method for analysis and measurement of information processing applications based on end user functional view of the system. The MK II Method is one of five currently recognized ISO standards for Functionally sizing software.

Weighted Micro Function Points (WMFP) is a modern software sizing algorithm which is a successor to solid ancestor scientific methods as COCOMO, COSYSMO, maintainability index, cyclomatic complexity, function points, and Halstead complexity. It produces more accurate results than traditional software sizing methodologies, while requiring less configuration and knowledge from the end user, as most of the estimation is based on automatic measurements of an existing source code.

Parasoft C/C++test is an integrated set of tools for testing C and C++ source code that software developers use to analyze, test, find defects, and measure the quality and security of their applications. It supports software development practices that are part of development testing, including static code analysis, dynamic code analysis, unit test case generation and execution, code coverage analysis, regression testing, runtime error detection, requirements traceability, and code review. It's a commercial tool that supports operation on Linux, Windows, and Solaris platforms as well as support for on-target embedded testing and cross compilers.

SNAP is the acronym for "Software Non-functional Assessment Process," a measurement of the size of non-functional software. The SNAP sizing method complements ISO/IEC 20926:2009, which defines a method for the sizing of functional software. SNAP is a product of the International Function Point Users Group (IFPUG), and is sized using the “Software Non-functional Assessment Process (SNAP) Assessment Practices Manual” (APM) now in version 2.4. Reference “IEEE 2430-2019-IEEE Trial-Use Standard for Non-Functional Sizing Measurements,” published October 19, 2019. Also reference ISO standard “Software engineering — Trial use standard for software non-functional sizing measurements,”, published October 2021. For more information about SNAP please visit YouTube and search for "IFPUG SNAP;" this will provide a series of videos overviewing the SNAP methodology.

Bill Curtis is a software engineer best known for leading the development of the Capability Maturity Model and the People CMM in the Software Engineering Institute at Carnegie Mellon University, and for championing the spread of software process improvement and software measurement globally. In 2007 he was elected a Fellow of the Institute of Electrical and Electronics Engineers (IEEE) for his contributions to software process improvement and measurement. He was named to the 2022 class of ACM Fellows, "for contributions to software process, software measurement, and human factors in software engineering".

COSMIC functional size measurement is a method to measure a standard functional size of a piece of software. COSMIC is an acronym of COmmon Software Measurement International Consortium, a voluntary organization that has developed the method and is still expanding its use to more software domains.

References

↑ Thomas Cutting, Estimating Lessons Learned in Project Management – Traditional, Retrieved on May 28, 2010
↑ 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)
↑ OMG/CISQ Specification "Automated Function Points", February 2013, OMG Document Number ptc/2013-02-01 http://www.omg.org/spec/AFP/1.0
↑ 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.
↑ Engineering Function Points and Tracking System, Software Technology Support Center Archived 2010-11-11 at the Wayback Machine , Retrieved on May 14, 2008
↑ 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.
↑ Jones, C. and Bonsignour O. The Economics of Software Quality, Addison-Wesley, 2012. pp. 105-109.
↑ Jones, C. Applied Software Measurement: Assuring Productivity and Quality. McGraw-Hill. June 1996.
↑ Albrecht, A. Software Function, Source Lines of Code, and Development Effort Estimation – A Software Science Validation. 1983.
↑ Symons, C.R. "Function point analysis: difficulties and improvements." IEEE Transactions on Software Engineering. January 1988. pp. 2-111.
↑ 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.
↑ 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.
↑ Symons, C. Software sizing and estimating: Mk II FPA (Function Point Analysis). John Wiley & Sons, Inc. New York, 1991
↑ Demarco, T. "An algorithm for sizing software products." ACM Sigmetrics Performance Evaluation Review. 1984. Volume 12, Issue 2. pp 13-22.
↑ 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.
↑ 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

The International Function Point Users Group (IFPUG)

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.

[1] Thomas Cutting, Estimating Lessons Learned in Project Management – Traditional, Retrieved on May 28, 2010

[ISO/IEC_14143-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.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]