Hubbry Logo
search
logo
Function point avatar
Function point
Function point
current hub
F

Function point

logo
Community Hub0 Subscribers
Read side by side
Function point
View on Wikipedia
from Wikipedia

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

[edit]

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

[edit]

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

[edit]

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

[edit]

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

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Function point

View on Grokipedia
from Grokipedia
Function point analysis (FPA) is a standardized method for measuring the functional size of a software application based on the functionality it provides to the end user, derived directly from user requirements rather than physical attributes like lines of code.[1] Developed to offer a technology-independent metric, FPA quantifies software size in terms of function points, which represent units of delivered functionality, enabling consistent comparisons across projects and lifecycles.[1] The technique was pioneered by Allan J. Albrecht at IBM in the late 1970s, with the initial proposal presented in October 1979 as a way to assess application development productivity from the end-user's viewpoint.[2] Albrecht's approach addressed limitations in traditional metrics by focusing on logical functionality, such as data processing and user interactions, rather than implementation details.[3] Since its introduction, FPA has evolved into an international standard, formalized by the International Function Point Users Group (IFPUG) and aligned with ISO/IEC 14143-1:2007 for functional size measurement.[1] At its core, FPA involves identifying and counting five basic function types: external inputs (EI) for data entering the system, external outputs (EO) for data leaving the system, external inquiries (EQ) for retrieving data from the system and sending it to the user without maintaining data storage, internal logical files (ILF) for user-maintainable data groups, and external interface files (EIF) for data maintained by other systems.[1] Each type is assigned a weight based on its complexity (low, average, or high), summed to yield unadjusted function points (UFP), and then adjusted by a value adjustment factor (VAF) that accounts for 14 general system characteristics like performance and reusability.[4] The resulting adjusted function points provide a reliable size metric for estimating effort, costs, schedules, and productivity.[1] FPA's primary applications include project estimation, benchmarking software productivity (e.g., effort per function point), quality assessment (e.g., defects per function point), and requirements management throughout the software development lifecycle.[1] Governed by IFPUG's Function Point Counting Practices Manual (CPM), which complies with ISO 20926:2009, the method ensures repeatability and is supported by certification programs like Certified Function Point Specialist (CFPS).[1] Its enduring relevance lies in normalizing metrics across diverse technologies, from legacy systems to modern agile environments, making it a cornerstone of software measurement practices.[2]

Introduction

Definition and Purpose

A function point (FP) is a standardized unit of measurement used to quantify the functional size of software applications from the perspective of the end user. It focuses on the functionality delivered to users, such as the processing of data inputs, outputs, and inquiries, rather than the technical details of implementation like lines of code or hardware specifics.[1][5] The primary purpose of function points is to provide a technology-independent metric for estimating software development effort, costs, and productivity across the entire software lifecycle. By measuring the size based on user requirements, function points enable consistent comparisons between projects, regardless of the programming language, platform, or development methodology employed. This approach supports benchmarking, resource allocation, and performance analysis in software engineering.[1][6] Key principles of function point analysis emphasize counting user-oriented functions, including external inputs, external outputs, external inquiries, internal logical files, and external interface files, to capture the business value provided by the software. Unlike traditional code-based metrics, which vary with implementation choices, function points prioritize the logical functionality derived from specifications, promoting a stable and repeatable measure. Developed in the 1970s to overcome the shortcomings of code volume metrics in managing large-scale projects, this method ensures assessments remain aligned with user needs and organizational goals.[1][7]

Historical Development

