Function Point Analysis
Andys Sundaypink Karolina Kiryjczuk
2034085@student.vu.nl 2128071@student.vu.nl
ABSTRACT
Software development needs effort estimation. It is a complex
problem which needs considerable research attention. Project
managers will have more effective and efficient time and budgets in
software development if the estimation techniques are improved.
This paper reviews a literature study to learn more about what
function point is and how to estimate a software development by
using Function Point Analysis.
1. INTRODUCTION
Software development involves estimation in cost and time. It is
used to establish the budget, resources, and schedules. Therefore if
it is not analyzed properly then it can cause a big problem. As we
can see that the cost and effort estimation are an important aspect
in software development process. First of all, section 2 will give a
brief story of function point analysis. Next, section 3 it will explain
thoroughly how to calculate the function point analysis and its
example. Moreover section 4 will discuss its advantages and
disadvantages and small overview of its differences between Line
of Code and Function Point Analysis. Last, conclusion will be
presented.
2. THE INVENTION OF FP METRICS
In early days, Line of Code (LoC) comes into mind as a unit of
measure of software size. But it can be problematic. Why can it be
a problematic? What are the reasons? It is because there is no
consistent definition of line of code. Does whitespace count as line
of code? Is each line of if statement counts as one line of code or is
the whole if block statement count as one line of code? It also
depends on the programming language being used. 1 line of code in
Java may take 4 lines of code in assembly language. It also depends
on the developer‟s experience and preferences.
The other fundamental reason is Line of Code cannot be used to
estimate the project size at the early stage of the software
development process. As we know that we can have the codes or
measuring the lines of code as we are in the implementation phase.
This means that the first two phases are skipped.
Therefore, in the 1970s Allan Albrecht developed Function Point
Analysis at IBM. It is as an alternative to Line of Code. Its purpose
is to overcome the problems caused by the Line of Code.
Function point is a unit measure for software based on user
perspective, logical design, or functional requirements. Function
point analysis is a structured technique to break system into smaller
components. Therefore it can be better understood and analyzed.
3. FPA IN PRACTICE
In this section we will dive deeper into the actual working of
function point analysis. First it is of great importance to understand
the true meaning of the word function in this context. Programmers
Jos Hoebe
1633317@student.vu.nl
and IT-specialists tend to think of functions as code methods
(“public void DoSomething()”). In this context however functions
are regarded as functionalities, abstracted from implementation. As
such it can be easily used in design. In short we count
functionalities and their complexity and give them weight certain
types relative to each other. We will follow a real time example
during each step to clarify each part.
3.1 Overview
The process of determining the adjusted (final) function point count
is done in 7 steps. These are illustrated in the figure. The first two
consecutive steps deal with the type of the system and the
boundary.
1: Determine Type of Count
2: Identify scope/boundary
Then we count and define the complexity of the functions
themselves.
3: Count Data functions
4: Count Transactional functions
With the functions and complexity of each function counted this
information can be used to balance out and adjust to come up with
the final function point count by taking into account the relative
weights and external factors.
5: Determine Unadjusted Function Point count
6 Determine Value Adjustment factor
7: Calculate the Adjusted Function Point Count
3.2 Determine Type of Count
The first step of the process is to determine the type of the count
that needs to be executed. This type will be used in later steps as
each type has its‟ own characteristics. Function point analysis
makes a distinction between 3 types of systems:
Development: Counts the functions in the first installment of the
software, the “new” system.
Enhancement: Counts the changes, additions and deletion,
basically all “modifications” to the system.
Application: Counts the functions in an existing “installed”
system.
Example:
In our example we will be looking at a small car rental system. In
short, it contains a graphical user interface where a user can enter
new cars into a database and hire them. This system is development
newly and as such we can regard it as development system.
In this system there will be two types of users: an administrator and
a customer, both of which have an entry point into the system, but
since we regard raw functionality this can be left out and we will
view it as one.
 The administrator will be able to enter cars into the database
which is for rent. He must be able to specify the name and age
and put them in the database. He does this by using User
Interface and by pressing the submit button the information
will be processed (checked for validity) and inserted into the
database.
 The Customer will have two functionalities at his disposal.
