Function Point Analysis

Objectives of Function Point Analysis

Frequently the term end user or user is used without specifying what is meant. In this case, the user is a sophisticated user. Someone that would understand the system from a functional perspective  more than likely someone that would provide requirements or does acceptance testing.

Since Function Points measures systems from a functional perspective they are independent of technology. Regardless of language, development method, or hardware platform used, the number of function points for a system will remain constant. The only variable is the amount of effort needed to deliver a given set of function points; therefore, Function Point Analysis can be used to determine whether a tool, an environment, a language is more productive compared with others within an organization or among organizations. This is a critical point and one of the greatest values of Function Point Analysis.

Function Point Analysis can provide a mechanism to track and monitor scope creep. Function Point Counts at the end of requirements, analysis, design, code, testing and implementation can be compared. The function point count at the end of requirements and/or designs can be compared to function points actually delivered. If the project has grown, there has been scope creep. The amount of growth is an indication of how well requirements were gathered by and/or communicated to the project team. If the amount of growth of projects declines over time it is a natural assumption that communication with the user has improved.

 Characteristic of Quality Function Point Analysis

Function Point Analysis should be performed by trained and experienced personnel. If Function Point Analysis is conducted by untrained personnel, it is reasonable to assume the analysis will done incorrectly. The personnel counting function points should utilize the most current version of the Function Point Counting Practices Manual,

Current application documentation should be utilized to complete a function point count. For example, screen formats, report layouts, listing of interfaces with other systems and between systems, logical and/or preliminary physical data models will all assist in Function Points Analysis.

The task of counting function points should be included as part of the overall project plan. That is, counting function points should be scheduled and planned. The first function point count should be developed to provide sizing used for estimating.

 The Five Major Components

Since it is common for computer systems to interact with other computer systems, a boundary must be drawn around each system to be measured prior to classifying components. This boundary must be drawn according to the user’s point of view. In short, the boundary indicates the border between the project or application being measured and the external applications or user domain. Once the border has been established, components can be classified, ranked and tallied.

External Inputs (EI) – is an elementary process in which data crosses the boundary from outside to inside. This data may come from a data input screen or another application. The data may be used to maintain one or more internal logical files.  The data can be either control information or business information.  If the data is control information it does not have to update an internal logical file.  The graphic represents a simple EI that updates 2 ILF’s (FTR’s).

external inpu

External Outputs (EO) – an elementary process in which derived data passes across the boundary from inside to outside.   Additionally, an EO may update an ILF.  The data creates reports or output files sent to other applications.  These reports and files are created from one or more internal logical files and external interface file.  The following graphic represents on EO with 2 FTR’s there is derived information (green) that has been derived from the ILF’s



External Inquiry (EQ)

– an elementary process with both input and output components that result in data retrieval from one or more internal logical files and external interface files.  The input process does not update any Internal Logical Files, and the output side does not contain derived data. The graphic below represents an EQ with two ILF’s and no derived data.


Each count is multiplied by the numerical rating shown to determine the rated value. The rated values on each row are summed across the table, giving a total value for each type of component. These totals are then summed across the table, giving a total value for each type of component. These totals are then summoned down to arrive at the Total Number of Unadjusted Function Points

Function Point

The value adjustment factor (VAF) is based on 14 general system characteristics (GSC’s) that rate the general functionality of the application being counted. Each characteristic has associated descriptions that help determine the degrees of influence of the characteristics. The degrees of influence range on a scale of zero to five, from no influence to strong influence. The IFPUG Counting Practices Manual provides detailed evaluation criteria for each of the GSC’S, the table below is intended to provide an overview of each GSC.

General System Characteristic

Brief Description

1. Data communications How many communication facilities are there to aid in the transfer or exchange of information with the application or system?
2. Distributed data processing How are distributed data and processing functions handled?
3. Performance Was response time or throughput required by the user?
4. Heavily used configuration How heavily used is the current hardware platform where the application will be executed?
5. Transaction rate How frequently are transactions executed daily, weekly, monthly, etc.?
6. On-Line data entry What percentage of the information is entered On-Line?
7. End-user efficiency Was the application designed for end-user efficiency?
8. On-Line update How many ILF’s are updated by On-Line transaction?
9. Complex processing Does the application have extensive logical or mathematical processing?
10. Reusability Was the application developed to meet one or many user’s needs?
11. Installation ease How difficult is conversion and installation?
12. Operational ease How effective and/or automated are start-up, back-up, and recovery procedures?
13. Multiple sites Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations?
14. Facilitate change Was the application specifically designed, developed, and supported to facilitate change?

Once all the 14 GSC’s have been answered, they should be tabulated using the IFPUG Value Adjustment Equation (VAF) —

 14 where: Ci = degree of influence for each General System Characteristic

 VAF = 0.65 + [ (Ci) / 100] .i = is from 1 to 14 representing each GSC.

i =1 Ã¥ = is summation of all 14 GSC’s.

The final Function Point Count is obtained by multiplying the VAF times the Unadjusted Function Point (UAF).


Post Author: educlash

Leave a Reply

Your email address will not be published. Required fields are marked *