International Journal of Computer Science and Telecommunications [Volume 9, Issue 5, September 2018] 28

Limitations of Function Point for Agile Software

Environment: A Case Study
ISSN 2047-3338

Hala Hamad Osman1,2, Mohamed Elhafiz Musa1, Abdelgaffar Hamed Ahmed1

1
Faculty of Computer Science, Sudan University of Science & Technology (SUST), Sudan
2
Faculty of Computer Studies, International University of Africa, Khartoum, Sudan
1
[email protected]

Abstract– Software measurement is an important area of Also; there are no methods for estimating and monitoring the
research as it focused on the estimation of the cost and size of performance of agile projects based on a standardized
software. There are a different software estimation models that procedure [6]. FP is one of the most common used to estimate
are used in industry to provide accurate and reliable estimates of software sizing in the early phase of the software development
the software costs and size. Despite their contribution towards
process, that the reason is low maturity of the software
software estimation, such models need to be standardized,
validated, to incorporation estimation. Function Point (FP) measurement practice.
metrics are used for studying software size, productivity, quality The remainder of this paper is organized as follows: Section
and costs. FP provides good result in traditional software II is a summary of relevant theories, In Section III the
estimation environment. But, it didn’t give suitable results when research methodology is described. Section IV presents the
used for measuring agile software. This paper investigates FP results and Section V discusses the result’s validity. Finally,
analysis in agile software development measurement through section VI presents the conclusions.
two case studies developed by scrum method. This study proved
that FP in an original form is not a suitable metrics for agile
II. RELATED WORK
software estimation. Hence, this paper states that the traditional
FP needs more tangible enhancement to be used in agile software
properly.
Software measurement methods:
There are a different of software estimation methods that
Index terms– Software Estimation Models, Function Point, used in industry for providing accurate and reliable estimates
Agile Software, Story Point (SP), Using Function Point in Agile of the costs and size of software but there is not a general/
Projects and Agile Estimation Methods
complete model or method to estimate different attributes of
software (cost, size, quality). The resulting estimates are
directly related to the other aspects and activities of the entire
I. INTRODUCTION
software project such as project planning, development and
construction [1].
S OFTWARE measurement is an important aspect for both
software development methods (traditional and agile).
There are a different software estimation models that used
A) Traditional software estimation methods
in industry for providing accurate and reliable estimates of the This category includes three models: Quantitative (formal)
costs and size of software but there is not a general/ complete estimation methods [7], Ad hoc models [10] and Human –
model to estimate different attributes of software (cost, size, based models [11].
quality). The resulting estimates are directly related to the The limitations of these models include: high time
other aspects and activities of the entire software project such consuming and expensive, difficulty of use by non-technical
as project planning, development and construction [1]. personnel, extensive training is required and the value will not
Software measurements methods s are growing and can be be known until the software is fully developed [1], [8], [9] in
classified into three categories are: quantitative (formal), addition are not satisfactory for the customers. [10]
expert judgment-based (human-based) and ad hoc methods furthermore the Human-based model is that the estimates are
(others). [2] Agile software methodologies introduced some based on an opinion and experience of the estimators which
of models and techniques to estimate software sizing and may not guarantee the accuracy of results [1], [12], [13].
many aspects of software development [3], [4]. So all these
methods have drawbacks that challenge their ability to offer B) Agile software estimation models
accurate and satisfactory results. Furthermore; the velocity In Agile software estimation models expert opinion,
that introduces the team’s rate of progress is measured at the analogy, or disaggregation are used to arrive at the estimates
end of the iteration which makes it less dynamic [4], [5].

Journal Homepage: www.ijcst.org

 Hala Hamad Osman et al. 29