Function point analysis originated in the late 1970s at IBM, where Allan J. Albrecht developed it as a method to measure software productivity independent of programming languages or technologies. Albrecht introduced the concept in October 1979 during an internal presentation and subsequently detailed it in his 1979 paper "Measuring Application Development Productivity," presented at the Joint SHARE/GUIDE/IBM Application Development Symposium.[8] This approach addressed limitations in traditional metrics by focusing on five core function types: external inputs, outputs, inquiries, internal logical files, and external interface files.[2] The metric gained broader adoption in the mid-1980s through the formation of the International Function Point Users Group (IFPUG) in 1987, a non-profit organization dedicated to standardizing and promoting function point practices.[9] IFPUG released its first Counting Practices Manual (CPM) in 1988 (version 1.0), providing guidelines for consistent application of Albrecht's method, with subsequent versions refining rules for accuracy and interoperability.[10] During the 1980s and 1990s, refinements addressed ambiguities in counting complex systems, driven by user feedback and committee work, leading to more robust standardization; influential figures like Capers Jones further advanced its global promotion through research on software economics and productivity benchmarking using function points.[11] Initially applied in mainframe environments for project estimation at IBM and early adopters, function points expanded in the 1990s to client-server architectures as organizations sought technology-agnostic sizing. By the 2000s, adaptations extended its use to web and distributed applications, culminating in international recognition with the adoption of IFPUG's method in ISO/IEC 20926:2009, which formalized function point analysis as a standard for software functional size measurement.[12]

Function Point Analysis Methodology

Core Components

Function point analysis relies on five primary base functional components to quantify the functional size of software from the user's perspective. These components—external inputs (EI), external outputs (EO), external inquiries (EQ), internal logical files (ILF), and external interface files (EIF)—capture the elementary processes and data entities that deliver functionality across the application's boundary. Each component is identified and weighted based on specific criteria to ensure consistent measurement.[13] External inputs (EI) are elementary processes that process data or control information entering from outside the application boundary into the system, typically to create, update, or delete data in internal logical files or to alter system behavior without maintaining data. Examples include data entry screens that validate and store user information. EIs cross the boundary once and involve processing logic.[13][10] External outputs (EO) are elementary processes that generate and send derived data or control information to an external destination, often involving calculations, derivations, or maintenance of internal logical files during processing. For instance, a report generated from multiple data sources with computed totals qualifies as an EO. EOs cross the boundary once and may include formatting or aggregation.[13][10] External inquiries (EQ) represent the simplest transactional components, consisting of an elementary process that retrieves data from internal sources, applies no derivations or maintenance, and presents the information externally via input and output crossing the boundary. A search screen displaying matching records without updates exemplifies an EQ. EQs emphasize read-only access for information retrieval.[13][10] Internal logical files (ILF) are user-identifiable groups of logically related data maintained entirely within the application's boundary through its elementary processes, such as adding, changing, or deleting records. An ILF might be a customer database table where the application handles all CRUD operations. ILFs do not include temporary data or system-generated files without user recognition.[13][10] External interface files (EIF) are user-identifiable groups of logically related data referenced by the application but maintained by another application outside its boundary; the counted application only reads or derives data from them without maintenance rights. For example, an inventory system referencing a shared supplier catalog maintained elsewhere counts as an EIF. EIFs support integration but exclude any update capabilities within the scope.[13][10] Complexity for these components is classified as low, average, or high using two key metrics: data element types (DETs), which are unique, user-recognizable, non-recursive fields of data crossing boundaries or maintained; file types referenced (FTRs), which count each distinct ILF or EIF involved in processing (one per read or maintain action); and record element types (RETs), which are user-recognizable subgroups of data within an ILF or EIF (e.g., one for the primary record plus additional for subtypes or associations). Transactional functions (EI, EO, EQ) use DETs and FTRs, while data functions (ILF, EIF) use DETs and RETs. Weights, expressed as unadjusted function points, are assigned via standardized matrices.[13][10] The complexity matrix for external inputs (EI) is as follows:
DETs \ FTRs0-123+
1-4Low (3)Low (3)Avg (4)
5-15Low (3)Avg (4)High (6)
16+Avg (4)High (6)High (6)
[13] For external outputs (EO) and external inquiries (EQ), the shared matrix is:
DETs \ FTRs0-12-34+
1-5LowLowAvg
6-19LowAvgHigh
20+AvgHighHigh
Weights: EO—Low: 4, Average: 5, High: 7; EQ—Low: 3, Average: 4, High: 6.[13] The complexity matrix for internal logical files (ILF) and external interface files (EIF) is:
DETs \ RETs12-56+
1-19LowLowAvg
20-50LowAvgHigh
51+AvgHighHigh
Weights: ILF—Low: 7, Average: 10, High: 15; EIF—Low: 5, Average: 7, High: 10.[13]

Calculation Process