First, he can view the raw database information in the “car‟s
for rent” section. The name and age are displayed whenever
the user requests this (unspecified for simplicity
reasons).Secondly, he will be able to “rent a car”. This
functionality is more complex and involves multiple steps. By
first retrieving the banking information from the user and in
the next step sending the processed (validated if the car is in
the database) payment info to the banks‟ database.
Figure 1
We created a small custom data flow diagram, as you can see in
figure 1. We visualized a basic GUI to clarify the example further.
3.4 Count Data Functions
Data Functions are functions that represent data to the user to meet
3.3 Identify Counting Scope and Application internal and external data requirements. Data functions are
Boundary represented in so called (logical) files. A file in this context is a
In order to answer the business problems that defined the purpose “logically related group of data” which is a more abstract concept
of the function point count it is of importance to define what is to and not necessarily a physical file (“users.txt”). We make
be counted. Therefore we use 2 definitions. distinction between two types of files:

Counting Scope: Defines all functionality which will be
included in a function point count.
Boundary: Defines the border between measured
application and external applications (domain) and the
user.
Internal Logical File (ILF): File maintained by
elementary process inside the project boundary.
External Interface File (EIF): File not maintained by the
applications but externally, outside the project boundary
by another application.

Example: Measuring Complexity:

In this example we created schematic for a very simplistic car We measure the complexity of data functions by counting two
rental system. The car rental systems‟ boundaries are very obvious types of elements within the logical files:
here as only the bank database is outside the implementation.

Data Element Type (DET): A unique user-identifiable

field (username, age)
Record Element Type (RET): Subgroup of data in a file
((sub) classes)

