Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / operating-systems / Windows

Calculating Function Points

4.33/5 (6 votes)
15 Mar 20076 min read 1  
Using Function Point analysis to calcuate Function Points.

Calculating Function Points using Function Point Analysis.


Introduction

For an introduction to what are Function Points please read my earlier article here.

There can be various methods to calculate function points; you can define your custom too based on your specific requirements. But "Why re-invent the wheel?" when you already have a tried and tested method given by IFPUG by their experiences and case study.

The method used to calculate function point is knows as FPA (Function Point Analysis). Also I would define it in single line as "A Method of quantifying the size and complexity of a software system in terms of the functions that the system delivers to the user". As I have already given an Introduction to FP and FPA in my earlier Blog I wont go into much deeper right now. Let's start learning how to calculate the function points.

Functionalities

Following functionalities are counted while counting the function points of the system.

  • Data Functionality
    • Internal Logical Files (ILF)
    • External Interface Files (EIF)
  • Transaction Functionality
    • External Inputs (EI)
    • External Outputs (EO)
    • External Queries (EQ)

Now logically if you divide you software application into parts it will always come to one or more of the 5 functionalities that are mentioned above. A software application cannot be derived without using any one of the functionalities above.

Methodology of calculating the function points

We need to under stand a system first with respect to the function points for that consider an application model as below for measuring the function points.

Screenshot - FPM.jpg

Now to calculate the function points we need to follow the following steps:

  1. Measure the application boundary

    1. The application boundary defines what is external to the application.

    2. It is dependent on the users external business view of the application and not on the technical and/or implementation consideration

  1. Identify the data functionalities (ILF and EIF)

    1. User identifiable group of data; logically related and maintained with in the boundary of the application through one or more elementary process is know as ILF.

    2. User identifiable group of data, logically related, referenced by the application but maintained with in the boundary of different application is known as EIF.

Screenshot - EIF.jpg

<shape id="_x0000_i1025" style="WIDTH: 252pt; HEIGHT: 80.25pt" type="#_x0000_t75"><imagedata src="Calculating%20Function%20Points_files/image003.png">

    1. Few other terminologies of RET and DET are to be understood here as well to determine the function points.

    2. A RET (record element type) is a user recognizable subgroup of data elements with as ILF or EIF

    3. A DET (data element type) is a unique user recognizable, non-repeated field either maintained in an ILF or retrieved from an ILF or ELF.

  1. Identify the transaction functionalities (EI, EO, EQ)

    1. All the tree Transactional functionalities are "elementary processes"

    2. An Elementary Process is the smallest unit of activity that is meaningful to the user(s).

    3. The elementary process must be self-contained and leave the business of the application in a consistent state.

    4. An EI (External Input) is an elementary process of the application which processes data that enters from outside the boundary of the application. Maintains one or more ILF.

    5. An EO (External Output) is an elementary process that generates data that exits the boundary of the application (i.e. presents information to the user) through processing logic, retrieval of data through ILF or EIF. The processing logic contains mathematical calculations, derived data etc.

    6. An EQ (External Query) is an elementary process that results in retrieval of data that is sent outside the application boundary (i.e. present information to the user) through retrieval of data from ILF or EIF. The processing logic should not contain any mathematical formula, derived data etc.

  1. Using the above data we can calculate the UFP (Unadjusted Function Points)

    1. After all the basic data & transactional functionalities of the system have been defined we can use the following set of tables below to calculate the total UFP.

    2. Now for each type of Functionality determine the UFP's based on the below table.

    3. For EI's, EO's & EQ's determine the FTR's and DET's and based on that determine the Complexity and hence the Number of UFP's it contributes. We have to calculate this for all the EI's, EO's & EQ's.

External Inputs (EI)

File Type Referenced (FTR)

">Data Elements (DET)

1-4

5-15

Greater than 15

Less than 2

Low (3)

Low (3)

Average (4)

2

Low (3)

Average (4)

High (6)

Greater than 2

Average (4)

High (6)

High (6)

External Outputs (EO)

">File Type Referenced (FTR)

">Data Elements (DET)

1-5

6-19

Greater than 19

Less than 2

Low (4)

Low (4)

Average (5)

2 or 3

Low (4)

Average (5)

High (7)

Greater than 3

High (7)

High (7)

High (7)

External Inquiry (EQ)

">File Type Referenced (FTR)

">Data Elements (DET)

1-5

6-19

Greater than 19

Less than 2

Low (3)

Low (3)

Average (4)

2 or 3

Low (3)

Average (4)

High (6)

Greater than 3

Average (4)

High (6)

High (6)

    1. For ILF's & EIF's determine the RET's and DET's and based on that determine the Complexity and hence the Number of UFP's it contributes. We have to calculate this for all the ILF's & EIF's.

Internal Logical File (ILF)

">Record Element Types (RET)

">Data Elements (DET)

1-19

20-50

51 or More

1 RET

Low (7)

Low (7)

Average (10)

2 to 5 RET

Low (7)

Average (10)

High (15)

6 or more RET

Average (10)

High (15)

High (15)

External Interface File (EIF)

">Record Element Types (RET)

">Data Elements (DET)

1-19

20-50

51 or More

1 RET

Low (5)

Low (5)

Average (7)

2 to 5 RET

Low (5)

Average (7)

High (10)

6 or more RET

Average (7)

High (10)

High (10)

    1. Once we have the score of all the Functionalities we can get the UFP as

UFP = Sum of all the Complexities of all the EI's, EO's EQ's, ILF's and EIF's

  1. Further the calculation of VAF (Value added Factor) which is based on the TDI (Total Degree of Influence of the 14 General system characteristics)

    1. TDI = Sum of (DI of 14 General System Characteristics) where DI stands for Degree of Influence.

    2. These 14 GSC are

1. Data Communication

2. Distributed Data Processing

3. Performance

4. Heavily Used Configuration

5. Transaction Role

6. Online Data Entry

7. End-User Efficiency

8. Online Update

9. Complex Processing

10. Reusability

11. Installation Ease

12. Operational Ease

13. Multiple Sites

14. Facilitate Change

    1. These GSC are on a scale of 0-5

  1. Once the TDI is determined we can put it in the formula below to get the VAF.

VAF = 0.65 + (0.01 * TDI)

  1. Finally the Adjusted Function Points or Function Points are

FP = UFP * VAF

  1. Now these FP's can be used to determine the Size of the Software, also can be used to quote the price of the software, get the time and effort required to complete the software.

  1. Effort in Person Month = FP divided by no. of FP's per month (Using your organizations or industry benchmark)

  1. Schedule in Months = 3.0 * person-month^1/3

For e.g. for a 65 person month project

Optimal Schedule = 3.0 * 65^1/3 ~ 12 months

Optimal Team Size = 65 / 12 ~ 5 or 6 persons.

Next Edition

Coming soon a detailed case study on calulating FP throught FPA.

References

www.ifpug.org, http://en.wikipedia.org/

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here