The calculation of function points begins with identifying the application boundary, which defines the scope of the software being measured by delineating what functionality is internal to the application versus external interfaces or other systems. This boundary is determined from the user's perspective, focusing on the logical design and functionalities perceivable by the end user, ensuring only relevant elements are counted within the project's scope.[1][12] Step 1 involves identifying and counting the five core function types—External Inputs (EIs), External Outputs (EOs), External Inquiries (EQs), Internal Logical Files (ILFs), and External Interface Files (EIFs)—using predefined complexity criteria such as the number of data element types and file type referenced, as detailed in the component definitions. Each identified function type is classified as low, average, or high complexity and assigned a corresponding weight: for example, low-complexity EIs are weighted at 3, average at 4, and high at 6. The Unadjusted Function Points (UFP) are then calculated as the sum of the weighted values across all components:
UFP=∑(EI weights)+∑(EO weights)+∑(EQ weights)+∑(ILF weights)+∑(EIF weights). \text{UFP} = \sum (\text{EI weights}) + \sum (\text{EO weights}) + \sum (\text{EQ weights}) + \sum (\text{ILF weights}) + \sum (\text{EIF weights}).
[1][10] Step 2 applies the Value Adjustment Factor (VAF) to account for general system characteristics influencing the software's complexity and value. The VAF is derived from 14 General System Characteristics (GSCs), each rated on a degree of influence scale from 0 (no influence) to 5 (strong influence), covering aspects such as data communications, performance, and reusability. The Total Degree of Influence (TDI) is the sum of these ratings (ranging from 0 to 70), and the VAF is computed as:
VAF=0.65+0.01×TDI, \text{VAF} = 0.65 + 0.01 \times \text{TDI},
yielding a multiplier between 0.65 and 1.35. The 14 GSCs are:
GSC NumberCharacteristicDescription Example
1Data communicationsExtent of communication facilities
2Distributed data processingDistribution of processing components
3PerformanceResponse or throughput specifications
4Operational environmentOperating system and network support
5Transaction rateNumber of transactions per time period
6Online data entryProportion of online versus batch
7End-user efficiencyEfforts to make system convenient
8Online updateProportion of updates in online mode
9Complex processingMathematical or statistical computations
10ReusabilityModularity for reuse
11Installation easeEase of converting and installing
12Operational easeEase of daily operations
13Multiple installationsNumber of sites for one application
14Facilitated changesEase of non-functional modifications
[1][12][14]
The Adjusted Function Points (AFP), representing the final functional size measure, are obtained by multiplying the UFP by the VAF:
AFP=UFP×VAF. \text{AFP} = \text{UFP} \times \text{VAF}.
[1][10] For example, consider a hypothetical project where the UFP totals 100 based on counted components. If the GSCs are rated such that the TDI is 35 (e.g., as shown in the table below for illustration), the VAF is 1.0, resulting in AFP = 100.
GSC NumberDegree of Influence (0-5)
13
22
34
41
50
63
75
84
92
103
112
123
131
142
Total (TDI)35
VAF = 0.65 + (35 × 0.01) = 1.0; AFP = 100 × 1.0 = 100.[1][10]

Standards and Variations

IFPUG Standards

The International Function Point Users Group (IFPUG) was formally established in 1986 to standardize and promote the function point analysis method originally developed by Allan Albrecht.[15] As a non-profit organization, IFPUG maintains the official guidelines for function point counting through its Counting Practices Manual (CPM), with the latest full release being version 4.3.1 in 2010, accompanied by subsequent minor updates and supplementary materials to ensure compliance with international standards.[1][16] The CPM provides detailed rules for function point analysis, including boundary setting, which defines the scope based on user requirements and applies across the software development life cycle.[1] Component identification involves categorizing functional elements such as external inputs, external outputs, external inquiries, internal logical files, and external interface files.[1] Complexity assessment evaluates each component using standard tables based on data elements and record elements types, assigning low, average, or high complexity weights.[1] The Value Adjustment Factor (VAF) is then applied to adjust the unadjusted function point count for general system characteristics, using a 14-factor model rated from 0 to 5.[1] IFPUG offers certification programs to validate expertise in function point analysis, including the Certified Function Point Specialist (CFPS), which requires a minimum score of 90% overall and 80% in each exam section covering definition, implementation, and case studies, demonstrating mastery of best practices.[17] The Certified Function Point Practitioner (CFPP) is an entry-level certification requiring 80% overall and 70% per section, focusing on foundational skills for accurate and consistent counting.[18] Both certifications are valid for three years, with options for extension pending major CPM updates.[18] The IFPUG method has been internationally standardized as ISO/IEC 20926:2009, which defines the rules, steps, and definitions for applying function point analysis as a functional size measurement technique, ensuring interoperability and consistency.[12] Post-2010 revisions and supplementary IFPUG publications, such as the 2012 Guide to IT and Software Measurement, address adaptations for modern technologies, including guidance on applying function points in agile development environments and cloud computing contexts to maintain relevance in iterative and distributed systems.[19][20]

