Mark II Function Point Analysis (FPA)
I wanted a summary of the function point counting process as the various manuals and books tended to be overly fulsome.
The effort involved in a count typically takes 0.2% - 0.4% of the total project effort for a new large development project (UKSMA, 1998).
Step1: Determine Scope of Count
Type of count: Development/Application or Change?
What is the desired accuracy of the count? Earlier means less accurate.
What is the boundary of the count, i.e. what logical transactions to include?
Step 2: Identify the Logical Transactions
Note: Step 2-4 are likely to be concurrent and iterative.
Analyse the requirements to find the Logical Transactions, although we're only interested in these so we can find their associated Entities (Step 3) and Data Element Types (Step 4) and from this determine a Functional Size (Step 5).
Logical Transaction …
The basic functional component of MK II FPA. The smallest complete unit of information processing that is meaningful to the end user in the business. It is triggered by an event in the real world of interest to the user, or by a request for information. It comprises an input, process and output component. It must be self-contained and leave the application being counted in a consistent state. (UKSMA, 1998, p. 72).
Most Entities in the system are going to have at least 5 transactions: Create, Read, Update, Delete, and List (CRUDL). For example, a requirement to "Maintain Customer" will correspond to these five transactions, and may well have more if there are variations in processing.
Counting rules:
- Populating a list box from a primary Entity is a separate Logical Transaction.
Step 3: Count the Entities
The processing element of the Function Point Count corresponds to the storage and retrieval of information about Entities of interest to the external world. It is useful to draw an Entity Relationship Diagram (ERD) to find the primary Entities in the system; because we're only interested in the primary Entities, this doesn't have to be full Third Normal Form.
Entity (or Data Entity Type) …
A fundamental thing of relevance to the user, about which information is kept. An association between entities that has attributes is itself an entity (UKSMA, 1998, p. 71).
A non-primary Entity is created to satisfy Third Normal Form, e.g. master tables only used for validation of data entry. They are fairly static and only have a few attributes, e.g. code, description. All references to non-primary entities are considered references to a single entity called the System Entity; there is only ever one System Entity.
Counting rules:
- Each Logical Transaction must reference at least one Entity.
- A Logical Transaction counts each Entity it refers to; the same Entity can be counted for more than one Logical Transaction.
- Sub-Entities are counted separately from the parent when different processing logic is used for the Sub-Entity.
- Recursive Entities are counted twice for any Logical Transaction that traverses the hierarchy.
- Count the System Entity once if the Logical Transaction refers to any non-primary Entities; don't count the non-primary Entities themselves.
Step 4: Count the Data Elements (DET)
Data Element Type (DET) …
A unique user recognisable, non-recursive item of information. The number of DET's is used to determine the input and output size of each Logical Transaction. (UKSMA, 1998, p. 71)
An Input DET (In-DET) comes from outside the system boundary and changes the state of the system. They are concerned with acquisition and validation of data.
An Output DET (Out-DET) goes back across the system boundary so a user can see/use it. They are concerned with formatting and presentation of data.
Counting Rules:
- Each Logical Transaction must have at least one In-DET.
- Count one In-DET for each distinctly validated DET or group of DETs.
- In the absence of other In-DETs, a Trigger for an event is a DET.
- Each Logical Transaction must have at least one Out-DET.
- Count one Out-DET for each distinctly formatted DET or group of DETs.
- All Error/Confirmation messages for a Logical Transaction are lumped together as one Out-DET.
- Count each Total as an Out-DET, separately from the associated detail DET.
- If an In-DET is redisplayed as part of validation, then also count it as an Out-DET.
Step 5: Calculate the Function Point Index (FPI)
Calculate the functional size or Function Point Index (FPI) of each Logical Transactions whose input and output components cross the system boundary.
|
0.58 * Count(In-DET) + 1.66 * Count(Entities-Referenced) + 0.26 * Count(Out-DET) |
The functional size of the system, i.e. the total FPI, is the sum of the sizes of each of the Logical Transactions.
Total FPI = Sum (FPI of all Logical Transactions)
Example:
|
Code |
Transaction Description |
CRUDL |
Entities Referenced |
Response |
In-DET |
Entities |
Out-DET |
FPI
|
|
|
R01.0 |
Maintain Customer |
|
|
|
|
|
|
|
51.3 |
|
R01.1 |
Add Customer |
C |
Customer |
OK/Error |
20 |
1 |
1 |
13.5 |
|
|
R01.1.1 |
Find All Sales People (for drop down) |
L |
Sales Rep |
List |
1 |
1 |
1 |
2.5 |
|
|
R01.2 |
Update Customer |
U |
Customer |
OK/Error |
20 |
1 |
1 |
13.5 |
|
|
R01.3 |
Delete Customer |
D |
Customer |
OK/Error |
1 |
1 |
1 |
2.5 |
|
|
R01.4 |
Read Customer |
R |
Customer |
Details |
4 |
2 |
25 |
12.1 |
|
|
R01.5 |
List Customers |
L |
Customer |
List |
1 |
1 |
19 |
7.2 |
|
|
|
|
|
|
|
|
|
|
|
|
|
R02.0 |
Maintain Account |
|
|
|
|
|
|
|
12.5 |
|
R01.1 |
Add Account |
C |
Customer, Account |
OK/Error |
15 |
2 |
2 |
12.5 |
|
|
Etc |
|
|
|
|
|
|
|
|
|
|
Total |
|
|
|
|
|
|
|
63.8 |
63.8 |
For counting changes to systems
Count Entities and DETs if they are touched by the change, i.e. added, modified, or deleted. If a component is not changed, then don't count it.
FPI of Change = Added + Modified + Deleted functionality
FPI after Change = FPI before Change + Added - Deleted functionality
Note: this has the interesting effect that the cost of deleting functionality is the same as it originally cost to build it.
Rough Function Point Count based on Use Cases
If you don't have time to itemise each Logical Transaction for a Use Case, you could try approximating it with the following:
|
Type of Use Case |
Transaction Category |
Simple |
Average |
Complex 25
fields |
|
Create |
C |
5.1 |
14.2 |
23.3 |
|
View |
R |
3.5 |
10.6 |
17.7 |
|
Update |
U |
5.1 |
14.2 |
23.3 |
|
Delete |
D |
7.5 |
7.5 |
7.5 |
|
Search, List, Report, Email |
L |
3.5 |
10.6 |
17.7 |
|
Maintain |
CRUDL |
24.7 |
57.1 |
89.5 |
Contingency
If you've done the count very early in the development process, i.e. before the requirements are detailed, you'll have to add a bigger contingency to the total FPI to take into account unknown requirements.
Technical Complexity Adjustments
Following the suggestion of UKSMA (1998), I have ignored Technical Complexity Adjustments as they don't add value.
Mk II versus Albrecht/IFPUG
I used Albrecht/IFPUG FPA in the past, but I now have a preference for Mk II FPA because:
- Mk II is simpler to count.
- Mk II has finer granularity, i.e. each entity and data element has an effect, whereas Albrecht/IFPUG lumps groups of elements together.
- Mk II is a continuous measure, i.e. adding entities and data elements continues to have an effect. In contrast, Albrecht/IFPUG limits the count once a threshold is reached
References
UKSMA. (1998 Sept). MK II Function Point Analysis: Counting Practices Manual, Version 1.3.1. United Kingdom Software Metrics Association (UKSMA).
Available On-Line at http://www.gifpa.co.uk/library/Resources/MkIIr131.pdf.
This is the definitive description of Mk II Function Point Analysis, including all changes up to October 1998.
Function Point FAQ - Frequently asked questions about FPA.