Implementation of Function Point Analysis

for Software Effort Estimation

Abstract
*Gaurav Chakrabarty
*M.Sc. IT, M.Sc. Geoinformatics

One of the foremost reasons for failures of Software projects is improper planning and imprecise estimation of costs
and efforts. Several studies have been done in term of finding the reason of the software projects failure. It has been
observed that, poor planning, abrupt decisions at the early stages of the project, inadequate requirements
engineering, and most importantly inaccurate estimations are the most vital reasons. Software effort and cost
estimation are necessary at the early stage of the software development life cycle for the project manager to be able
to successfully plan for the software project. Unfortunately, most of the estimation models depend on details that
will be available at the later stage of the development process. Thus, the necessary reliable estimation is not
available at the early stage which leads to project failures. Function Points can be estimated from requirement
specification or design specification which makes it possible to estimate effort in early phases of development. This
paper discusses the Function Point Analysis and its utilization for effort estimation. Further, it is to be noted that no
estimation method is appropriate for all classes of software and in all developmental environments, so choosing of
proper estimation model based on the need and environment is another key factor to avoid project failure.
Keywords: Estimation Methods, Effort estimation, Function Point Analysis, LOC, FP

1.0 Introduction
Over the last decade, it has become clear that empirical studies are a fundamental component of software
engineering research and practice. Software development practices and technologies must be investigated by
empirical means in order to be understood, evaluated, and deployed in proper contexts. This stems from the
observation that higher software quality and productivity have more chances to be achieved if well-understood,
tested practices and technologies are introduced in software development. Empirical studies usually involve the
collection and analysis of data and experience that can be used to characterize, evaluate and reveal relationships
between software development deliverables, practices, and technologies.[1]
For estimation of software cost and effort a number of parameters should be considered among which the size of the
product and to translate the estimated size into effort, time and cost is the most vital. The estimation of effort and
cost depends on the accurate prediction of the size. Effort and cost estimations are difficult in the software projects
because projects are often not unique and the managers or developers have no background or previous experience
about them. Consequently, the prediction of aforesaid parameters remains a complex task. Although a great amount
of research time, and money have been devoted to improving accuracy of the various estimation models, due to the
inherent uncertainty in software development projects as like complex and dynamic interaction factors, intrinsic
software complexity, pressure on standardization and lack of software data, it is unrealistic to expect very accurate
effort estimation of software development processes [2].
Function Points (FP) was originated in 1979 and widely accepted from both academics and practitioner and the
research in this area is generally known as Function Point Analysis (FPA) or Function Oriented Size
Measurement (FSM). The FP measurement could be classified into FP counting and estimation. FPA provides a
standardized methodology for measuring the various functions of a software application. It measures functionality
from the user point of view, that is, on the basis of what the user requests and receives in return.
An estimation model for computer software uses empirical derived formulas to predict effort as a function of Line of
Code (LOC) or Function Point (FP). The estimation models can be categorized based on their basic formulation
schemes as estimation by expert, analogy based estimation schemes, algorithmic methods including empirical

methods, rule induction methods, artificial neural network based approaches, Bayesian network approaches,
decision tree based methods and fuzzy logic based estimation schemes [3-11]. Among these diversified models,
empirical estimation models are found to be possibly accurate compared to other estimation methods. The
estimation parameters in empirical estimation models are commonly derived from empirical data obtained from past
projects.
2.0 Estimation Methods
Effort and size estimations are critical to the success of a software project. Of the different techniques stated in prior
section the most popular include algorithmic and parametric models, expert judgment, and reasoning by analogy.
Generally, most effort estimation models rely on empirical derivation, using regression analysis of a collection of
historical project data. These models usually take a software size as input to estimate its development effort, where
the size measurement can be either Lines of Code (LOC) or Function Points (FP). The LOC-based models are
mostly nonlinear, and their estimated effort is at least quadratic to the size. Other models based on function points
are not; the effort relates linearly to the function points [12]. Other recent methods include Machine learning models
for size and/or effort estimation and they include case-based reasoning, fuzzy logic, neural network, and many
others. However, since the data desirable by these models typically are not obtainable at the beginning of a software
project, most can be applied only during the afterward stages of the software development process.
A typical estimation model is derived using regression analysis on data collected from past projects. The overall
structure of such models takes the following form [12]
E = A + B * (ev)C

where: E is effort in person-months,

A, B, and C are empirically derived constants,
ev is the estimated variable (LOC or FP).

2.1 Line of Code (LOC) Estimates