Other Variants and Extensions

Beyond the International Function Point Users Group (IFPUG) standard, several alternative functional size measurement (FSM) methods have emerged to address specific limitations or extend applicability to diverse software domains. These variants maintain the core principle of quantifying functionality from the user's perspective but differ in components, weighting schemes, and target applications.[21][22] COSMIC Function Points (CFP), developed by the Common Software Measurement International Consortium in 1998, provide a second-generation FSM approach suitable for all software types, including real-time and embedded systems. Unlike IFPUG's focus on data and transactional functions, CFP measures size based on four elementary data movements—entries (input to the software), exits (output from the software), reads (retrieval of data without change), and writes (storage or update of data)—each assigned a fixed size of 1 CFP. This granularity enables precise sizing in layers or processes, making it ideal for non-business applications where IFPUG may undercount control processes. The method was formalized as the ISO/IEC 19761:2011 standard, emphasizing universality across development paradigms like Agile.[23][24] NESMA Function Points, originating in the Netherlands during the 1990s as a national standard under the Netherlands Software Metrics Association, closely resemble IFPUG but incorporate simplified estimation techniques for early project phases. It classifies functions similarly (internal logical files, external interface files, external inputs, external outputs, external inquiries) but applies predefined weights to standard function types, reducing subjectivity in counting for common business applications. This approach facilitates rapid indicative and estimated sizing, particularly valuable in European outsourcing contracts where contractual benchmarks require consistent, low-effort measurements. NESMA's guidelines align with ISO/IEC 24570:2018 for software enhancement projects.[25][26] Mark II Function Points, introduced in the late 1980s by Charles Symons and detailed in his 1991 publication, represent a UK-originated variant emphasizing transaction-oriented sizing for information systems. It counts logical transactions (external inputs, outputs, and inquiries) weighted by complexity, alongside an "information profile" that assesses data entities (logical data stores and access paths) to capture both processing and data aspects more holistically than early IFPUG versions. This method, standardized under ISO/IEC 20968:2002, supports broader applicability to transaction-heavy systems but has seen limited global adoption compared to newer standards.[27] Extensions to traditional function points have also adapted the metric for modern contexts. Web Function Points (WFP) extend IFPUG by incorporating web-specific elements, such as dynamic pages, hyperlinks, and multimedia content, to better size user interfaces and navigation in web applications where standard counts overlook interactivity. This variant assigns points to web objects like forms and static/dynamic pages, improving estimation accuracy for e-commerce and portal developments. Similarly, Agile Function Points tailor FSM for iterative environments by aligning counts with user stories and sprints, allowing incremental sizing that integrates with story points for velocity-based planning without disrupting agile workflows. These adaptations maintain core FSM principles while enhancing relevance to web and agile paradigms.[28][29]
VariantKey ComponentsWeighting SchemePrimary Applicability
COSMIC (CFP)Entries, Exits, Reads, WritesFixed (1 CFP each)Real-time, embedded, all software types
NESMAILF, EIF, EI, EO, EQ (similar to IFPUG)Predefined for standard functionsBusiness apps, outsourcing in Europe
Mark IILogical transactions, data entitiesComplexity-based (low/avg/high)Transactional info systems
IFPUG (baseline)ILF, EIF, EI, EO, EQComplexity-based (low/avg/high)Traditional business applications
This table highlights structural differences, with COSMIC's data-movement focus contrasting IFPUG's data-transaction emphasis, while NESMA streamlines for estimation and Mark II balances both.[30][31]

