Function Point Method

Overview of Function Point Analysis

1. Invented by Allan Albrecht in mid 1970s as an alternative to Source Lines of Code as a measure of software sizing
2. First paper published internally at IBM in 1979
3. In 1981, the same paper reprinted in IEEE
4. In 1984, Albrecht introduced “General System Characteristics” to FPA
5. International Function Point User’s Group (IFPUG) created in 1986
6. In 1990, the first version of Counting Practices Manual (CPM) - IFPUG

Objectives of Function Point Analysis

1. Measure functionalities based on the user’s view of application software functionalities
2. Minimize the overhead of measurement
3. Set up a size measurement method which is consistent across organizations

Benefits of Function Point Analysis

1. Size can be determined early in the project life cycle
2. Forms a basis for measuring, improving productivity
3. FP is a unit for software measure like “m” is a unit for distance measure or “Co” is a unit for temperature measure.
4. Independent of development tools and environments – hence, can be used to measure productivities across various tools and environments
5. Provides consistent size measures across groups and organizations
6. Sizing is an important component in determining productivity (outputs/inputs), predicting effort, understanding unit cost, and so on.

 Function Point Counting Procedures

 

 

 

 Definition of User View

 

A user view:

1. Is a description of the business functions
2. Is approved by the user
3. Can be used to count function points
4. Can vary in physical form (e.g., catalog of transactions, proposals, requirements document, external specifications, detailed specifications, user handbook)

Type of Function Point Count
Function point counts can be associated with either projects or applications. There are three types of function point counts:

1. Development project - The development project function point count measures the functions provided to the users with the first installation of the software delivered when the project is complete.
2. Enhancement project - The enhancement project function point count measures the modifications to the existing application that add, change, or delete user functions delivered when the project is complete.
3. Application - The application function point count is associated with an installed application. This count provides a measure of the current functions the application provides the user.

Definition of the Counting Scope
The scope:

1. Defines a (sub) set of the software being sized
2. Is determined by the purpose for performing the function point count
3. Identifies which functions will be included in the function point count so as to provide answers relevant to the purpose for counting
4. Could include more than one application

Definition of the Application Boundary
The application boundary:

1. Defines what is external to the application
2. Is dependent on the user’s external business view of the application and independent of technical and/or implementation considerations
3. Acts as a ‘membrane’ through which data processed by transactions (EIs, EOs and EQs) pass into and out from the application
4. Encloses the logical data maintained by the application (ILFs)
5. Assists in identifying the logical data referenced by but not maintained within this application (EIFs)

Definitions: ILFs and EIFs

Internal Logical Files (ILFs):

 

An Internal Logical File (ILF) is a user identifiable group of logically related data that resides entirely within the applications boundary and is maintained through External Inputs.

 

External Logical Files (EIFs):

 

External Interface File (EIF) is a user identifiable group of logically related data that is used for reference purposes only. The data resides entirely outside the application and is maintained by another application. The External Interface File is an Internal Logical File for another application.

ILF/EIF Identification Rules

ILF Identification Rules:

All of the following counting rules must apply for the information to be counted as an ILF.

1. The group of data or control information is logical and user identifiable.
2. The group of data is maintained through an elementary process within the application boundary being counted.

EIF Identification Rules:

 

All of the following counting rules must apply for the information to be counted as an EIF.

1. The group of data or control information is logical and user identifiable.
2. The group of data is referenced by, and external to, the application being counted.
3. The group of data is not maintained by the application being counted.
4. The group of data is maintained in an ILF of another application.

Complexity and Contribution Definitions and Rules
A functional complexity of each identified ILF and EIF bases on the number of data element types (DETs) and record element types (RETs) associated with the ILF or EIF.

 

1. A data element type (DET) is a unique user recognizable and non-repeated field.
2. A record element type (RET) is a user recognizable subgroup of data elements within an ILF or EIF. There are two types of subgroups: Optional  and Mandatory

DET Rules
The following rules apply when counting DETs:

1. Count a DET for each unique user recognizable, non-repeated field maintained in or retrieved from the ILF or EIF through the execution of an elementary process.
2. When two applications maintain and/or reference the same ILF/EIF, but each maintains/references separate DETs, count only the DETs being used by each application to size the ILF/EIF.
3. Count a DET for each piece of data required by the user to establish a relationship with another ILF or EIF.

RET Rules
One of the following rules applies when counting RETs:

1. Count a RET for each optional or mandatory subgroup of the ILF or EIF.
2. If there are no subgroups, count the ILF or EIF as one RET.