Albrecht’s Function Point Method

Function Point Analysis (Albrecht/IFPUG)

Function Point Analysis (FPA) is a standardized method for measuring software size based on its functionality delivered to the user. Developed by Allan Albrecht at IBM in the 1970s and later standardized by the International Function Point Users Group (IFPUG), it quantifies software based on logical functions from the user’s perspective, independent of the technology used for implementation. It aims to measure ‘what’ the software does, not ‘how’ it does it.

IFPUG Function Points are recognized under ISO/IEC standards (e.g., ISO/IEC 20926).

Core Concepts of Function Points

FPA identifies and classifies five types of elementary functional components based on the application’s boundary:

Data Functions:

• Internal Logical File (ILF): A user-identifiable group of logically related data maintained within the application boundary. Example: A file/table of customer records managed by the application.
• External Interface File (EIF): A user-identifiable group of logically related data referenced by the application but maintained outside its boundary (by another application). Example: Referencing a currency exchange rate table maintained by a separate financial system.

Transactional Functions:

• External Input (EI): An elementary process where data crosses the boundary from outside to inside, processing data to maintain one or more ILFs. Example: A screen function to add a new customer.
• External Output (EO): An elementary process where derived data crosses the boundary from inside to outside. Processing logic must be involved beyond simple data retrieval. Example: A report summarizing monthly sales, requiring calculations based on ILF data.
• External Inquiry (EQ): An elementary process with both input and output components that retrieves data from ILFs or EIFs and sends it outside the boundary. The primary intent is data retrieval, involving minimal processing logic. Example: A screen function to look up and display a specific customer’s details.

Steps in Function Point Counting (IFPUG Method)

1. Determine the Type of Count: Is it for Development (initial build), Enhancement (modifications), or Application (total size of existing application)?
2. Identify the Application Boundary: Clearly define what is inside and outside the application being measured.
3. Count Functional Components: Identify and categorize all ILFs, EIFs, EIs, EOs, and EQs based on the user’s perspective and IFPUG rules.
4. Determine Complexity Level: Assign a complexity rating (Low, Average, High) to each identified component based on specific rules involving Data Element Types (DETs - unique user-recognizable fields) and Record Element Types (RETs - logical subgroups of data within an ILF/EIF) or File Types Referenced (FTRs - ILFs/EIFs read or maintained by a transaction). IFPUG provides specific matrices for this.
5. Example Complexity Matrix (Conceptual - refer to IFPUG manual for exact rules):
7. Calculate Unadjusted Function Points (UFP): Multiply the count of each component type at each complexity level by standard weighting factors and sum the results.
9. Determine Value Adjustment Factor (VAF): Assess the impact of 14 General System Characteristics (GSCs) on the application. Each GSC (e.g., Data Communications, Performance, Reusability, Security) is rated on a scale of 0 (No Influence) to 5 (Strong Influence). The sum of these ratings (Total Degree of Influence - TDI) is used in the VAF formula.
10. The 14 GSCs are: Data Communications, Distributed Data Processing, Performance, Heavily Used Configuration, Transaction Rate, On-Line Data Entry, End-User Efficiency, On-Line Update, Complex Processing, Reusability, Installation Ease, Operational Ease, Multiple Sites, Facilitate Change.
11. Calculate Final Adjusted Function Points (FP): Apply the VAF to the UFP. The formula is: FP = UFP * VAF, where VAF = 0.65 + (0.01 * TDI).

Application and Context

Function Points are used for:

• Software Size Measurement: Providing a technology-independent size measure.
• Estimation: Input for effort and cost estimation models (though often needs calibration with historical data).
• Productivity Measurement: Calculating productivity (e.g., FP per person-month).
• Project Tracking: Monitoring scope changes by tracking FP added, changed, or deleted.
• Benchmarking: Comparing application sizes or project productivity across different projects or organizations.

Limitations and Modern Relevance

While standardized, FPA has limitations:

• Subjectivity: Identifying components and assessing complexity can still involve judgment, requiring trained counters for consistency.
• Effort Intensive: Detailed counting can be time-consuming, especially for large applications.
• Early Lifecycle Difficulty: Requires reasonably detailed functional requirements, making it harder to apply accurately in very early phases.
• Suitability: May be less suitable for non-transactional systems (e.g., scientific computing, real-time embedded systems) or highly distributed microservice architectures where boundaries are complex.
• Agile Context: Less frequently used for short-term planning in Agile teams, which often prefer relative sizing with Story Points and velocity-based forecasting. However, FPs might still be used for high-level portfolio estimation or contract purposes.

Despite limitations, FPA remains a relevant technique in certain contexts, particularly for large-scale project estimation, benchmarking, and managing fixed-price contracts where a standardized size measure is needed.