LOC is software metric used to measure the size of software program by counting the number of lines in the text of
the programs source code. The estimation parameter LOC includes the number of all commands and data definition
but it does not include statements such as comments, blanks, and continuation lines. After computing the LOC for
software, its amount is compared with LOC of other past projects, and the size of project is estimated. Generally,
thousand Lines of Code (KLOC) are used for estimation in large scale. Using this metric is common in many
estimation methods, although it seems very difficult at the early stages of the project because of the lack of
information about requirements. LOC usually is computed by considering SL as the lowest, SH as the highest and SM
as the most probable size [13]
S = (SL + 4 SM + SH)/6
2.2 Function Point (FP) Estimates
FP denotes a family of algorithmic methods for size estimation. This method separately evaluates two classes of the
attributes of a software system: size factors and influence factors. The FP estimation has the advantage over others in
a way as from the users point of view the functionality of a software system, usually emerges early in a project, and
FP offers the unique benefit of being applicable during the early stage, when other approaches to size measurement
are not appropriate.
Function Point was introduced by Albrecht [12, 14], the concept is based on the idea that the functionality of the
software delivered is the driver of the size of the software LOC. In other words, the more the functions delivered, the
more the Line of Codes. The functionality size is measured in terms of Function Points (FP). FPA assumes that a
software program comprises of functions and each function consists of five unique function types as namely User
Input (UI), User Output (UO), User Inquiry (UIQ), Internal Logical File (ILF), and External Interface File (EIF).

This is illustrated in Figure 1. Each of these five function types is individually assessed for complexity and given a
Function Points value which varies from 3 to 15. The Weighting Factor is tabulated in Table 1.

ILF

UO

Function

UI

UIQ

EIF
Figure 1. Albrecht five function types

Table 1. Function Point Weights

Weighting Factor
Function Type
No. of UI
No. of UO
No. of UIQ
No. of ILF
No. of UIF

Simple
3
4
3
7
5

Average
4
5
4
10
7

Complex
6
7
6
15
10

The sum of all the occurrences is computed by multiplying each function count with a Function Point Weighting as
shown in Table I, and then the Count Total (CT) is attained by adding up all the values as follows:
5

CT= N ij W ij
i=1 j=1

Where Nij is the number of the occurrences of each function type i of the five types and Wij is the corresponding
complexity function point weighting value j of the three levels Simple, Average and Complex. Finally, to calculate
the Function Point (FP) following equation is used:

14

( Fi )

FP=CT 0.65+ i=1

100

Here

Fi ( 1 i 14 ) are complexity adjustment values based on factors such as backup and recovery

requirement, data communications, performance, heavily used configuration, transaction rate, online data entry, end
user efficiency, online update, complex processing, reusability, installation ease, ease of operations, multiple sites,
facilitate change, distributed functions. Each complexity factor is rated on the basis of its degree of influence from 0

through 5 where no influence represents a 0 and highly influential represents 5. The summation of the fourteen
factors values, divided by 100 and then added to a constant of 0.65, is multiplied with CT value to obtain the FP.
Even though Function Point Analysis (FPA) is well known, it is difficult to adopt in modern software environments,
which has been the impetus for various extensions [15]. The coefficients in the complexity weighting factor table
given at Table 1 also must be justified before implementation [16]. The determination of the influence adjustment
factor is another problem; empirical studies show that each estimator demands different considerations regarding the
influence factor of the general system characteristics, and the final function points may vary by as much as 30%
within an organization and even more across organizations when they are based on different estimators [17, 18].
As an illustration, we consider a Payroll system to be developed in C# language whose 5 unique function types
being counted as: UI=32, UO=60,UIQ=24,ILF=8 and EIF=2. The weighting factors are taken as average, and then
the CT may be calculated as
Parameter
UI
UO
UIQ
ILF
EIF

Count
24
60
32
8
2

Weighting Factor
4
5
4
10
7
Count Total (CT)

Total
96
300
128
80
14
618

The complexity adjustment values are calculated as follow:

Parameter

Complexity Adjustment Value

3
2
1
4
3
1
3
1
4
3
3
3
3
5
39

Backup and Recovery

Data Communication
Distributed Processing Functions
Performance
Operational Environment
Online Data Entry
Multiple Screens/Operations
Online Updation of Master Files
Complexity of Input, Output, files & inquiries
Complexity of Internal Processing
Reusability
Installation
Multiple Installations
Ease of Use
Fi

14

( Fi )

FP=CT 0.65+ i=1

100

=618 (0.65 + 39/100) = 642.72

So, FP can be taken as 643. Further, the size of the software is attained by multiplying the FP counts with the
average number of line of codes per function point of the programming language used to transform the FP counts to
number of line of codes (LOC). The software is to be implemented with C#, the average number of line of codes per
function point for C# is 127. The line of codes measured in KLOC for this software is calculated as follows:

KLOC = (127 643)/1000=81.661

