Function points: Meaning, Criticisms & Real-World Uses

What Are Function Points?

Function points are a standardized unit of measure used in software engineering to quantify the functional size of a software system based on the functionality it provides to the end-user. This metric falls under the broader category of software estimation metrics and is crucial for project management and cost estimation in information technology (IT) and software development. Unlike traditional measures like lines of code, function points focus on the observable features and functions of a software application rather than the underlying technical implementation or programming language. This makes function points a valuable tool for stakeholders, including business users and financial professionals, to understand the scope and complexity of a software project without needing technical expertise.

History and Origin

The concept of function points was introduced in the late 1970s by Allan J. Albrecht, an IBM engineer, to address the challenges of estimating and assessing productivity and costs in diverse software development environments⁵³, ⁵⁴, ⁵⁵. Albrecht's methodology aimed to evaluate software development from the perspective of functional requirements, rather than solely relying on lines of code, which can vary significantly across different programming languages and developers⁵¹, ⁵².

In 1986, a group of function point analysis users established the International Function Point Users Group (IFPUG). This non-profit organization has played a pivotal role in standardizing and enhancing Albrecht's original method, developing and maintaining the Function Point Counting Practices Manual (CPM), which serves as the global standard for function point analysis⁴⁷, ⁴⁸, ⁴⁹, ⁵⁰. IFPUG's efforts have contributed to the widespread adoption of function points as a recognized industry standard for measuring software value and functional size⁴⁴, ⁴⁵, ⁴⁶.

Key Takeaways

Function points measure the functional size of software from the user's perspective, independent of technology or programming language.
They are a key metric for estimating software development costs, schedules, and effort, and for assessing productivity and quality assurance.
The calculation involves identifying and weighting five core functional components: External Inputs, External Outputs, External Inquiries, Internal Logical Files, and External Interface Files.
Function points provide a standardized basis for benchmarking, contract negotiations, and evaluating return on investment in software projects.
While widely used, function points have limitations, particularly for certain types of software like multimedia applications or projects using agile methodologies with evolving business requirements.

Formula and Calculation

The calculation of function points involves two main steps: determining the Unadjusted Function Point (UFP) count and then applying a Value Adjustment Factor (VAF) to derive the Adjusted Function Point (AFP) count. The UFP is calculated by categorizing and weighting five fundamental components of the software application:

External Inputs (EI): Data or control information entering the system from outside (e.g., user login, data entry forms).
External Outputs (EO): Data or control information leaving the system (e.g., reports, error messages, GUI displays).
External Inquiries (EQ): A combination of input and output that retrieves data from internal or external files without altering them (e.g., a search query and its results).
Internal Logical Files (ILF): User-identifiable logical groups of data or control information residing within the application's boundary (e.g., a customer master file).
External Interface Files (EIF): User-identifiable logical groups of data or control information referenced by the application but maintained by another application (e.g., a shared database from another system).⁴⁰, ⁴¹, ⁴², ⁴³

Each of these components is classified by complexity (simple, average, or complex) based on the number of data element types (DETs) and record element types (RETs) they involve, and then assigned a specific weight.

The formula for the Unadjusted Function Point (UFP) count is:

\text{UFP} = \sum (\text{EI} \times W_{EI}) + (\text{EO} \times W_{EO}) + (\text{EQ} \times W_{EQ}) + (\text{ILF} \times W_{ILF}) + (\text{EIF} \times W_{EIF})

Where:

(\text{EI}), (\text{EO}), (\text{EQ}), (\text{ILF}), (\text{EIF}) represent the count of each component type.
(W) represents the corresponding weighting factor for each component, based on its complexity. These weights are standardized by IFPUG.

After calculating the UFP, a Value Adjustment Factor (VAF) is determined by assessing 14 General System Characteristics (GSCs) that describe the overall complexity of the application and its environment (e.g., data communication, distributed processing, performance objectives, reusability, maintainability). Each GSC is rated on a scale from 0 (not applicable) to 5 (essential), and their sum is used to calculate the Degree of Influence (DI).

The formula for the Value Adjustment Factor (VAF) is:

\text{VAF} = 0.65 + (0.01 \times \text{DI})

Where:

(\text{DI}) is the sum of the ratings for the 14 General System Characteristics.

Finally, the Adjusted Function Point (AFP) count is calculated as:

\text{AFP} = \text{UFP} \times \text{VAF}

This AFP value provides a refined measure of the software's functional size, considering both its core functional components and the environmental and technical complexities.

Interpreting Function Points

Interpreting function points provides critical insights into the scope, complexity, and resource requirements of a software project. A higher function point count generally indicates a larger and more complex application, implying greater effort, time, and cost for its development and maintenance.

