implementation of function point aalysis for software effort estimation

7/25/2019 Implementation of Function Point Aalysis for Software Effort Estimation

1/6

Implementation of Function Point Analysis

for Software Effort EstimationAbstract

*Gaurav Chakrabarty

*MSc I!" MSc 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. unction !oints can be estimated from requirement

specification or design specification which ma"es it possible to estimate effort in early phases of development. This

paper discusses the unction !oint #nalysis and its utili$ation for effort estimation. urther, 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 "ey factor to avoid project failure.

#eywor$s% Estimation Metho$s" Effort estimation" Function Point Analysis" &'C" FP

() Intro$uction

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 conte%ts. 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. 'mpirical studies usually involve the

collection and analysis of data and e%perience that can be used to characteri$e, evaluate and reveal relationships

between software development deliverables, practices, and technologies.()*

or estimation of software cost and effort a number of parameters should be considered among which the si$e of the

product and to translate the estimated si$e into effort, time and cost is the most vital. The estimation of effort and

cost depends on the accurate prediction of the si$e. 'ffort and cost estimations are difficult in the software projects

because projects are often not unique and the managers or developers have no bac"ground or previous e%perience

about them. +onsequently, the prediction of aforesaid parameters remains a comple% tas". #lthough 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 li"e comple% and dynamic interaction factors, intrinsic

software comple%ity, pressure on standardi$ation and lac" of software data, it is unrealistic to e%pect very accurate

effort estimation of software development processes (*.

unction !oints -! was originated in )/0/ and widely accepted from both academics and practitioner and the

research in this area is generally "nown as Function Point Analysis FPA+ or Function 'riente$ Si,eMeasurement FSM+. The ! measurement could be classified into ! counting and estimation. !# provides a

standardi$ed 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.

#n estimation model for computer software uses empirical derived formulas to predict effort as a function of 1ine of

+ode -1O+ or unction !oint -!. The estimation models can be categori$ed based on their basic formulation

schemes as estimation by e%pert, analogy based estimation schemes, algorithmic methods including empirical


2/6

methods, rule induction methods, artificial neural networ" based approaches, 2ayesian networ" approaches,

decision tree based methods and fu$$y logic based estimation schemes (3&))*. #mong 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.

-)Estimation Metho$s

'ffort and si$e 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, e%pert judgment, and reasoning by analogy.

4enerally, most effort estimation models rely on empirical derivation, using regression analysis of a collection of

historical project data. These models usually ta"e a software si$e as input to estimate its development effort, where

the si$e measurement can be either 1ines of +ode -1O+ or unction !oints -!. The 1O+&based models are

mostly nonlinear, and their estimated effort is at least quadratic to the si$e. Other models based on function points

are not5 the effort relates linearly to the function points ()*. Other recent methods include 6achine learning models

for si$e and7or effort estimation and they include case&based reasoning, fu$$y logic, neural networ", and many

others. 8owever, 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.

# typical estimation model is derived using regression analysis on data collected from past projects. The overall

structure of such models ta"es the following form ()*

E.A/B* ev+C

where9 Eis effort in person&months,

A,B, and Care empirically derived constants,

evis the estimated variable -1O+ or !.

-( &ine of Co$e &'C+ Estimates

1O+ is software metric used to measure the si$e of software program by counting the number of lines in the te%t of

the program:s source code. The estimation parameter 1O+ includes the number of all commands and data definition

but it does not include statements such as comments, blan"s, and continuation lines. #fter computing the 1O+ forsoftware, its amount is compared with 1O+ of other past projects, and the si$e of project is estimated. 4enerally,

thousand 1ines of +ode -;1O+ 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 lac" of

information about requirements. 1O+ usually is computed by considering S&as the lowest, S0as the highest and SM

as the most probable si$e ()3*

S . S&/ 1 SM/ S0+23

-- Function Point FP+ Estimates

! denotes a family of algorithmic methods for si$e estimation. This method separately evaluates two classes of the

attributes of a software system9 si$e factors and influence factors. The ! estimation has the advantage over others ina way as from the user:s point of view the functionality of a software system, usually emerges early in a project, and

! offers the unique benefit of being applicable during the early stage, when other approaches to si$e measurement

are not appropriate.

unction !oint was introduced by #lbrecht (), )


3/6

Function

ILF

EIF

UI

UO

UIQ

This is illustrated in igure ). 'ach of these five function types is individually assessed for comple%ity and given a

unction !oints value which varies from 3 to )>. The ?eighting actor is tabulated in Table ).

Fi4ure ( Albrecht five function types

!able ( Function Point 5ei4hts

5ei4htin4 Factor

Function !ype Simple Avera4e Comple6

No. of UI 3 < @

No. of UO < > 0

No. of UIQ 3 < @

No. of ILF 0 )A )>

No. of UIF > 0 )A

The sum of all the occurrences is computed by multiplying each function count with a unction !oint ?eighting as

shown in Table I, and then the +ount Total -+T is attained by adding up all the values as follows9

CT=i=1

5

j=1

3

NijWij

?hereNijis the number of the occurrences of each function type i of the five types and Wijis the corresponding

comple%ity function point weighting value j of the three levels Simple, #verage and +omple%. inally, to calculate

the unction !oint -! following equation is used9

FP=CT

[0.65+

i=1

14

(Fi )

100

]8ere Fi (1 i14 ) are comple%ity adjustment values based on factors such as bac"up and recoveryrequirement, data communications, performance, heavily used configuration, transaction rate, online data entry, end

user efficiency, online update, comple% processing, reusability, installation ease, ease of operations, multiple sites,

facilitate change, distributed functions. 'ach comple%ity factor is rated on the basis of its degree of influence from A


4/6

through > where no influence represents a A and highly influential represents >. The summation of the fourteen

factors: values, divided by )AA and then added to a constant of A.@>, is multiplied with +T value to obtain the !.

'ven though unction !oint #nalysis -!# is well "nown, it is difficult to adopt in modern software environments,

which has been the impetus for various e%tensions ()>*. The coefficients in the comple%ity weighting factor table

given at Table ) also must be justified before implementation ()@*. The determination of the influence adjustment

factor is another problem5 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 3AB

within an organi$ation and even more across organi$ations when they are based on different estimators ()0, )C*.

#s an illustration, we consider a !ayroll system to be developed in +D language whose > unique function typesbeing counted as9 UIE3, UOE@A,UI=E


5/6

;1O+ E -)0 J @


6/6

)A. 4. 8. Subramanian, !. +. !endhar"ar, and 6. ?allace, #n 'mpirical Study of the 'ffect of +omple%ity,

!latform, and !rogram Type on Software Gevelopment 'ffort of 2usiness #pplications, 'mpirical

Software 'ngineering, vol. )), pp. >>3, AA@.

)). S. ;umar, 2. #. ;rishna, and !. S. Satsangi, u$$y systems and neural networ"s in software engineering

project management, Mournal of #pplied Intelligence, vol. , )//

implementation of function point aalysis for software effort estimation

Documents