of the story points [11], [14], [15] There is no set formula for studies to reflect on the applicability of FP analysis in agile
defining the size of a story that is a key problem in the agile environments. The main questions of this study are:
software metrics [16], [17]. However, these models suffer i) Can a systematic metric be used for Cost, Size and
from some drawbacks in somewhere and may results is not Duration (CSD) estimation in agile software?
satisfactory, because story points' counting and velocity differ ii) Can function point analysis be used alone to estimate
from a team to another, is difficult to use them to estimate the size for agile development projects?
time duration objectively and it’s not sufficient to size
measuring [5], [11], [17]. B) Limitations of FPA in agile environnements
C) Function Point - enabled in agile projects When we want to develop any system by agile method,
organized the system requirements into story form to prepare
Function Point is an indirect quantitative measure of product backlog that includes features, bugs, technical work
application software functionality and size; also for studying [27] When wanted to express feature we use user story that is
software productivity, quality, costs, risks, and economic a high level definition of a requirement containing enough
value. Also; FP can be estimating cost software very well information [27], [28].
because it acts as a basis for software measurement,
comparison, and analysis and its can provide a mechanism to C) Case Studies
track and monitor scope creep. [4] [17] many steps in [18]-
[21] to calculate FP in accurate way especially in traditional The used case studies follow these steps:
software development. In [22], [23] [24] conducted it's i) Collect all system requirements in user story form
difficult to count the functions of a software system when we (Product backlog).
try to use on modern software development. ii) Break down the user stories into small task (Sprint
In recent years, many researches on function point metric backlog).
were proposed to improve software size estimation by iii) Mapping small tasks into corresponding FP’ elements
redefine Unadjusted Function Point to be suitable with to estimate software size and effort form small tasks
specific kind of application domain [22] or add new System (step 2).
General Characteristics (SGC) to be adopted with new field of
iv) List the problems and difficulties faced the team when
software development. [25] Many difficulties exist when
they built the above three steps
some are metrics to estimate the size and cost of agile
software by using traditional metrics such as FP, COCOMO; Step 1 and 2: user stories form and small tasks from stories:
due to the nature of agile software. While Story point is not
Case study 1: taken from [16] about Deep Black and white
sufficient alone to record an accurate result [17] FP can
game
compatible with story points to estimate software size on agile
Case study Two: about E- Registration System developed
projects. [4], [17] These studies concluded with theoretical
by T&M Company
relationship between Story Point and function Point but not
empirical study. Also; the process of calculation FP from Step 3: mapping small tasks into corresponding types of FP:
user story and story point need more details and analysis, and
specific tasks for each story. [17], [19] The strengths of the
FP include its increasingly wide use in software contracts, can Table I: Mapping of small tasks into corresponding FP’ elements
be used to determine whether a tool, a language, an
environment, is more productive when compared with others
and can be used for measuring size software applications No Task Types of FP Case No
accurately and independent of languages or tools [19], [26].
On the contrary there are some weakness as: function points Draw empty board External Input (EI)
1 1
are almost never used on large systems > 10,000 function
points in size, that is causes it counting is slow [4], [19], [27] Write automated test for
2 ILF 1
According to [28] function point metrics can easily become a ship win
universal metric used for all software applications and for all Have move engine
software contracts in all countries. However, there are some External output
3 pursue an unblocked 1
logistical problems with function point metrics when used to (EO)
ring
estimate agile software sizing that need to understand,
analysis, adaptation and overcome in order for function point Automate test cases for
5 Unspecified 2
metrics to become the primary metric for agile software making activated code
measurement.
Identify test cases for
6 Unspecified 2
III. METHODOLOGY payment process

7 Design errors massage. EI, EO 2

A) Introduction
Upload a lecture video
The methodology used in this study based upon 8 Unspecified 2
constructive and action research method. This study uses case (storage constraint).
International Journal of Computer Science and Telecommunications [Volume 9, Issue 5, September 2018] 30

