A function point (FP) is a unit of measurement used in [[software engineering]] to express the amount of functionality a software system provides to its users. Developed by Allan Albrecht at [[IBM]] in the late 1970s, Function Point Analysis (FPA) is a method for quantifying software functionality based on the system's external user view, independent of the technology or programming language used. It serves as a primary metric for estimating [[software project]] size, effort, cost, and schedule, and for measuring [[software productivity]] and quality.
History and Origin
Allan Albrecht introduced Function Point Analysis in 1979 while working at IBM. He sought a method to measure software size that was independent of source code lines and could be used early in the software development lifecycle when code was not yet available. The initial goal was to improve software project estimation and make comparisons across different projects and technologies more objective. The [[International Function Point Users Group]] (IFPUG) was later established to standardize the methodology, creating the IFPUG FPA Counting Practices Manual, which is now the de facto standard.Core Concept
Function points quantify the functionality that a software system delivers to its users. Instead of focusing on technical implementation details (like lines of code), FPA examines the logical design of the system from an external perspective, specifically identifying the data and transactional functions that users perceive. The underlying principle is that the amount of functionality directly relates to the effort required to develop the software.Components of Function Point Analysis
FPA involves two main categories of functions: Data Functions and Transactional Functions. Each function type is classified based on its complexity (low, average, high) and assigned a specific weight.Data Functions
Data functions represent the data that the application maintains or references.- Internal Logical File (ILF): A user-identifiable group of logically related data or control information that resides entirely within the application's boundary and is maintained through one or more of the application's elementary processes. It represents a major logical collection of data or a control file for the application.
- External Interface File (EIF): A user-identifiable group of logically related data or control information that is referenced by the application, but maintained by another application. The EIF is an ILF for another application and is external to the boundary of the application being counted.
Transactional Functions
Transactional functions describe the processes that move data or control information across the application boundary.- External Input (EI): An elementary process that processes data or control information that enters the application boundary from outside. Its primary purpose is to maintain one or more ILFs and/or to change the behavior of the system.
- External Output (EO): An elementary process that sends data or control information outside the application boundary. Its primary purpose is to present information to a user through processing logic other than, or in addition to, the retrieval of data. An EO may also maintain one or more ILFs.
- External Inquiry (EQ): An elementary process that sends data or control information outside the application boundary. Its primary purpose is to retrieve data or control information from an ILF or EIF and present it to a user. Unlike an EO, an EQ does not update any ILFs.
Function Point Counting Process (IFPUG FPA)
The standard IFPUG FPA counting process typically involves the following steps:-
Determine the Type of Function Point Count:
- Development Project Function Point Count: Measures the size of the software being developed.
- Enhancement Project Function Point Count: Measures the size of the changes (additions, deletions, modifications) to an existing application.
- Application Function Point Count: Measures the size of an installed application (baseline).
-
Determine the Application Boundary: Clearly define what constitutes the application under consideration and what lies outside its scope. This step is crucial for accurate counting.
-
Identify and Count Data Functions: Identify all ILFs and EIFs within the application boundary. Assign a complexity level (low, average, high) to each based on the number of Data Element Types (DETs) and Record Element Types (RETs) they contain, according to predefined rules. Each complexity level has an associated weight (e.g., ILF: Low=7, Avg=10, High=15; EIF: Low=5, Avg=7, High=10).
-
Identify and Count Transactional Functions: Identify all EIs, EOs, and EQs. Assign a complexity level (low, average, high) to each based on the number of DETs and File Types Referenced (FTRs) they interact with. Each complexity level also has an associated weight (e.g., EI: Low=3, Avg=4, High=6; EO: Low=4, Avg=5, High=7; EQ: Low=3, Avg=4, High=6).
-
Calculate Unadjusted Function Points (UFP): Sum the weighted counts of all ILFs, EIFs, EIs, EOs, and EQs. This total represents the raw functional size of the application before considering general system characteristics.
-
Determine the Value Adjustment Factor (VAF): Evaluate 14 General System Characteristics (GSCs) on a scale of 0 (no influence) to 5 (strong influence). These GSCs assess factors like data communications, distributed data processing, performance, usability, operational ease, multiple site use, facilitative change, etc. The sum of these 14 values (Total Degree of Influence, TDI) is used to calculate the VAF:
VAF = (TDI * 0.01) + 0.65. -
Calculate Adjusted Function Points (AFP): Multiply the UFP by the VAF:
AFP = UFP * VAF. The AFP represents the final function point count, reflecting the functional size adjusted for the general characteristics of the application.
Benefits of Function Point Analysis
- Technology-Independent: FPs measure functionality, not lines of code, making them applicable across different programming languages, platforms, and development methodologies.
- User-Oriented: FPA focuses on the user's perspective of functionality, making it easier to relate to business requirements.
- Early Estimation: FPs can be counted from high-level requirements or design documents, allowing for project estimates much earlier in the lifecycle.
- Basis for Productivity Measurement: By relating FPs to effort (person-hours) or cost, organizations can measure and compare productivity across projects and teams.
- Benchmarking: FPs facilitate benchmarking against industry averages for productivity, quality, and cost.
- Contract Negotiation: FPs can be used as a basis for fixed-price contracts for software development.
Limitations and Criticisms
- Subjectivity: The process of identifying components and assigning complexity can be subjective, leading to variations in counts between different analysts. Standardization by IFPUG aims to minimize this.
- Requires Expertise: Accurate FPA requires trained and experienced counters to ensure consistent and reliable results.
- Non-Functional Requirements: FPA primarily focuses on functional size and may not adequately capture the effort associated with non-functional requirements (e.g., performance, security, reliability, scalability).
- Initial Overhead: The initial investment in training and establishing a consistent counting process can be significant.
- Updates for Agile: While adaptable, traditional FPA was designed for more waterfall-like approaches. Adapting it to agile methodologies requires careful consideration.
Variations and Related Concepts
Several other function point-like methods have emerged, often addressing perceived limitations or adapting FPA to specific contexts:- COSMIC Function Points (CFP): A second-generation functional size measurement method, designed to be more suitable for real-time systems and component-based development.
- NESMA Function Points: A variant developed by the Netherlands Software Metrics Association, offering specific guidelines for enhancement projects.
- Mark II Function Points: Another early method developed in the UK.
- Feature Points: An extension of FPA that adds an algorithm component to account for complex algorithmic logic.
Function points remain a widely recognized and valuable tool in software project management and estimation, providing a standardized, technology-independent measure of software size.