Software development teams and project managers use function points to:

Estimate effort and schedule: By correlating historical data (e.g., person-hours per function point) with the estimated function point count of a new project, organizations can predict the required development effort and project timeline.
Measure productivity: Function points enable the comparison of productivity across different projects, teams, or even organizations by normalizing the output. For example, "function points per month" can be a key productivity metric.
Benchmark performance: Organizations can use function point data to benchmark their development performance against industry averages or best practices, identifying areas for process improvement.
Negotiate contracts: For outsourcing or vendor contracts, function points provide an objective and technology-independent basis for defining the scope of work and negotiating costs, facilitating clear communication of business requirements.

For financial stakeholders, function points offer a tangible measure that connects technical software development to quantifiable business value. This allows for more informed budgeting and resource allocation, enabling a clearer understanding of the expected return from software investments.

Hypothetical Example

Imagine a company, "DiversiFin Tech," is developing a new online financial planning portal for its clients. The portal will allow users to input personal financial data, view customized reports, inquire about investment options, and integrate with external banking systems.

Let's estimate the function points for a core module of this portal, the "User Profile Management" system:

Step 1: Identify and Count Functional Components (UFP)

External Inputs (EI):
- User Registration (Simple) = 1
- Profile Update (Average) = 1
- Password Reset (Simple) = 1
- Total EI = 3
External Outputs (EO):
- Registration Confirmation Email (Simple) = 1
- Profile Summary Display (Average) = 1
- Total EO = 2
External Inquiries (EQ):
- View Profile Details (Average) = 1
- Check Account Status (Simple) = 1
- Total EQ = 2
Internal Logical Files (ILF):
- User Data Database (Complex) = 1
- Security Log File (Simple) = 1
- Total ILF = 2
External Interface Files (EIF):
- Integration with CRM System (Complex) = 1
- Total EIF = 1

Step 2: Calculate Unadjusted Function Points (UFP)

Using simplified IFPUG average weighting factors for this example (actual weights vary by complexity): EI=4, EO=5, EQ=4, ILF=10, EIF=7

\text{UFP} = (3 \times 4) + (2 \times 5) + (2 \times 4) + (2 \times 10) + (1 \times 7)

\text{UFP} = 12 + 10 + 8 + 20 + 7 = 57 \text{ Unadjusted Function Points}

Step 3: Determine Value Adjustment Factor (VAF)

Assume after assessing the 14 General System Characteristics (GSCs), the sum of their ratings (DI) is 30.

\text{VAF} = 0.65 + (0.01 \times 30)

\text{VAF} = 0.65 + 0.30 = 0.95

Step 4: Calculate Adjusted Function Points (AFP)

\text{AFP} = 57 \times 0.95 = 54.15 \text{ Adjusted Function Points}

This calculation gives DiversiFin Tech a standardized functional size for their User Profile Management module. With historical data on how many hours it typically takes to develop one function point, they can then estimate the effort and budgeting required for this specific part of the portal, contributing to overall financial planning for the project.

Practical Applications

Function points are widely applied across various facets of software development and IT management, extending beyond initial cost estimation.

Project Planning and Tracking: Function points serve as a foundational metric for software development project planning. They provide a technology-agnostic measure of project size, allowing managers to estimate effort, resources, and timelines more accurately, regardless of the programming language or development environment. This enables better resource allocation and helps in tracking progress against planned deliverables.
Vendor and Outsourcing Management: In contracts with external vendors or outsourcing partners, function points offer an objective basis for defining project scope and pricing. Governments and large organizations often mandate the use of functional sizing, like function points, as a prerequisite for bidding on IT contracts, ensuring transparency and comparability across proposals³⁹. This minimizes disputes over scope creep and ensures both parties have a shared understanding of the delivered functionality.
Benchmarking and Process Improvement: By collecting function point data across multiple projects, organizations can establish internal benchmarks for productivity (e.g., function points per person-month) and quality (e.g., defects per function point). This data analysis helps identify areas for process improvement within their software engineering practices, leading to more efficient and higher-quality outcomes. The International Function Point Users Group (IFPUG) further facilitates this by providing standardized counting practices and data for industry comparisons. https://www.ifpug.org/
Portfolio Management: At a strategic level, function points can be used to assess the functional size of an entire software portfolio. This provides insights into the organization's total software assets, aiding in strategic financial planning for maintenance, enhancements, and future investments.

Limitations and Criticisms

Despite their widespread use and advantages, function points are not without limitations and have faced several criticisms.

One primary criticism is the manual and labor-intensive nature of counting function points³⁸. Accurately determining the number and complexity of external inputs, outputs, inquiries, and files requires a detailed understanding of the system's business requirements and can be time-consuming, especially for large and complex applications³⁶, ³⁷. This can lead to inconsistencies if different individuals perform the counting without rigorous adherence to the IFPUG Counting Practices Manual³⁵.

