Global Journal of Computer Science and Technology

Software & Data Engineering

Volume 13 Issue 8 Version 1.0 Year 2013
Type: Double Blind Peer Reviewed International Research Journal
Publisher: Global Journals Inc. (USA)
Online ISSN: 0975-4172 & Print ISSN: 0975-4350

Software Cost Estimation using Function Point with Non

Algorithmic Approach
By Dr. N. Balaji, N. Shivakumar & V. Vignaraj Ananth
Thiagarajar College of Engineering, India
Abstract - Cost estimation is one of the most challenging tasks in project management. It is to
accurately estimate needed resources and required schedules for software development projects.
The software estimation process includes estimating the size of the software product to be produced,
estimating the effort required, developing preliminary project schedules, and finally, estimating overall
cost of the project. Nearly one-third projects over run their budget and late delivered and two-thirds
of all major projects substantially over run their original estimates. Effort is a function of size. For
estimating effort first we face sizing problem. In direct approach size is measured in lines of code
(LOC). In indirect approach, size is represented as Function Points (FP). In this paper we use both
approach with different technique.
Keywords : estimation; budget; effort; LOC; FP.
GJCST-C Classification : D.2.9

Software Cost Estimation using Function Point with Non Algorithmic Approach

Strictly as per the compliance and regulations of:

© 2013. Dr. N. Balaji, N. Shivakumar & V. Vignaraj Ananth. This is a research/review paper, distributed under the terms of the Creative
Commons Attribution-Noncommercial 3.0 Unported License http://creativecommons.org/licenses/by-nc/3.0/), permitting all non-
commercial use, distribution, and reproduction inany medium, provided the original work is properly cited.
 Software Cost Estimation using Function Point
with Non Algorithmic Approach
Dr. N. Balaji α, N. Shivakumar σ & V. Vignaraj Ananth ρ

Abstract - Cost estimation is one of the most challenging tasks method can be used either at system-level or at the
in project management. It is to accurately estimate needed

Year 2 013
component-level.
resources and required schedules for software development
projects. The software estimation process includes estimating c) Top Down Estimating Method
the size of the software product to be produced, estimating Top-down estimating method is also called
the effort required, developing preliminary project schedules, Macro Model. Using top-down estimating method, an
and finally, estimating overall cost of the project. Nearly one- overall cost estimation for the project is derived from the 1
third projects over run their budget and late delivered and two- global properties of the software project, and then the
thirds of all major projects substantially over run their original
project is partitioned into various low-level components.

D ) Volume XIII Issue VIII Version I

estimates. Effort is a function of size. For estimating effort first
we face sizing problem. In direct approach size is measured in d) Bottom Up Estimating Method
lines of code (LOC). In indirect approach, size is represented Using bottom-up estimating method, the cost of
as Function Points (FP). In this paper we use both approach each software components is estimated and then
with different technique.
combine the results to arrive at an estimated cost of
Keywords : estimation; budget; effort; LOC; FP. overall project. It aims at constructing the estimate of a
I. Introduction system from the knowledge accumulated about the
small software components and their interactions.

O
ut of the three principal components of cost i.e.,
hardware costs, travel and training costs, and e) Algorithmic Method
effort costs, the effort cost is dominant. Software The algorithmic method is designed to provide
cost estimation starts at the proposal state and some mathematical equations to perform software
estimation. These mathematical equations are based on

Global Journal of Computer Science and Technology ( C

continues throughout the life time of a project.
There are several techniques of software cost research and historical data and use inputs such as
estimation: Source Lines of Code (SLOC), number of functions to
perform, and other cost drivers.
• Algorithm Cost Model
• Expert Judgments II. Direct Approach
• Estimation by Analogy
• Top-down Estimation Source lines of code (SLOC) is a software
• Bottom-up Estimation metric used to measure the size of a software program
by counting the number of lines in the text of the
a) Expert Judgment Method program's source code. SLOC is typically used to
Expert judgment techniques involve consulting predict the amount of effort that will be required to
with software cost estimation expert or a group of the develop a program, as well as to estimate programming
experts to use their experience and understanding of the productivity or maintainability once the software is
proposed project to arrive at an estimate of its cost. produced. There are two major types of SLOC
b) Estimating by Analogy measures: physical SLOC (LOC) and logical SLOC
Estimating by analogy means comparing the (LLOC). Specific definitions of these two measures vary,
proposed project to previously completed similar project but the most common definition of physical SLOC is a
where the project development information id known. count of lines in the text of the program's source code
Actual data from the completed projects are including comment lines. Blank lines are also included
extrapolated to estimate the proposed project. This unless the lines of code in a section consists of more
than 25% blank lines. Logical SLOC attempts to
measure the number of executable "statements", but
Author α : Professor and Head Information Technology KLN College their specific definitions are tied to specific computer
of Engineering Madurai, India. E-mail : [email protected] languages.
Author σ : Assistant Professor, Department of Computer Science The COCOMO cost estimation model is used
Thiagarajar College of Engineering Madurai, India.
E-mail : [email protected] by thousands of software project managers, and is
Author ρ : PG Student, Department of Computer Science Thiagarajar based on a study of hundreds of software projects.
College of Engineering Madurai, India. E-mail : [email protected] Unlike other cost estimation models, COCOMO is an
© 2013 Global Journals Inc. (US)
 Software Cost Estimation Using Function Point with Non Algorithmic Approach