IV. RESULTS importance to this code. Also, the team of agile development
is one important factor to deliver useful product to the
Step 4: List the problems / difficulties: customer, (GSC) not include any factor or character related to
Some problems emerged as a result of implementing the the team’ velocity.
above three steps, these are:
V. CONCLUSION
Problem 1:
Function Point is one of the most popular metrics widely
It is difficult to estimate effort / size related to projects
used in traditional software measurement and it became a
accurately, because at the planning phase of the project there
standard metrics in software industry, while story point
is uncertainty about the project scope, due to the rapid change
considered as main metrics in agile software sizing, especially
in the requirements in the agile software development
in scrum and XP methodologies.
(Case study 1).
Story point alone didn’t give accurate results when used in
Problem 2: agile projects; also FP in its original form didn’t obtain
suitable and successful results. Many studies investigated new
User story express customer’s needs that involve more
approaches to produce best results in the field of agile
detailed in developing the features, risks, complexity and all
software measurement that are combination between FP and
quality and technical requirements. In addition, story point
SP.
estimate complexity of the story, while function point does
Many publications addressed some factors that have direct
not cover non-functional requirements (Case study 1, 2).
impact on agile estimation process, but these factors in most
Problem 3: researches proposed without any assigning of specific
measuring value. Also, some researches proposed new form
Calculation of function point from a story is more difficult
of FP which is a suitable to work in agile environment by
to apply, since:
extend and enhance one of the two categories of FP, the first
a). It requires detailed analysis about the user story that it’s is unadjusted FP, the second is adjusted FP but not both
not available on agile project due to the nature of categories.
documentation in this field. From above discussion and case studies, it’s clearly that FP
b). It is written in natural language form, may lead to in its original form is not appropriate metrics to estimate agile
different results in the size measuring due to software size. So; there is a real need to enhance FP by
ambiguous and variation in the language and lead to the modifying and replacing the unadjusted and adjusted FP for
errors in case of inexperienced agile team mainstreaming with agile software environment.
c). Some system holds huge volume of data. FPA rarely Also; there is no single technique that is best for all
considers the data storage. In addition, it does not situations. Therefore, story point is not sufficient alone, so
consider the size of simulations, animations and combination between SP and FP may provide more
additional document effects (Case study 2). accurate results.
Future Work: Future work on software measurement will
Problem 4:
encompass both theoretical and practical activities. On
In some cases; the development team focuses on the tasks theoretical side, studies are needed to use multi_ measurement
that help them to develop the system, regardless of classifying techniques that an important area to analyze and investigate.
specific tasks into design, code, test, etc. Many studies focused on using only one metric for estimating
This may complicate the extraction of FP from stories too software size.
much. Since, all these tasks -which are the real work of agile On the application side, measurement needs to be
development- are not related directly to any types of FP introduced in traditional applications environments and in
unadjusted counting. So, the elements of FP are not suitable new ones, such as Service Oriented Architecture (SOA) and
when software development methodology become modern cloud computing applications. Our future work will focus on
such as agile software (Case study 1). the extension and improvement for Function Point metric to
Problem 5: be adopted and used in reliable way in the agile environment.

General System Characteristics (GSC) are used to adjust

Function Points that are not sufficient for agile development,
because there are many factors have influence on the agile
project not shown in (GSC). FPA not much considering data
transfer facilities. However; some systems have fund transfer
facilities, which require high end security codes. Each line of
this code has much weight. FPA does not reflect the
 Hala Hamad Osman et al. 31

Table II: Summary of problems for all case studies

No. Problems C1 C2 Recommendation Suggested Solution

requirements
Nature of agile
1 changing, scope √ √ Iterative model
software
creep
No relationship
Redefine factors of FP to
between real tasks
2 - √ - compatible with agile
and current FP
concepts and practices.
unadjusted count,
a). story card alone not
sufficient to calculate
Model for story C’s
FP
3 Difficulty to apply √ √ Card, conversation,
b). not all tasks in
confirmation
template can apply to
any system
General system
characteristics
Questionnaire
(GSC) are used to
To determine which factors
4 adjust Function √ √ -
influence on agile’ team.
points are not
Velocity
sufficient for agile
development,