The KLOC may be rounded off to 82.
The required effort is then be estimated using LOC-oriented or FP-oriented models. Some common LOC oriented
estimation model include [13]
a)

Walston-Felix model
E = 5.2 * ( KLOC )0.91
b) Bailey-Basili model
E = 5.5 + 0.73 * ( KLOC )1.16
Some common FP oriented estimation model include
a) Albrecht and Gaffney model
E = -13.39 + 0.0545 * FP
b) Matson, Barnett, Mellichamp
E = 585.7 + 15.12 FP

In this paper, the required effort is estimated using Albrecht and Gaffney model for FP oriented estimation.
E= -13.39 + 0.0545*FP= -13.39 + 0.0545 * 643=21.65 persons-month
3.0 Conclusion
The core cause for software project failures is imprecise estimation in early stages of the project. So introducing and
focusing on the estimation methods seems necessary for achieving to the accurate and reliable estimations. Even
though estimation is a serious step for the success of a software project, but in practice, many projects still use ad
hoc methods to conduct this task. This phenomenon may result because most of the generic algorithmic estimation
models are difficult to be adopted, in that they require the collection of many detailed items that may affect the size
and effort associated with an application. Since software project managers are used to select the best estimation
method based on the conditions and status of the project, describing and comprising of estimation techniques can be
useful for decreasing of the project failures. There is no estimation method which can provide the best estimates in
all situations. So, it is necessary to understand the principals of each estimation method to choose the best.
References
1.
2.
3.
4.
5.
6.

7.

8.
9.

http://www.springer.com/computer/swe/journal/10664 ( Empirical Software Engineering journal)

Satyananda, An Improved Fuzzy Approach for COCOMOs Effort Estimation Using Gaussian Membership
Function Journal of Software, vol 4, pp 452-459, 2009
Jorgen M, Sjoberg D.I.K, The Impact of Customer Expectation on Software Development Effort Estimates
International Journal of Project Management, Elsevier, pp 317-325, 2004
Chiu NH, Huang SJ, The Adjusted Analogy-Based Software Effort Estimation Based on Similarity
Distances, Journal of Systems and Software, Volume 80, Issue 4, pp 628-640, 2007
Kaczmarek J, Kucharski M, Size and Effort Estimation for Applications Written in Java, Journal of
Information and Software Technology, Volume 46, Issue 9, pp 589-60, 2004
Jeffery R, Ruhe M,Wieczorek I, Using Public Domain Metrics to Estimate Software Development Effort,
In Proceedings of the 7th International Symposium on Software Metrics, IEEE Computer Society,
Washington, DC, pp 1627, 2001
Heiat A, Comparison of Artificial Neural Network and Regression Models for Estimating Software
Development Effort, Journal of Information and Software Technology, Volume 44, Issue 15, pp 911-922,
2002.
K. Srinivasan and D. Fisher, Machine learning approaches to estimating software development effort, IEEE
Transactions on Software Engineering, vol. 21, pp. 126-137, 1995.
A. R. Venkatachalam, Software Cost Estimation Using Artificial Neural Networks, Presented at 1993
International Joint Conference on Neural Networks, Nagoya, Japan, 1993.

10. G. H. Subramanian, P. C. Pendharkar, and M. Wallace, An Empirical Study of the Effect of Complexity,
Platform, and Program Type on Software Development Effort of Business Applications, Empirical
Software Engineering, vol. 11, pp. 541-553, 2006.
11. S. Kumar, B. A. Krishna, and P. S. Satsangi, Fuzzy systems and neural networks in software engineering
project management, Journal of Applied Intelligence, vol. 4, pp. 31-52, 1994
12. A. J. Albrecht and J. E. Gaffney Jr., Software function, source lines of code, and development effort
prediction: A software science validation, IEEE Transactions on Software Engineering, Vol. 9, 1983, pp.
639-648.
13. Pressman, Roger S. Software Engineering: A Practioner's Approach, 6th Edn., McGraw-Hill New York,
USA., ISBN: 13: 9780073019338,2005
14. A. J. Albrecht, Measuring application development productivity, in Proceeding of the IBM Applications
Development Symposium, California, October 14-17, 1979, pp. 83-92.
15. C. R. Symons, Software Sizing and Estimating, MkII FPA (Function Point Analysis), John Wiley and Sons,
Chichester, U.K., 1991.
16. B. Kitchenham, The problem with function points, IEEE Software, Vol. 14, 1997, pp. 29-31.
17. D. Garmus and D. Herron, Function Point Analysis: Measurement Practices for Successful Software
Projects, Addison-Wesley, Boston, MA, 2001.
18. R. Jeffery and J. Stathis, Function point sizing: Structure, validity and applicability, Empirical Software
Engineering, Vol. 1, 1996, pp. 11-30.