open model. COCOMO estimates are more objective Each function is classified according to its
and repeatable than estimates made by methods relying relative functional complexity as low, average or high.
on proprietary models. The most fundamental The data functions relative functional complexity is
calculation in the COCOMO model is the use of the based on the number of data element types (DETs) and
Effort Equation to estimate the number of Person- the number of record element types (RETs). The
Months required to develop a project. COCOMO has transactional functions are classified according to the
cost drivers that assess the project, development number of file types referenced (FTRs) and the number
environment and team to set each cost driver. The cost of DETs. The number of FTRs is the sum of the number
drivers are multiplicative factors that determine the effort of ILFs and the number of EIFs updated or queried
required to complete your software project. number of during an elementary process.
executable "statements", but their specific definitions are The data functions are:
Year 2 013

tied to specific computer languages.

1. Internal Logical File (ILF)
Effort is calculated by 2. External Interface File (EIF)
b
Effort= a* (Size) The transactional functions are:
2 Where ‘a’ and ‘b’ are empirically determined 1. External Input (EI)
constants. Size is length of the code in KLOC. 2. External Output (EO)
D ) Volume XIII Issue VIII Version I

3. External Inquiry (EI)

Type of project A B The actual calculation process consists of three steps:
Organic 3.2 1.05 1. Determination of unadjusted function points (UFP).
Semi detached 3.0 1.12 2. Calculation of value of adjustment factor (VAF).
Embedded 2.8 1.20 3. Calculation of final adjusted functional points.
b) Evaluation of Unadjusted FP
The Effort Adjustment Factor in the effort The unadjusted Functional points are evaluated
equation is simply the product of the effort multipliers in the following manner.
corresponding to each of the cost drivers. UFP= ΣΣFij*Zij, for j= 1 to 3 and i = 1 to 5,
For example, if your project is rated Very High where Zij denotes count for component i at level (low,
for Complexity (effort multiplier of 1.34), and Low for average or high) j, and Fij is corresponding Function
Language & Tools Experience (effort multiplier of 1.09), Points.
Global Journal of Computer Science and Technology ( C

and all of the other cost drivers are rated to be Nominal

(effort multiplier of 1.00), the EAF is the product of 1.34 c) Evaluation of Value Adjusted FP
and 1.09. Value Adjustment Factor (VAF) is derived from
The COCOMO schedule equation predicts the the sum of the degree of influence (DI) of the 14 general
number of months required to complete your software system characteristics (GSCc). General System
project. The duration of a project is based on the effort characteristics are:
predicted by the effort equation: 1. Data communications
Duration=3.67*(Effort)SE 2. Distributed data processing
3. Performance
Where 4. Heavily utilised configuration
Effort is the effort from the COCOMO effort 5. Transaction rate
equation. SE is the schedule equation exponent derived 6. On-line data entry
from the cost Drivers. 7. End-user efficiency
The Man per month is calculated by 8. On-line update
Average staffing = (Person-Months) / (Duration) 9. Complex processing
10. Reusability
III. Indirect Approach 11. Installations ease
12. Operational ease
a) Function Point Analysis (FPA) 13. Multiple sites/organisations
It begins with the decomposition of a project or 14. Facilitate change
application into its data and transactional functions. The
data functions represent the functionality provided to the Function points can be converted to Effort in
user by attending to their internal and external Person Hours. Numbers of studies have attempted to
requirements in relation to the data, whereas the relate LOC and FP metrics. The average number of
transactional functions describe the functionality source code statements per function point has been
provided to the user in relation to the processing this derived from historical data for numerous programming
data by the application. languages. Languages have been classified into
different levels according to the relationship between
© 2013 Global Journals Inc. (US)
 Software Cost Estimation Using Function Point with Non Algorithmic Approach