REFERENCES [15]. Taghi, J., Hazura, G., & Abdul, Z., “Obstacles In Moving To
Agile Software Development Methods”, At A GlancE. Journal of
[1]. Lafferty, M., T., “Software Effort Estimation Accuracy: A Computer Science. 9 (5): 620-625, 2013 ISSN 1549-3636, 2013
comparative Study of Estimations Based on Software Sizing and [16]. Cohn, M,” User stories applied: For Agile Software
Development Methods”, PhD thesis, Capella University, 2010. Development”, Addison RXesley, Doston, 2005
[2]. J Leinonen, “Development effort estimation process in agile [17]. Sungjoo, K., Okjoo C., & Jongmoon, B, “Model-based Dynamic
software development context”, Master Thesis, 2016. Cost Estimation and Tracking Method for Agile Software
[3]. Cohn, M,” Agile Estimating and Planning”, Addison-Wesley, Development” Presented at International Conference on Computer
Reading, 2005 and Information Science. IEEE/ACIS, 2010.
[4]. Santana, C., Leoneo, F., & Vasconcelos, A, “Using function [18]. Albrecht, A. J,” Measuring Application Development
points in agile projects”, Springer-Verlag Berlin Heidelberg. pp. Productivity”, IBM Corporation, 1979.
176–191, 2011 [19]. Dekkers, C, David Consulting Group, “Story Points or Function
[5]. Hala, H., O, & Mohamed, E. M,” Survey of Agile Software Points or both”, 2015 Retrieved from
Estimation Methods: International Journal of Computer Science \http://www.ifpug.org/Articles/Dekkers-
and Telecommunications IJCST, Volume 7, Issue (3), 2016 CountingAgileProjects.pdf [accessed on 2017-05-30].
[6]. Radenko Corovic, “Agile Estimating and Agile EVM”, [20]. Pressman, R., S,” Software Engineering A Practitioner’s
unpublished Approach”, ISBN 978–0–07–3 37597–7 MHID 0–07–
[7]. Fedotova, O., Teixeira, L., Alvelos, H, “Software Effort 337597–7, 2010
Estimation with Multiple Linear Regression: review and practical [21]. Jones, C, “Estimating software cost”, tata Mc- Graw -Hill
application”, JOURNAL OF INFORMATION SCIENCE AND Edition, 2007.
ENGINEERING (ISE), 2011 [22]. Bingchiang, J, “A Specific Effort Estimation Method Using
[8]. Touesnard, B,” Software Cost Estimation: SLOC-based Models Function Point”, Journal of Information Science and Engineering
and the Function Points Model”, UNB, 2004 27, 1363-1376, 2011
[9]. Boehm, B., & Abts, C,” Software development cost estimation [23]. Gianfranco Lanza, “Function Point: how to transform them in
approaches - A survey”, Annals of Software Engineering. Vol. 10. effort? “, Measurement European Forum, Milan, Itlay, pp 127-
pp. 177-205, 2000 136, 2008.
[10]. Alverson,” Software Development Lifecycle”, Spring, CSE 403, [24]. Kemerer, C,” An empirical validation of software cost estimation
2007 models”, Communications of the ACM, Vol. 30, No. 5, pp. 416-
[11]. Moløkken-Ø, Kjetil H, & Nils C,” Combining estimates with 429, doi: 10.1145/22899.22906, 1987.
planning poker - An empirical study”, In Proceedings of the [25]. Kanakalata & Mahadevan, 2012.
Australian Software Engineering Conference (ASWEC'07), IEEE, [26]. Scott G. Retrieved from
2007 http://www.qpmg.com/pdf/articles/Quantifying_the_Benefits_Usi
[12]. F.J. Heemstra, R.J. Kusters, “Software cost estimation and control ng_Function_Points.pdf, 2016.
: lessons learned”, In European software cost modelling meeting : [27]. Jones, C, “Strengths and Weaknesses of Software Metrics”,
proceedings, 27-29 May 1992, Munich, Germany Version 5, March 22, 2007.
[13]. Shepperd, M., Schofield, C. & B. Kitchenham,” Effort Estimation [28]. Jones, C, “Function Points as a Universal Software Metric”, July
Using Analogy”, in Proceedings of International Conference on 13, 2013.
Software Engineering. pp. 170- 178, 1996 [29]. Cohn, M, Retrieved from
[14]. Ambily O. A, “Agile Software Development- An Approach to https://www.mountaingoatsoftware.com/agile/user-stories, 2017,
Light Weight From Heavy Weigh”, International Journal of [accessed on 2017-05-25].
Engineering Science and Technology (IJEST). ISSN: 0975-5462.
Vol. 3 No. 1 Jan, 2011