Applications and Benefits

Project Estimation and Sizing

Function points serve as a foundational metric for sizing software projects by quantifying the functional requirements in terms of user-valued features, enabling the estimation of development effort through established ratios. Practitioners typically multiply the total unadjusted or adjusted function points by an organization-specific or industry-derived person-hours per function point (PH/FP) ratio to forecast effort; for instance, industry benchmarks indicate ratios ranging from 5 to 20 PH/FP, with a global average of approximately 15 PH/FP derived from large-scale productivity studies across various languages and domains.[11][32] These ratios are calibrated from historical project data, accounting for factors like programming language and team experience, to provide reliable upfront sizing in the planning phase. For cost estimation, function points are converted to monetary values by applying productivity rates—such as function points per person-month (FP/PM)—to the effort estimate, incorporating labor rates and overheads; this approach is particularly valuable in fixed-price contracts, where it ensures scope clarity and reduces disputes over changes.[33] In benchmarking, organizations compare their cost per function point against industry repositories, revealing efficiencies or gaps; for example, the International Software Benchmarking Standards Group (ISBSG) data shows average costs varying by project type, aiding competitive analysis and vendor negotiations.[34] Productivity measurement leverages function points to track output as delivered FP per month or per developer, normalizing for functional complexity across projects and teams; this metric supports performance evaluation by highlighting variances from benchmarks like 7-13 FP/PM in mature organizations.[11] Function points integrate seamlessly with traditional waterfall methodologies for comprehensive upfront sizing during requirements analysis, while adaptations for agile environments involve estimating FP within user stories or epics to inform sprint capacities and velocity forecasting.[29] In practice, IBM's early adoption of function points for mainframe applications in the late 1970s, including those in finance and banking sectors, demonstrated their efficacy; a study of 24 IBM projects correlated function point counts with actual work-hours at coefficients of 0.86 or higher, achieving average relative errors below 32.3% in effort predictions and thus improving schedule accuracy.[35] Tools such as Function Point WORKBENCH automate the counting process, integrating with project management systems to streamline estimation and maintain audit trails for compliance in regulated industries.[36]

Advantages in Software Metrics

Function points offer a technology-independent measure of software size, focusing on the functionality delivered to users rather than implementation details such as programming language or platform. This independence allows for consistent assessment across diverse technological environments, unlike code-based metrics like lines of code (LOC), which vary significantly by language (e.g., requiring up to 2,200% more LOC in low-level languages compared to high-level ones for equivalent functionality).[1][11] A key advantage is the ability to apply function point analysis early in the software development lifecycle, during the requirements phase, enabling reliable predictions of effort, cost, and resources before design or coding begins. This early applicability supports proactive project planning and risk management, contrasting with metrics that depend on completed artifacts.[37][1] The standardized counting rules of function point analysis, as defined by international standards like ISO 20926:2009, minimize subjectivity and facilitate cross-project and cross-organizational comparisons. By providing a consistent framework for sizing, function points enable benchmarking against industry data, such as that from the ISBSG repository, to evaluate productivity and process improvements objectively.[1][37] Function points emphasize user value by quantifying the features and functionalities that directly address business needs and end-user requirements, aligning software metrics with delivered benefits rather than internal development artifacts. This focus helps organizations assess the economic value of software assets and prioritize enhancements based on functional impact.[37][1] Empirical evidence indicates that function points demonstrate reliability in predicting development effort across languages, with productivity rates stabilizing at consistent function points per month regardless of technological choices.[11] Function points exhibit strong scalability, effectively measuring software size from small applications to large enterprise systems, including maintenance and enhancement activities. This versatility supports portfolio management and normalization of metrics like productivity (e.g., function points per staff hour) across varying project scales.[37][1]

Comparisons with Other Metrics

Versus Lines of Code