LOC and FP. Programming language levels and membership function, while the largest possible value
average numbers of source code statements per is 1.
function point.
e) Defuzzification
d) Fuzzy Logic Defuzzification means the fuzzy to crisp
Fuzzy logic is used to find fuzzy functional conversions. The fuzzy results generated cannot be
points and then the result is defuzzified to get the used as such to the hence it is necessary to convert the
functional points and hence the size estimation in fuzzy quantities into crisp quantities for further
person hours. Triangular fuzzy numbers are used to processing. This can be achieved by using
represent the linguistic terms in Function Point Analysis defuzzification process. The defuzzification has the
(FPA) complexity matrixes. A fuzzy set is characterized capability to reduce a fuzzy to a crisp single-valued

Year 2 013
by a membership function, which associates with each quantity or as a set, or converting to the form in which
point in the fuzzy set a real number in the interval [0,1], fuzzy quantity is present. Defuzzification can also be
called degree or grade of membership. The called as “rounding off” method. Defuzzification reduces
membership function may be triangular, trapezoidal, the collection of membership function values in to a
parabolic etc. Fuzzy numbers are special convex and single sealer quantity. 3
normal fuzzy sets, usually with single modal value, Defuzzification is the process of producing a
representing uncertain quantitative information. A quantifiable result in fuzzy logic, given fuzzy sets and

D ) Volume XIII Issue VIII Version I

triangular fuzzy number (TFN) is described by a triplet corresponding membership degrees. It will have a
(α, m, β), where m is the modal value, α and β are number of rules that transform a number of variables
the right and left boundary respectively. into a fuzzy result, that is, the result is described in terms
We take each linguistic variables as a triangular of membership in fuzzy sets. The defuzzification is
Fuzzy numbers, TFN (α, m, β), α ≤ m, β ≥ m. The applied to the value that had been obtained from the
membership function (μ(x)) for which is defined as: fuzzification process. The fuzzified output has to be
defuzzified into the real number so that it will give the
0 , x  effort that has been needed for the cost estimation.
 x - / m - , x m
µx- x / - m , mx 
µ(x)*w1 0<c(x)≤1
 , x≥
≤2

