Function Point Analysis (FPA) is a widely used method for estimating the size and effort required for software development projects. It measures the functionality delivered to the user based on the system’s requirements, independent of the technology used to implement it. FPA was developed by Allan Albrecht in the late 1970s and is maintained by the International Function Point Users Group (IFPUG).
Table of Contents
Steps in Function Point Analysis
- Identify and Classify Function Types:
- Function Point Analysis are categorized into five types:
- External Inputs (EI): Data or control inputs from outside the system.
- External Outputs (EO): Data or control outputs to outside the system.
- External Inquiries (EQ): Interactive inputs that trigger a response.
- Internal Logical Files (ILF): Data stored and maintained within the system.
- External Interface Files (EIF): Data stored and maintained outside the system but used by the system.
- Function Point Analysis are categorized into five types:
- Determine the Complexity of Each Function:
- Each function type is rated as Low, Average, or High complexity based on the number of data elements and file types referenced.
- Calculate Unadjusted Function Points (UFP):
- Multiply the number of each function type by its corresponding weight (based on complexity) and sum them up to get the total unadjusted function points.
- Compute the Value Adjustment Factor (VAF):
- The VAF is calculated based on 14 general system characteristics (GSCs), such as data communications, performance, and reusability. Each characteristic is rated on a scale of 0 to 5.
- The formula for VAF is:VAF=0.65+(0.01×Sum of GSC ratings)VAF=0.65+(0.01×Sum of GSC ratings)
- Calculate Adjusted Function Points (AFP):
- Multiply the UFP by the VAF to get the adjusted function points:AFP=UFP×VAFAFP=UFP×VAF
- Estimate Effort:
- Use historical data or industry benchmarks to convert function points into effort (e.g., person-hours or person-months). For example, if the organization’s productivity rate is 10 hours per function point, the total effort for 100 function points would be 1,000 hours.
Benefits of Function Point Analysis
The benefits of Function Point Analysis
- Technology-Independent:
- Function Point Analysis measures functionality from the user’s perspective, making it applicable to any programming language or technology.
- Consistent and Repeatable:
- The standardized methodology ensures consistent results across projects and organizations.
- Early Estimation:
- Function Point Analysis can be used early in the project lifecycle, even before detailed design or coding begins.
- Focus on User Requirements:
- It emphasizes the functionality delivered to the user, aligning development efforts with business needs.
- Useful for Benchmarking:
- Function points provide a common metric for comparing productivity and quality across projects and organizations.
- Supports Scope Management:
- By quantifying functionality, FPA helps manage scope creep and ensures alignment with project goals.
Comparison with COCOMO (Constructive Cost Model)
COCOMO is another effort estimation technique, but it differs significantly from Function Point Analysis. COCOMO estimates effort based on the size of the software (in lines of code) and a set of cost drivers (e.g., team experience, complexity, and tools).
Benefits of Function Point Analysis Over COCOMO
- Technology Independence:
- FPA is not tied to lines of code, making it more flexible and applicable to modern development environments (e.g., low-code platforms, cloud-based systems).
- User-Centric:
- FPA focuses on the functionality delivered to the user, while COCOMO focuses on technical aspects like lines of code.
- Early Estimation:
- FPA can be used earlier in the project lifecycle, whereas COCOMO requires a reasonably accurate estimate of lines of code, which is often unavailable in the early stages.
- Better for Non-Code-Centric Projects:
- FPA is suitable for projects involving configuration, integration, or customization (e.g., ERP implementations), where lines of code may not be relevant.
- Consistency Across Projects:
- FPA provides a consistent metric (function points) for comparing projects of different sizes, technologies, and domains.
- Easier to Communicate:
- Function points are easier to explain to non-technical stakeholders compared to lines of code.
When to Use FPA vs. COCOMO
- Use FPA:
- When the project involves user-centric functionality.
- When the technology stack is not yet finalized.
- For non-code-centric projects (e.g., ERP, CRM implementations).
- When early estimation is required.
- Use COCOMO:
- When the project is code-centric, and lines of code can be estimated accurately.
- For projects where technical complexity and team experience are critical factors.
- When historical data on lines of code and effort is available.
Example of FPA in Practice
Suppose a project has the following function counts:
- 5 External Inputs (EI) of average complexity.
- 3 External Outputs (EO) of high complexity.
- 2 External Inquiries (EQ) of low complexity.
- 4 Internal Logical Files (ILF) of average complexity.
- 1 External Interface File (EIF) of low complexity.
Using IFPUG weights:
- EI (Average): 5 × 4 = 20
- EO (High): 3 × 7 = 21
- EQ (Low): 2 × 3 = 6
- ILF (Average): 4 × 10 = 40
- EIF (Low): 1 × 5 = 5
Unadjusted Function Points (UFP): 20 + 21 + 6 + 40 + 5 = 92
If the Value Adjustment Factor (VAF) is 1.15, then:
Adjusted Function Points (AFP): 92 × 1.15 = 105.8
If the organization’s productivity rate is 10 hours per function point, the total effort would be:
Effort: 105.8 × 10 = 1,058 hours.
Conclusion
Function Point Analysis is a powerful and flexible technique for estimating software development effort. It offers several advantages over COCOMO, particularly in its user-centric approach, technology independence, and applicability to early project stages. However, the choice between FPA and COCOMO depends on the project context, available data, and organizational preferences. Both techniques have their strengths and can complement each other in a comprehensive estimation process.