Lines of code (LOC) is a traditional software metric that measures the physical or logical volume of source code in a program, typically counting statements while accounting for variations in programming languages; for instance, a single line in Java may equate to approximately 3-5 lines in C due to differences in syntax density and abstraction levels.[38][11] Function points (FP) differ fundamentally from LOC by focusing on the functional size of software from a user perspective, quantifying elements like inputs, outputs, inquiries, files, and interfaces, whereas LOC emphasizes implementation details such as coding style and language specifics; consequently, FP remains stable after the design phase and is unaffected by refactoring, while LOC counts fluctuate with code optimizations or rewrites.[11][39] FP offers advantages over LOC by eliminating language bias, enabling fair comparisons across technologies, and providing a more reliable basis for productivity measurement, such as consistent function points per person-month across development teams regardless of the programming language used.[11][40] In contrast, while LOC is simpler for quick code reviews in small-scale tasks, it can inflate counts through inclusions like comments or blank lines, leading to misleading size estimates; for example, the same application delivering 100 function points might require about 10,700 lines in COBOL but only around 5,300 lines in Python, highlighting how LOC distorts cross-language productivity assessments.[38][11] Empirical studies, including research by Capers Jones in the 2010s analyzing thousands of projects, demonstrate that FP correlates more strongly with development effort and costs than LOC, as evidenced by an IBM case where two compilers with identical function points showed vastly different LOC (17,500 in assembly versus 5,000 in PL/S) but FP better predicted the actual 2.4 times higher productivity in the higher-level language.[11] Approximate conversions between LOC and FP exist in models like COCOMO, which use language-specific factors to link the metrics, such as an average of 128 source lines of code per function point for the C language, though these ratios vary widely (e.g., 53 for Java) and are derived from historical data rather than universal rules.[41][42]

Versus Object-Oriented Metrics

Object-oriented metrics, such as the Chidamber-Kemerer (CK) suite, focus on internal design attributes to assess complexity and quality in OO software. The CK metrics include Weighted Methods per Class (WMC), which measures the complexity of a class's methods; Depth of Inheritance Tree (DIT), capturing inheritance hierarchy depth; Coupling Between Object Classes (CBO), quantifying inter-class dependencies; Response For a Class (RFC), indicating the number of methods invoked by a class; Number of Children (NOC), reflecting subclass proliferation; and Lack of Cohesion of Methods (LCOM), evaluating intra-class cohesion. These metrics emphasize structural elements like encapsulation, inheritance, and polymorphism, aiding in predicting maintainability and fault-proneness during design and implementation phases.[43] In contrast, function points (FP) measure external functionality from the user's perspective, counting data and transactional elements without regard to internal implementation details, making them paradigm-agnostic. CK metrics, however, delve into OO-specific internals, such as class coupling and method complexity, which FP overlooks. Use case points (UCP), another OO-oriented approach, share structural similarities with FP by estimating size from behavioral specifications but differ by weighting actors (simple, average, complex) and use case scenarios (simple, average, complex) based on interaction complexity, rather than FP's focus on elementary processes and data functions.[44] The UCP formula, UCP = UUCP × TCF × EF—where UUCP is the unadjusted use case points (sum of actor and use case weights), TCF is the technical complexity factor, and EF is the environmental factor—parallels FP's unadjusted function points multiplied by a value adjustment factor (VAF), but UCP better aligns with early-stage OO modeling via use case diagrams. FP excels in OO contexts by treating applications as black boxes, enabling consistent sizing across paradigms, including legacy system integrations where OO design varies. Hybrid methods combine FP's functional sizing with CK metrics for comprehensive lifecycle coverage, using FP for requirements and CK for design evaluation.[44][45] For instance, in greenfield OO projects, UCP facilitates estimation from initial use cases, while FP proves more suitable for hybrid environments involving non-OO legacy components, as it avoids OO-specific assumptions. Empirical studies on OO adaptations of FP demonstrate enhanced prediction capabilities; one validation of Object-Oriented Function Points (OOFP) reduced normalized mean squared error in size estimation from 38% to 15% by integrating OO entities like classes and inheritance with FP principles.[45] Despite these strengths, traditional FP can undervalue OO features such as inheritance, as it ignores internal hierarchies and reuse mechanisms that reduce development effort. To mitigate this, adaptations like Object-Oriented Function Points (OOFP) have been proposed, extending FP to explicitly count OO elements including associations, methods, and inheritance depths, thereby providing a more tailored measure for OO analysis and design.[46]