Global Journal of Computer Science and Technology ( C

D(y)= µ(x)*w2+(1-µ(x))*w1 2<c(x)≤3.5
The five major components mentioned above, µ(x)*w2+(1-µ(x))*w3 3.5<c(x)≤ 5
they have to be rated as either Low, Average, or High. µ(x)*w3+(1-µ(x))*w2 5<c(x)≤ 6.5
Ranking is commonly based on File Types Referenced, ≤8
Data Element Types and Record Element Types. File
Types Referenced (FTRs) represents the total number of
internal logical files (ILFs) maintained, read, or
referenced and the external interface files read or IV. Various Criterions for Assessment
referenced by the EI/EO transaction. Data Element Type of Software Cost Estimation
(DET) can be defined as unique user recognizable non- Models
recursive fields including foreign key attributes that are There are 4 important criterions for assessment
maintained on ILF/EIF. Record element type (RET) is a of software cost estimation models:
subgroup of data elements within an ILF/EIF. For each
of the components belonging to Transactional functions, 1. VAF (Variance Accounted For) (%):

( 1 − 𝑣𝑎𝑟(𝐸 )∗
the ranking is based on the number of files updated or − 𝐸)
referenced (FTRs) and number of data element types VAF (%) =
𝑣𝑎𝑟 𝐸
(DETs). For the data components viz., Internal Logical
Files (ILF) and External Interface Files (EIF), ranking is 2. Mean absolute Relative Error (%):
based on the number of Data Element Types (DETs)
Mean absolute error (%) =
𝑓
and number of Record Element Types (RETs). Based on ∗ 100

the ratings the domain character values are fuzzified
using the Triangular membership function. The value 3. Variance Absolute Relative Error (%):
thus obtained is called membership function output, Σ𝑓𝑓 (𝑅𝑅𝐸𝐸 −𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 )
whose domain is specified, usually the set of real VAR (%) = * 100
Σ𝑓𝑓
numbers and whose range is the span of positive
numbers in the closed interval [0, 1]. Each numerical 4. Pred (n): Prediction at level n((Pred (n)):
value of the domain is assigned a specific value and 0 Σ𝑓𝑓(𝑥𝑥)
Var x =
represents the smallest possible value of the Σ𝑓𝑓
© 2013 Global Journals Inc. (US)
 Software Cost Estimation Using Function Point with Non Algorithmic Approach

V. Experimental Results estimation can be done to achieve the better

performance.
Performance of the effort can be predicted
based on the MARE and Prediction n method. The The graph shows the variation between the
estimated effort of LOC is compared with the actual actual and estimated effort using LOC.
effort of LOC in the first graph. The estimated effort of
FP is compared with the actual effort of FP in the
second graph. The MARE of LOC and FP is compared
in the third graph. It has been clearly identified that
Function point based estimation is better than the LOC
estimation.
Year 2 013

The Table 1 indicates the lines of code with the

actual effort and the estimated effort using the cocomo
model. Both MARE analysis and Prediction n method
has been applied to the direct approach and the indirect
4 approach. The actual effort is the original effort and the
estimated effort is the one which has been done in the
D ) Volume XIII Issue VIII Version I

estimation process using the cocomo method.

LOC Actual effort Estimated effort

48 1107.3 1465.83
50 84 145
39 72 112
164 246 510
200 130 625
40.5 82.5 160.7

The next table shows the function point with

actual effort and the estimate effort.
Global Journal of Computer Science and Technology ( C

LOC in FP Actual effort Estimated effort

15.23 40 52
10.1 12 36
17 50 67
20 60 83
18 52 73
22 90 105

VI. Conclusion and Future Work

This project proposes an efficient way of
estimating the effort. The results of the estimation based
on the Direct method shows that the deviation between
the actual and the estimated effort is more. The result of
Indirect method using the algorithmic technique cocomo
model based estimation reduces the relative error and
the mean absolute relative error. So the analysis of the
effort from Direct method and Indirect method gives that
Function point based estimation is the efficient method
for the estimation process.
Though Cocomo model which is algorithmic
method is an open model. It has some limitations also.
In the FP based estimation also exists the deviation
between actual and estimated effort. So the same effort
can be implemented by using the Non algorithmic
Method. Fuzzy logic is one type of Non algorithmic
method. This fuzzy based estimation using the
Triangular Membership Function has been proposed in
this paper. In future this non algorithmic based
© 2013 Global Journals Inc. (US)
 Software Cost Estimation Using Function Point with Non Algorithmic Approach

The following graph shows the variation References Références Referencias

between the actual and estimated effort using LOC in
FP. 1. M. Boraso, C. Montangero, and H. Sedehi,
"Software cost estimation: An experimental study of
model performances", tech. rep., 1996.
2. O. Benediktsson, D. Dalcher, K. Reed and M.
Woodman, "COCOMO based effort estimation for
iterative and incremental software development",
Software Quality Journal, vol. 11, pp. 265-281, 2003.
3. T. Menzies, D. Port, Z. Chen, J. Hihn and S. Stukes,
"Validation Methods for calibrating software e_ort

Year 2 013
models", ICSE '05: Proceedings of the 27th
international conference on Software engineering,
(New York, NY, USA),,pp. 587-595, ACM Press,
2005.
4. Boehm, B., Abts, C., Brown, A. W., Chulani, S., 5
Clark, B.K., Horowitz, E., Madachy, R., Reifer, D. J.,
Steece, B. Software cost estimation with COCOMO

D ) Volume XIII Issue VIII Version I

II. Prentice-Hall, Upper Saddle River, NJ, February
2000.
5. IFPUG. Function Point Counting Practices Manual:
Release 4.0. International Function Point Users
Group, Princeton Junction, NJ, 1994.
6. Alaa f. sheta," Estimation of the COCOMO Model
Parameters Using Genetic Algorithm for NASA
Software Projects", Journal of Computer Science,
2(2):118-123, 2006.
7. Ali Idri, alain Abran and Laila Kijri, "COCOMO cost
modeling using Fuzzy Logic", International
The MARE analysis is given as follows
conference on Fuzzy Theory and technology At-

Global Journal of Computer Science and Technology ( C

lantic, 7 New Jersy, March 2000.
8. Baiely, j.w Basili, "A Meta model for Software
Development Resource Expenditure", Proc. Intl.
Conference Software Egg., pp : 107-115,1981.
9. Idri, A. and Abran, A.:"COCOMO Cost Model Using
fuzzylogic”.
10. IFPUG. Function Point Counting Practices Manual:
Release 4.0. International Function Point Users
Group, Princeton Junction, NJ, 1994.

© 2013 Global Journals Inc. (US)

Year 2 013 Software Cost Estimation Using Function Point with Non Algorithmic Approach

6
D ) Volume XIII Issue VIII Version I

This page is intentionally left blank

Global Journal of Computer Science and Technology ( C

© 2013 Global Journals Inc. (US)