Function Points Based Size Metrics

Public section

Theme Text

Preferences are saved on this device.

Function Point Metrics

Function Point (FP) metrics address many limitations of Lines of Code (LOC) by measuring what the software does for the user, rather than how it is coded. LOC depends on programming language, coding style, and implementation choices; function points are based on user-visible functionality, so they are more stable across technologies and easier to estimate early.

The basic idea of Function Point Analysis (FPA) is:

The size of a software project is directly related to the number and complexity of the functions it provides to its users.

This makes function points especially useful during project planning, when only the problem specification and high-level requirements are available.

Objectives of Function Point Analysis (FPA)

Measure user-requested functionality – quantify the amount of functionality the user requests and receives, independent of the technology used.
Measure development and maintenance independent of technology – provide a metric that does not depend on programming language, tools, or hardware platform.
Minimise measurement overhead – keep the method simple enough that measurement does not impose excessive effort on the development team.
Provide consistent, comparable measures – standardise the measurement of functionality so that different projects and organisations can be compared more reliably.

Types of Function Points in FPA

FPA groups user-recognisable features into two broad categories: transactional function types and data function types.

(a) Transactional Function Types

These represent processing functions that involve input, output, or inquiry by the user:

External Input (EI) – processes data or control information entering the system from outside its boundary.
Example: user input forms, data entry screens.
External Output (EO) – sends data or control information from inside the system to an external destination.
Example: reports, confirmation messages, generated documents.
External Inquiry (EQ) – a combination of input and output that retrieves data without significant internal processing.
Example: a “view customer details” screen that shows information from existing records without complex calculations.

Figure 15: Function Point Analysis – illustrates the relationships among EI, EO, EQ, ILF, and EIF.

(b) Data Function Types

These represent logical data groups maintained or referenced by the application:

Internal Logical File (ILF) – a user-identifiable group of logically related data or control information that is maintained within the boundary of the application.
External Interface File (EIF) – a user-recognisable group of logically related data that is used by the application but maintained by another system.
Example: a product catalogue file owned by another system but read by this application.

Function Point Calculation

Function points are computed in two main steps:

Counting and classifying all functions
Identify all EIs, EOs, EQs, ILFs, and EIFs. Classify each as Low, Average, or High complexity based on its characteristics (for example, number of data elements and number of files referenced).
Calculating Unadjusted Function Points (UFP) and then applying a Value Adjustment Factor (VAF) to obtain the final Adjusted Function Points (FP).

Step 1: Calculate Unadjusted Function Points (UFP)

Each function type has a weight depending on its complexity. Let P_ij be the count of functions of type i with complexity level j, and W_ij the corresponding weight. The Unadjusted Function Points (UFP) are:

$$\mathrm{UFP} = \sum_{i=1}^{5} \sum_{j=1}^{3} P_{ij}\,W_{ij}$$

(Equation 2.1) Here, the five function types are EI, EO, EQ, ILF, and EIF, and the three complexity levels are Simple, Average, and Complex.

Table 3: Weight factors for function point parameters
Parameter / Functional Unit	Simple	Average	Complex
User Inputs (EI)	3	4	6
User Outputs (EO)	4	5	7
User Enquiries (EQ)	3	4	6
Internal Logical Files (ILF)	7	10	15
External Interface Files (EIF)	5	7	10

Step 2: Value Adjustment Factor (VAF) and Final Function Points

To account for overall system characteristics, FPA uses 14 General System Characteristics (GSCs) or complexity factors. Each factor F_i is rated from 0 (no influence) to 5 (strong influence).

The Value Adjustment Factor (VAF) is calculated as:

$$\mathrm{VAF} = 0.65 + 0.01 \sum_{i=1}^{14} F_i$$

(Equation 2.2)

The final Adjusted Function Points are then:

$$\mathrm{FP} = \mathrm{UFP} \times \mathrm{VAF}$$

(Equation 2.3)

General System Characteristics (GSCs)

The 14 GSCs commonly used in FPA are:

Data communications – use of data communication facilities.
Distributed data processing – presence of distributed processing.
Performance – required response time or throughput.
Heavily used configuration – degree of load on the hardware platform.
Transaction rate – expected frequency of transactions.
Online data entry – percentage of data entered online.
End-user efficiency – design focus on end-user productivity.
Online update – number of ILFs updated online.
Complex processing – extent of logical or mathematical processing.
Reusability – degree to which the application is designed for reuse.
Installation ease – difficulty of conversion and installation.
Operational ease – level of automation for startup, backup, recovery.
Multiple sites – planned installation at multiple locations.
Facilitate change – ease with which the system can accommodate future changes.

Benefits of Function Point Analysis (FPA)

FPA is widely used because it:

Estimates package size – helps determine the size of purchased or existing application packages by counting the functions they provide.
Supports benefit analysis – allows users to compare delivered functions with organisational needs.
Supports quality and productivity analysis – provides a consistent unit (function point) for measuring defect density, productivity, and other performance indicators.
Improves resource estimation – helps in estimating effort, cost, and staffing for both development and maintenance.

Example 2.1: Calculating Function Points

Consider a project where all functions are of average complexity, and all 14 GSCs are rated 2 (moderate influence). The counts for each functional unit are given below:

Parameter	Count	Weight (Average)	Count × Weight
User Inputs (EI)	40	4	160
User Outputs (EO)	30	5	150
User Enquiries (EQ)	25	4	100
Internal Logical Files (ILF)	6	10	60
External Interface Files (EIF)	4	7	28
Total UFP			498

Since each GSC has rating 2, the sum of all influence factors is: Σ F_i = 14 × 2 = 28. Using Equation 2.2:

VAF = 0.65 + 0.01 × 28 = 0.65 + 0.28 = 0.93

Finally, the function points are:

FP = UFP × VAF = 498 × 0.93 ≈ 463

Limitations of Function Point Analysis

Subjectivity: The classification and weighting of functions can be subjective and depend on the analyst’s expertise.
Learning curve: It requires understanding and practice to accurately identify and classify functions.
Challenges with modern applications: Rich web applications, microservices, and complex UI/UX patterns can make traditional FPA harder to apply without adaptation or updated counting rules.