Criticisms and Limitations

Key Criticisms

One major criticism of function point analysis (FPA) is its subjectivity, particularly in defining system boundaries and assigning complexity weights to functions, leading to significant variations among counters. Studies on inter-rater reliability have shown mean relative errors (MRE) ranging from 10.5% for adjusted function point counts under IFPUG methodology to 17.3% under earlier variants, with some categories like external interfaces exhibiting errors up to 47.5%.[35] Further empirical work by Low and Jeffery reported coefficients of variation (standard deviation divided by mean) of 33.8% to 45.5% across projects, translating to assumed MREs of 23% to 31%, highlighting inconsistencies due to interpretive differences in counting rules.[35] The process of performing a full FPA count is often time-consuming, requiring detailed examination of requirements and transactions, which can make it impractical for small applications or iterative development. Manual counting methods demand substantial effort for activities like categorizing data functions and transactions, leading to proposals for simplified variants to reduce this burden.[47] In practice, this overhead can consume notable project resources, deterring adoption in fast-paced or resource-constrained environments. FPA is limited to measuring functional size based on user-visible features, ignoring non-functional aspects such as performance, usability, security, or reliability, which are critical in many systems. This focus on data movements and storage makes it particularly unsuitable for real-time or embedded software, where control processes and hardware interactions dominate but are underrepresented or capped at low weights (e.g., maximum 7 function points per transaction regardless of elaboration complexity).[48] For instance, standard rules fail to distinguish sub-processes in real-time tasks like engine diagnostics, treating them equivalently to simpler controls and underestimating overall effort.[49] Critics argue that FPA struggles with modern software paradigms, such as microservices, AI-driven applications, or mobile systems, where traditional user boundaries blur due to distributed architectures and algorithmic complexity. In these contexts, defining elementary processes becomes ambiguous, as interactions span services or involve non-deterministic elements like machine learning models, rendering standard counting guidelines inadequate. Empirical studies from the 2010s, including systematic mappings of effort estimation techniques, indicate low adoption of FPA in agile environments (less than 2% of reviewed works), with questions raised about its correlation to actual development effort amid iterative practices and evolving requirements.[50]

Mitigation Strategies

To address subjectivity in function point counting, the International Function Point Users Group (IFPUG) offers certification programs such as Certified Function Point Specialist (CFPS) and Certified Function Point Practitioner (CFPP), which provide standardized training on counting practices to ensure consistent application of rules and boundaries across projects.[17] These programs emphasize guidelines from the Counting Practices Manual (CPM), including detailed definitions for elementary processes and data functions, reducing variability by promoting uniform interpretation among practitioners.[1] Automation tools mitigate the time-intensive nature of manual counting by integrating with requirements management systems to generate function point estimates directly from specifications. The Object Management Group (OMG) Automated Function Points (AFP) specification enables consistent automated counting aligned with IFPUG practices, supporting integration with tools like requirements analyzers for rapid sizing during development.[51] Similarly, the Consortium for IT Software Quality (CISQ) automated function points use static code analysis to derive sizes post-implementation, while maintaining traceability to user requirements.[52] Hybrid approaches combine function points with agile techniques to handle dynamic environments, such as mapping unadjusted function points to story points for backlog prioritization, allowing teams to leverage functional size for velocity-based planning.[53] For non-functional elements not captured by traditional function points, IFPUG's Software Non-functional Assessment Process (SNAP) measures aspects like operational and performance requirements, providing a complementary size metric that integrates with function points for total effort estimation in agile iterations.[54] Updated variants like COSMIC function points address limitations in non-business applications, such as real-time or embedded systems, by measuring functional size through data movements (entries, exits, reads, writes) applicable to any software domain, offering a more neutral alternative to IFPUG's business-oriented focus.[21] Organizations can further mitigate inaccuracies through empirical calibration, adjusting COSMIC counts based on historical project data to tailor predictions to specific contexts.[55] Best practices include conducting peer reviews during counting to validate boundaries and resolve ambiguities, fostering structured analysis similar to requirements inspections and enhancing count reliability through collaborative verification.[56] Additionally, leveraging historical databases like the International Software Benchmarking Standards Group (ISBSG) repository allows benchmarking of function point counts against industry data, enabling organizations to calibrate productivity metrics and identify deviations for refinement. Ongoing research post-2015 validates function points in DevOps contexts through adjusted models, such as integrating automated function points with continuous integration pipelines to track size changes during agile-DevOps transformations, demonstrating improved productivity and quality metrics in high-velocity deployments.[57]

