FPA - Function Point Analysis

References
Function Point Analysis is a means to measure the size of the software. A good book on FPA is "Measuring the software process; a practical guide to functional measurements" by David Garmus and David Herron.

FPA is maintained by IFPUG - International Function Point Users Group (www.ifpug.org)

Function Point Analysis Introduction

FPA is an accepted standard for the measurement of software size. It is a normalizing factor for software comparison similar to other standard units of size such as meters, ohm etc.

Function points can then be applied to costing and estimating. But just like the cost of 100 sq mts in a city downtown is more than 100 sq mts of a village, the cost and estimate depend on other factors aswell. However, the key ingredient would be function points. In other words, function points are the "pure" measurement metrics for the functionality as perceived by the users. It is independent of the technology, and other such similar system charecteristics.

The function point analysis process consists of the following steps

1. First determine the type of function point to perform
2. Then identify the system boundary
3. Identify the data functions and their complexity
4. Identify the transaction functions and their complexity
5. Determine the UFPC - unadjusted function point count
6. Determine the VAF - value adjustment factor depending on system characteristics
7. Determine the FPC

Types of function points

There are three types of function points -

1. Development project function points
2. Enhancement project function points
3. Application function points

Development project function points would calculate the size of the functionality available in the first version of the software. This may also include the size of any data conversion from a previous software. For such projects, at first when the requirements are not clear, based on existing information, function points are calculated. However, as the development progresses, the function points are updated. Also there may be new requirements being added to the project which would also lead to function point analysis of the new functionality.

Enhancement projects would include either new functionality additions, changes or deletions. Conversion functionality may also be implemented. The function points for the above changes are then reflected on the application function point.

Application function point counts measures an installed application and provides the function point counts of the functionality provided to the user.

Defining the system boundary

This is the boundary of the system being developed and the external systems and user domain. The following are the rules by IFPUG -

1. The boundary should be user perceivable such that the user should be able to define the scope.
2. When defining boundaries between related systems, it should be based only on business functionality and not on other factors such as technology.
3. As enhancements are done to the application, the application boundary changes with added or deleted functionality.

Data function points

Data functions relate to user identifyable logically grouped/related data or control information which are stored and available for update and retrieving. There are two kinds of data types -

1. Internal logical file (ILF) - maintained within the boundary of the application
2. External interface file (EIF) - readonly references to data which is maintained outside the application boundary

Some definitions

Elementary process - Smallest user meaningful unit of activity. Such an activity may do sub-activitities, but such activities on their own are not useful to the user.

User identifiable - Part of the requirements that can be understood and defined by an experience user.

Logical related data - logical group of data that fits the description, typically entities in the 2nd and 3rd normalized form. If for some implementation reason data is split, it should be merged back.

Control information - This is the information that will somehow influence an elementary process.
For example, the last time of login, to implement any timeout semantics etc.

Internal logical files (ILF)

It is

• user identifiable
• group of logically related data or control information
• maintained within the application boundary
• by an elementary process of the application

Please note that once an ILF is identified, it is possible that some other elementary process may just reference it and not modify it. In this case, it is still counted as ILF and not to be treated as EIF.

External Interface Files (EIF)

It is -

1. User identifiable
2. Logically related data or control information
3. referenced by an elementary process in the application boundary
4. but maintained by another application

Complexity of data functions

Complexity of a data function is calculated using two concepts -

1. Data element type (DET)
2. Record element type (RET)

Data element type

These are the

1. user recognizable
2. unique, non-recursive, field/attibutes (including any foreign key attributes) maintained in ILF or EIF.

Recursive means repeating. For example, if we were to store cheque values for all the 12 months of an year and the total value, then we would not count 12 values as these are only repeating. We would count them as DET for cheque value, single DET for month identifier and single DET for total check for the year stored.

Record element type

These are the

1. user recognizable
2. subgroups (optional or mandatory) of data elements contained within an ILF or EIF. Sub groups are typically represented in an ERD as entity sub types or attributive entities commonly called parent child relationship

If there are no sub groups, then RET is 1. Otherwise count an RET for each optional or mandatory sub group.

Calculating complexity of data functions

Depending on the number of RET and DET identified for each data function, complexity is calculated using the complexity matrix. This matrix is the same for both ILF and EIF and is -

1. If number number of RET is <>
2. If number number of RET is 2-5, then for DET 1-19, complexity is "L", for DET 20-50, complexity is "A" and 51+, it is "H"
3. If number number of RET is >5, then for DET 1-19, complexity is "A", for DET 20-50, complexity is "H" and 51+, it is "H"

Calculating unadjusted data function point

For ILF

1. If complexity is "L", then unadjusted function point is number of ILF multiplied by 7
2. If complexity is "A", then unadjusted function point is number of ILF multiplied by 10
3. If complexity is "H", then unadjusted function point is number of ILF multiplied by 15

For EIF

1. If complexity is "L", then unadjusted function point is number of ILF multiplied by 5
2. If complexity is "A", then unadjusted function point is number of ILF multiplied by 7
3. If complexity is "H", then unadjusted function point is number of ILF multiplied by 10

Transaction function points

Information systems are usually developed with the intent that certain manual tasks can be accomplished more economically and effectively. It is these tasks that end up being identified as transactional functions.

There are three types of transaction functions -

1. External input (EI) which maintains ILF

s