Furthermore, function point analysis primarily focuses on functional requirements and may not adequately capture the effort associated with non-functional requirements (NFRs) such as performance, security, usability, or complex system integration³², ³³, ³⁴. For instance, a system with high security demands or intensive graphical user interface (GUI) elements might have a relatively low functional point count but require significant development effort due to its NFRs. This limitation becomes particularly pronounced in modern software environments involving multimedia applications or real-time systems, where non-functional aspects heavily influence complexity and effort²⁹, ³⁰, ³¹.

Another challenge arises when applying function points to agile methodologies. Agile development emphasizes iterative and incremental delivery with evolving requirements, which can make it difficult to define and count all function points upfront in the early stages of a project²⁸. The traditional function point counting process often requires a relatively stable set of requirements, which contrasts with the dynamic nature of agile sprints and frequent changes²⁷. Consequently, applying traditional function point analysis to agile projects may not yield suitable results, leading to a need for adaptations or alternative sizing methods like story points²⁶.

Finally, while function points provide a measure of size, they do not directly measure the efficiency or capacity of the development team²⁵. The actual cost and duration of a project can still vary significantly depending on the team's productivity, skill level, and the organizational environment²⁴. A study discussing these limitations can be found on ResearchGate: "Limitations of Function Point Analysis in Multimedia Software/Application Estimation". https://www.researchgate.net/publication/330058882_Limitations_of_Function_Point_Analysis_in_Multimedia_SoftwareApplication_Estimation

Function Points vs. Lines of Code

Function points and lines of code (LOC) are two distinct metrics used to measure the size of software, each with its own strengths and weaknesses. The fundamental difference lies in their perspective: function points are a user-oriented measure of functional size, while lines of code are a developer-oriented measure of physical size.

Feature	Function Points (FP)	Lines of Code (LOC)
Measurement Focus	Business functionality delivered to the user²¹, ²², ²³	Number of physical or logical lines of source code¹⁹, ²⁰
Dependency	Language-independent; technology-independent¹⁶, ¹⁷, ¹⁸	Language-dependent; varies with coding style¹³, ¹⁴, ¹⁵
Early Estimation	Can be estimated earlier in the development lifecycle based on requirements¹¹, ¹²	Typically available later in the development cycle, once code is written¹⁰
Objectivity	More objective for comparing projects across different technologies⁸, ⁹	Less objective for comparisons due to language and style variations⁷
User Comprehension	Easier for non-technical stakeholders to understand and relate to⁵, ⁶	Difficult for non-technical stakeholders to interpret⁴
Scope Change	Adapts well to changes in functional scope³	Less adaptable to changes in functional scope without recounting code

While LOC is simple to count and provides a measure of developer productivity within a specific language, it struggles with consistency and comparability across different programming languages or projects¹, ². A program written in a high-level language might have fewer LOC than the same functionality implemented in a low-level language, yet both deliver the same user value. Function points, by focusing on what the software does for the user, offer a more consistent and robust measure for cross-project comparisons, strategic planning, and managing external contracts. Both metrics, however, can be valuable when used appropriately within their respective contexts. A more detailed comparison is available from GeeksforGeeks: "Differentiate between LOC and Function Point in Software Engineering". https://www.geeksforgeeks.org/differentiate-between-loc-and-function-point-in-software-engineering/

FAQs

What is the primary purpose of using function points?

The primary purpose of function points is to measure the functional size of software applications from a user's perspective, independent of the programming language or technology used. This helps in more accurate cost estimation, project management, and productivity measurement in software development.

How are function points different from lines of code (LOC)?

Function points measure the functionality delivered to the user, making them language-independent and valuable for early project sizing. Lines of code measure the physical size of the code, which is highly dependent on the programming language and coding style, and typically used later in the development process.

Can function points be used for agile software development?

Traditional function points can face challenges with agile methodologies due to their emphasis on detailed upfront requirements, which conflicts with agile's iterative and evolving nature. However, adapted approaches or complementary metrics, like Simple Function Points, are being explored to make function points more compatible with agile environments.

Who typically performs a function point count?

Function point counts are typically performed by trained and certified function point specialists or analysts. Organizations like the International Function Point Users Group (IFPUG) provide guidelines and certification programs to ensure consistency and accuracy in counting practices.

What are the benefits of using function points for financial professionals?

For financial professionals, function points provide a standardized, objective metric to assess the scope and complexity of IT projects. This aids in better budgeting, resource allocation, evaluating development costs, and making informed decisions regarding software investments and potential return on investment.