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 communicationsHow many communication facilities are there to aid in the transfer or exchange of information with the application or system?
2.Distributed data processingHow are distributed data and processing functions handled?
3.PerformanceWas response time or throughput required by the user?
4.Heavily used configurationHow heavily used is the current hardware platform where the application will be executed?
5.Transaction rateHow frequently are transactions executed daily, weekly, monthly, etc.?
6.On-Line data entryWhat percentage of the information is entered On-Line?
7.End-user efficiencyWas the application designed for end-user efficiency?
8.On-Line updateHow many ILF’s are updated by On-Line transaction?
9.Complex processingDoes the application have extensive logical or mathematical processing?
10.ReusabilityWas the application developed to meet one or many user’s needs?
11.Installation easeHow difficult is conversion and installation?
12.Operational easeHow effective and/or automated are start-up, back-up, and recovery procedures?
13.Multiple sitesWas the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations?
14.Facilitate changeWas 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