References

  1. Function Point Analysis (FPA) - IFPUG
  2. 40 Years of Function Points: Past, Present, Future - IFPUG
  3. Function Points - ScienceDirect.com
  4. What is Function Point Analysis (FPA)? - Total Metrics
  5. FPA - Function Point Analysis
  6. [PDF] Nesma on sizing - Part 1: Function Point Analysis (FPA)
  7. [PDF] A Generalized Structure for Function Point Analysis - Amazon S3
  8. [PDF] Measuring-Application-Development-Productivity.pdf - fattocs
  9. About Us - IFPUG - International Function Points Users Group
  10. (PDF) The IFPUG Function Point Counting Method - ResearchGate
  11. [PDF] Software Economics and Function Point Metrics - IFPUG
  12. ISO/IEC 20926:2009 - Software measurement
  13. [PDF] IFPUG Quick Refrence Card - Total Metrics
  14. Albrechts Function Point Method - Tutorials Point
  15. ISMA Conference - IFPUG - International Function Points Users Group
  16. Function Point Counting Practices Manual, Release 4.3.1 - MC LMS
  17. Certification Overview - International Function Points Users Group
  18. IFPUG - International Function Points Users Group
  19. The IFPUG Guide to IT and Software Measurement - Routledge
  20. [PDF] Functional Sizing of Agile Programs at US Department of ... - IFPUG
  21. COSMIC Software Sizing - open standard for software size ...
  22. Nesma
  23. https://cosmic-sizing.org/cosmic-fsm/
  24. ISO/IEC 19761:2011 - a functional size measurement method
  25. EFS - Nesma
  26. [PDF] mk ii function point analysis counting practices manual
  27. Function point measurement from Web application source code ...
  28. Counting Function Points for Agile / Iterative Software Development
  29. [PDF] Comparative Analysis of Functional Size Measurement Methods on ...
  30. [PDF] The use of function points in the industry | ISBSG
  31. An Analysis of Function Point Trends - QSM
  32. [PDF] The Role of Function Points in Software Development Contracts
  33. [PDF] Analysis of Project Cost per Function Point - ISBSG
  34. [PDF] AN EMPIRICAL STUDY OF FUNCTION POINTS ANALYSIS ...
  35. [PDF] Moving from Function Point WORKBENCH™ to SCOPE Project ...
  36. Benefits - IFPUG - International Function Points Users Group
  37. Software Complexity for Estimation - ISBSG
  38. [PDF] Function Point Analysis – A Cornerstone to Estimating - OSTI.GOV
  39. (PDF) Function Point Estimation Methods: A Comparative Overview
  40. Cost Estimation
  41. [PDF] The Application of Function Points to Predict Source Lines of Code ...
  42. [PDF] COCOMO II Model Definition Manual - Rose-Hulman
  43. A metrics suite for object oriented design | IEEE Journals & Magazine
  44. Predicting software effort from use case points: A systematic review
  45. Object-Oriented Function Points: An Empirical Validation
  46. A Function Point-Like Measure for Object-Oriented Software
  47. Estimating Software Functional Size via Machine Learning
  48. Using function points to measure and estimate real-time and ...
  49. Full Function Points for Embedded and Real-Time Software
  50. Software development effort estimation: a systematic mapping study
  51. Quantitative aspects of outsourcing deals
  52. About the Automated Function Points Specification Version 1.0
  53. CISQ's Automated Function Points: History and Calculation
  54. Using Function Points in Agile Projects - ResearchGate
  55. Software Non-Functional Assessment Process (SNAP) - IFPUG
  56. [PDF] Early Software Sizing with COSMIC: Practitioners Guide
  57. [PDF] www.ifpug.org
  58. [PDF] Using Analytics to Guide Improvement during an Agile–DevOps ...
User Avatar
No comments yet.