That will result in rating the function with one of the 3 levels of
complexity (low, average or high) by using the table in table 1.
Example:
In our car rental example figure 1 we have 2 logical files:
The Car Vehicle Database which is an Internal Logical File (ILF)
which in this very simple example has only 2 DET‟‟s namely
“name” and “age” and no RET‟s. Using the table in table 1 its
complexity would be Low.
The Bank Database is an External Interface File (EIF) and has one
DET “Bank Nr.” and 1 RET “User class” which according to table
1 makes it low complexity
3.5 Count Transactional Functions
In similar fashion we will count the transactional functions.
Transactional functions process data in an application. There are 3
types of transactional functions:
External Input (EI): Process data from outside boundary.
External Output (EO): Process data from inside to
outside the boundary
External Inquiry (EQ): Presents data from inside to
outside without processing
Measure Complexity:
In transactional functions we can measure the complexity also by
counting two types of elements used in the functions.
Data Element Type (DET): A unique user-identifiable
field (username, age)
File Type Reference (FTR): This can be a Internal
Logical File or External Logical File maintained by a
transactional function.
Here we will use a similar table for the rating the complexity of a
transactional function. There are two different tables used, the first
one deal with the External Input, the second with External
Output/Inquiry table 2.
Example:
In our car rental system we will regard 3 simple transactional
functions:
Enter Car: This is an External Input which processes the Car user
entry into the car database. It uses 2 DET‟s (“Name”, “Age”) and 1
FTR which is the Car/vehicle Database Internal Logical File.
According to table 2 the complexity with 2 DET‟s and 1 FTR
would be low.
Display Car: Display car is an example of an External Inquiry as it
only represents the data in the car database. It uses the also 2
DET‟s („name‟, „age‟) and 1 FTR (car db) as such the complexity
would be low.
Car Rental: The car rental is an External Output as it processes
data from inside to outside the system boundary (it processes the
bank nr and car rental order information in order for the bank to
use). It uses 3 DET‟s (Car name, age and Bank nr.) and 2 FTR‟s
(bank and car/vehicle db) in table 2 it would also be rated low
complexity.
3.6 Determine Unadjusted Function Point
Count
When both the Data and Transactional functions have been counted
and rated a complexity we can calculate the Unadjusted Function
Point count (UFP) in this stage. We do this by filling in a simple
table. The main principle behind this table is that each type of
function and their complexity have a relative weight. For instance
an External Inquiry with High complexity is less effort to create
than a high complexity external output which also has to process
the data.
Example:
To calculate the Unadjusted Function Point Count in our car rental
system example we will use the information from the previous
steps and fill them in the table. From counting the data functions
we found 1 low complexity Internal Logical File and 1 low
complexity External Interface File. Counting the Transactional
functions we found 1 low complexity External Input, 1 low
complexity external output and 1 low complexity External Inquiry.
When filling this into the table we get 1 x 3 + 1 x 4 + 1x 3 + 1x 7 +
1 x 5 = 22 UFP
3.7 Determine Value Adjustment Factor
Obviously there are a lot more factors involved when it comes to
development of systems. The function point analysis offers some
handles to incorporate these factors into the final calculation with a
Value Adjustment Factor (VAF). There are 14 subjects each worth
0 to 5 points with each point an individual assessment per subject.
These subjects are development or quality attributes as listed
below:
1. Data Communications
2. Distributed Data Processing
3. Performance
4. Heavily Used Configuration
5. Transaction Rate
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
When all the points have been determined these can be summed up
to create the Total Degree of Influence (TDI). Subsequently we are
now able to calculate the value adjustment factor.
VAF = TDI * 0.01 + 0.65
The resulting factor logically is min 0.65 and max 1.35. As such
these 14 points have only a positive or negative influence 35% and
it should be kept in mind that this is the weaker part of the analysis
as their influence is only limited.
Example:
Since the car rental example is very simple we shall in this case
only give credits to online data entry (3 points) as the manual states
in the case of online data entry: “3: 16% to 23% of transactions
are interactive data entry.” It leaves the rest of all the values at a
simple 0. Subsequently the calculation becomes: 3 * 0.01 + 0.65 =
0.68 VAF
3.8 Calculate Adjusted Function Point Count
Finally we can calculate the Adjusted function point count (AFP)
based on the type of system that we are developing. The basic
formula is simply the unadjusted function points (UFP step 5) * the
value adjustment factor (VAF step 6).
Development (“new systems):
AFP = (UFP + CFP) * VAF
Takes into account the extra CFP: Conversion Function
points which is:
“Conversion functionality consists of functions provided
only at installation to convert data and/or provide other
user-specified conversion requirements, such as special
conversion reports.” [2]
Enhancement (“Add/Modify/Delete”):
AFP= [(ADD + CHGA + CFP) * VAFA] + (DEL* VAFB)
Takes in to account Added (ADD) function points and
Changed (CHGA), Conversion (CFP) which will be
multiplied by the function points after the change is done
(VAFA) plus the Deleted functions points (DEL) multiplied
by the functions points before the change is done (VAFB)
Application
AFP = ADD * VAF
ADD is the unadjusted function point count of those
functions that were installed by the development project.
Example:
Finally we calculate the final function point count for the simple car
rental system. For the formula we have gathered a Value
Adjustment Factor (VAF) of 0.68 and an Unadjusted Function
Point count (UFP) of 22. This simple system does not have any
conversion function points that need to be taken into account. As
such the final calculation becomes:
(22 + 0) * 0.68 = 15 AFP
It is the total of function points in the car rental system as a
development project.
4. DISCUSSION
4.1 Standard and Source Code Based FPA
Over the years, several approaches toward Function Point Analysis
have been proposed and developed. However, it seems like the
general idea must be accurate in its essentials, since none of the
modifications has brought any significant changes of the
definitions or the algorithm itself.
The standard FPA, as explained in the previous section, is based on
the documentation. The main requirement is that the documentation
must be available, complete and correct. By analyzing the
documentation and models according to the steps presented before,
we obtain the Function Point value.
Source code based FPA makes an attempt to bridge the gap
between the functional world and the world of source code. The
term “source code based Function Point analysis” itself may sound
like a dissonance, nevertheless it is just a more pragmatically
approach. In this case, the input of the counting system would be a
collection of source codes, programs and if possible the data model,
which may significantly simplify the detection of logical files. By
analyzing different statements (I/O-statements, SQL-statements,
various other calls), operations and variables, we are able to
identify counting boundary, determine logical files, transactional
functions and their element types and thereafter count the adjusted
Function Point value.
4.2 FPA Advantages and Disadvantages
Function Point Analysis is based on a logical point of view. The
emphasis is put on analyzing the system from user's perspective.
This means that we focus on what the system does and not how it
does it. Moreover, the fact that we are interested in logic, not in the
implementation makes the Function Point analysis platform
independent - it is no longer relevant in what language the system
has been implemented and what are other requirements.
The International Function Point Users Group functional
measurement method is an ISO recognized software metric. The
IFPUG FSM Method (ISO/IEC 20926 SOFTWARE
ENGINEERING - FUNCTION POINT COUNTING
PRACTICES MANUAL) is currently one of five recognized ISO
standards for functionally sizing software.
Using the FP count, we should be able to measure the project
effort. Project effort is dependent on two attributes: the project size
and productivity. Project effort can be calculated by dividing the
project size by the productivity. It is typically measured as person
month or staff month.
Example:
The project size is 1000FP and the productivity is 10FP
per person month. Then by dividing 1000FP with 10FP
per person month, we will get 100 person months.
As we may observe, the Function Point analysis is relatively
complicated. As opposed to Lines of Codes, it requires the
infrastructure to fulfill certain requirements. It usually needs extra
documentation and this documentation must be available, complete
and correct, which is not always the case, for example, with many
legacy systems (however, new approaches, like source code based
FPA, may be applied in case of missing functional documentation).
On the other hand, this could be perceived as an advantage as well -
for the need of writing well-defined set of requirements may be
beneficial and result in well-organized and well-structured
documentation, which, furthermore, may prevent some
misunderstandings and save time.
Unfortunately, this measurement method typically is not integrated
into maintenance process, since it cannot be fully automated
(although, again, source code based Function Point analysis, may
be useful here and can be automated to some degree).
4.3 FPA vs LoC
Lines of Codes and Function Point analysis are two methods of
different sorts and are focused on different levels. Sometimes they
both can be used; however, in some cases, one seems to be more
applicable than the other. The choice of the measurement method
should be preceded by careful analysis on the project character and
expected outcome.
As we have seen, Function Point analysis has developed some
unified formalism, which includes definitions (for instance, logical
files, transactional functions) and a well-formed algorithm, which
consists of the list of steps one has to follow in order to perform the
analysis. Whereas the case with the Lines of Codes is that it is
quite difficult and challenging to come up with the accurate and
acceptable definition; however, ones such definition is provided,
counting becomes extremely easy and may be fully automated. As a
result, it is cheap and simple sizing method, therefore a tempting
alternative for the complicated and more expensive FPA.
The one great advantage of FPA over LoC is that it is independent
of the language used for implementation. FPA is based on the
logical point of view and it does not matter if a statement takes one
or four lines code or what libraries it uses – the important thing
here is what this piece of code actually does.
Neither of the two metrics is applicable for the projects in every
stage of development. Obviously, LoC cannot be used for
development projects, since there is simply no code to count. On
the other hand, FPA is hardly used for enhancement projects.
LoC seems to be very straightforward and clear method for
estimating how much effort has been put into creating a certain
piece of code and, as a consequence, a particular piece of software:
simply, the more code has been written, the greater effort has been
put. Yet, FPA might be of better credit when it comes to measuring
actual effectiveness of the code - the fact that some piece of code is
small might not reflect its substantive capabilities and the whole
thinking process that stands behind it; nevertheless, if it is powerful
then the FP-count will show that.
4.4 Backfiring
A method called backfiring may seem a nice combination of the
two measurement methods. Many FPA-counts have been analyzed
in order to estimate a relation between the number of Lines of
Codes and unction Points for various languages.
Having this estimated factor and counting Lines of Codes, one can
extract the number of Function Points. For example, if we have a
program written in C which contains 100 000 Lines of Code, we
get approximate FP:
FP = LoC/(LoC/FP) = 100 000/128 ≈ 781.
Moreover, backfiring might come in handy if there is a need to
compare two projects which have been analysed each by using a
different of these two methods. Suppose we had an FP count for
one project and LoC count for another; then we could estimate the
FP count of the latter by backfiring and this way obtain some frame
of reference to contrast and compare the two projects.
However, this solution is a bit hazardous and should be used
carefully, in situations when the documentation is not available or
when the first order estimation is sufficient.
5. CONCLUSION
The Function Point analysis is one of the methods for estimating
the size of a software project and, as such, can also indicate both
cost and development effort that has been put into the project. It
has its formalism, which has been presented in this paper. FPA is a
useful measurement tool itself and can be combined with other or it
can be the basis of other methods. Therefore, we believe that FPA
may contribute greatly in field of software development and
software management. We hope that this paper gives the reader an
idea of how the FPA works and how it can be applied.
6. REFERENCES
[1] “Source Code Based Function Point Analysis for
Enhancement Projects”, Steven Klusener , Software
Improvement Group, Vrije Universiteit.
[2] “Function Point Counting Practices Manual - Release 4.1” -
International Function Point Users Group (IFPUG)
[3] http://www.kendrickhang.com/blog/?p=76
[4] http://www.softwaremetrics.com/fpafund.htm
[5] http://insidetech.monster.com/training/articles/1523-
estimating-the-size-of-software-projects