ICSEA 2016 : The Eleventh International Conference on Software Engineering Advances

A UML-based Simple Function Point Estimation Method and Tool

Geng Liu, Xingqi Wang, Jinglong Fang
School of Computer Science and Technology
Hangzhou Dianzi University
Hangzhou, China
email:{liugeng, xqwang, fjl}@hdu.edu.cn

Abstract—Function Point Analysis (FPA) is used to measure sum of the sizes of data and transactions is the size of the
the size of functional user requirements of software applications. application in Unadjusted Function Points (UFP).
However, the measurement process of FPA is slow, expensive and Organizations that develop software are interested in
complex. The Simple Function Point (SiFP) method has been Function Point measurement process that is reliable, rapid and
proposed as a replacement of FPA that is much faster and cheap, and that fits well in their development processes.
cheaper to apply. However, no tools supporting Simple Function However, performing FPA requires a thorough exploration of
Point measurement have yet been proposed. In this paper, we FUR, to identify and possibly weigh basic functional
aim at building a tool to facilitate SiFP measurement. components. Therefore, the measurement process can be quite
Specifically, we propose a measurement based on UML models of
long and expensive. In fact, FPA performed by a certified
requirements, including use case diagrams and domain model
function point consultant proceeds at a relatively slow pace:
(class diagrams). The proposed methodology –including a set of
guidelines for domain modeling and the mapping between SiFP between 400 and 600 function points (FP) per day, according
measure components and UML elements – makes SiFP to Capers Jones [5], between 200 and 300 FPs per day
measurement much easier to perform. In fact, the proposed according to experts from Total Metrics [6]. Consequently,
methodology is usable in the early requirements definition stage, measuring the size of a moderately large application can take
when only use case diagram and the primary class diagram too long, if cost estimation is needed urgently. Also, the cost of
illustrating the domain model (including classes' names and measurement can be often considered excessive by software
relationship among classes) are available. We used 17 academic developers.
sample applications to validate our proposal. The result shows In addition, at the beginning of a project, size estimation
that our method and tool can be used to replace manual Simple would be necessary for bidding and planning. But, FURs have
Function Point measurement in the early phases of the software not yet been specified in detail and completely, namely the
development cycle to measure the functional size of software available information is often incomplete and insufficient. So
project. the customer is only able to do approximate measurements.
The accuracy of a FP measure grows with the completeness
Keywords— Functional Size Measures; Simple Function Point; and precision of FUR specifications. When we can measure
SiFP; UML; Object-oriented measures. with the highest accuracy, we no longer need that measure. The
situation is described by the paradox illustrated in Fig. 1.
I. INTRODUCTION

Function Point Analysis (FPA) [1][2][3] aims at measuring

the size of Functional User Requirements (FUR) of software
applications. Being based on FUR, which are available in the
early phases of development, these measures are widely used
to estimate the effort required to develop software applications.
FPA was originally introduced by Albrecht to measure data-
processing systems by quantifying the functionality the
software provides to the user, from the information view, by
quantifying the volume of data flow and the storage [4]. Fig. 1. Paradox of estimation and informations about estimation
The basic idea of FPA is that the "amount of functionality"
released to the user can be evaluated by taking into account the Given the above situation, many simplified methods, such
data used by the application to provide the required functions, as Early & Quick Function Points（E&QFP) [7], Estimated
and the transactions (i.e., operations that involve data crossing NESMA [8], Simplified FP[9], ISBSG [10], ILF model [11],
the boundaries of the application) through which the and Early FP [12], have been proposed. The SiFP method
functionality is delivered to the user. Data are user identifiable [13][14][27] is different from the other methods mentioned
groups of logically related data, and are classified as Internal above, as it does not aim at providing approximate estimation
Logical Files (ILF) or External Interface Files (EIF). A of FP measures; rather, it defines a brand new functional size
transaction is a set of actions seen as one cohesive unit of work. measure, to be used in place of traditional FP.
FPA differentiates three types of transactions: External Input In this paper, we propose some rules for building UML
(EI), External Output (EO), and External Inquiry (EQ). The models in a SiFP-oriented way. Since SiFP counting is based
size of each data function depends on the type of contents; the on the identification of Unspecified Generic Elementary
size of each transaction depends on the number of data files Process (UGEP) and Unspecified Generic Data Group
used and the amount of data exchanged with the external. The (UGDG), which basically correspond to system data and

Copyright (c) IARIA, 2016. ISBN: 978-1-61208-498-5 39

 ICSEA 2016 : The Eleventh International Conference on Software Engineering Advances

process, we exploit the ability of UML to represent such

information by establishing an explicit relation between SiFP
elements and UML language constructs. We also define some
rules to measure the SiFP size of an application from use case
diagrams and the domain model, and develop a tool to
automatically measure SiFP on the base of XMI/XML files
abstracted from UML model. Throughout the paper we take for
granted that the reader knows at least the basics of FPA
measurement and is familiar with basic UML concepts.
The rest of the paper is organized as follows: Section II
explains the background knowledge about SiFP. Section III
describes the empirical study. The validity of the study is
Fig. 3. BFC Types [14]
discussed in Section IV. Related work is presented in Section
V. Finally, Section VI draws some conclusions and outlines
future work. In the case of the UGEP, the term "unspecified" highlights
that it is not necessary to distinguish whether a process is
mainly for input, or output, or what is its primary intent of data
II. BACK GROUND KNOWLEDGE-SIFP processing. Similarly, in the case of the UGDG, it means that it
is not necessary to distinguish between internal and external
This section presents a brief summary of the SiFP method. logical storage with respect to the boundary of the MSA.
For full details and explanations of the method, see the On the other hand, the term "Generic" indicates that for any
reference manual [13]. BFC there is no need to identify subcomponents in order to
SiFP method was proposed by the Simple Function Point determine BFC's complexity: all the BFCs weight equally
Association, Italy. Its basic idea is that a notion of complexity within the same type of BFC. Future developments of the
based on the number of logical data file or cross reference methodology may lead to define different functional weights
among transaction and file or subgroup of data in a file is not for each specific BFC depending on elements related to the
significant to the goal of representing functional size and of processing component of transactional BFCs that, at present, is
estimation effort or cost. In order to measure the functional size not quantitatively taken into account.
of an application, it is not necessary to identify several types of
transactions and files.
The SiFP method defines the generic software model as
shown in Fig.2, which highlights the components related to the
functional requirements of "moving" data, "processing" data
and data "storage".

Fig. 4. SiFP measurement process [13]

Fig. 2. Theory of SiFP [13]
The SiFP measurement process is represented in Fig.4. It is
a 6-step process:
The SiFP method defines and uses only two basic − Gather the available documentation;
functional components (BFCs): UGEP and UGDG, see Fig.3. − Identify application boundary;
An UGEP is defined as: "An atomic set of functional user − Determine the measurement goal and scope;
requirements conceived for processing purposes. It refers to an − Locate elementary processes (UGEP) and logical data
informational or operational goal considered significant and files (UGDG);
unitary by the user and includes all automated, mandatory and − Calculate the function size using function SiFP = 4.6
optional activities needed to meet the goal. After an UGEP is UGEP + 7 UGDG;
concluded, the measurable software application (MSA) to − Document and present the measurement.
which it belongs must be in a logically consistent state." [13]
An UGDG is defined as: "An atomic set of user requirements III. THE EMPIRICAL STUDY
having a storage purpose. It refers to a single logical data set
In this section, we introduce UML-based SiFP estimation
of interest to the user, for which information must be kept
method through a case study and present briefly the Tool
persistently."[13]
SiFPOOTool developed by us.

Copyright (c) IARIA, 2016. ISBN: 978-1-61208-498-5 40

 ICSEA 2016 : The Eleventh International Conference on Software Engineering Advances

A. The case introduction diagram contains four components. The boundary defines the
We use as the case a reduced version of a real Information system of interest in relation to the world around it. The actors
System by Lavazza [15], since it is concise and its size is are usually individuals involved with the system defined
appropriate. Its functional size in FP is already measured, so according to their roles. The use cases are the specific roles
we do not need to do it again. In our case, a system class played by the actors within and around the system. The last
diagram that involves composition and component is the relationships between and among the actors
specification/generalization meets our needs. The only and the use cases. UML provides use case diagrams, which are
drawback of this system for our study is that the use case well suited for our purposes. The boundary of the use case
diagram is relatively simple; the relationships among the use diagrams can be directly taken as the boundary of the MSA.
cases just involve the general association. But, overall, it is The correspondence between the SiFP concepts and the
suitable for our objectives. elements of UML use case diagrams is schematically described
This GymIS is an information system for Gym in Table I.
management. The application offers annual and monthly
TABLE I. MAPPING OF THE ELEMENTS BETWEEN SIFP AND UML
subscriptions. The client who subscripts the annual service
only needs to pay 12 times the cost of a month but have the SiFP UML
right of receiving 13 months service. The client and Boundary of the object that
Application boundary
owns the use cases
subscription data are stored in the system database. The former
is characterized by name, age, profession, address, and SSN. UGEP Use case
Clients can also be updated, but, once inserted, they are never User Actor
removed from the system. A subscription is characterized by UGDG locating out of the
Actor
the duration, the subscription date, the subscribing client, the system boundary
set of optional services to which the client subscribed (their
cost adds up to the cost of the basic subscription). Among the Step 2: Present UGEP using use case
optional services there is the possibility to get a monthly Use Case Diagrams indicate –as actors– the elements
medical check. outside the boundary with which the application interacts; most
The functions that the application must provide are the important, use case diagrams show the transactions. We
following: record a new client, update the client data, record a represent each UGEP as a use case.
new subscription, record the payment by a given client for a Rule 1: Each use case must represent the smallest unit of
given month, compute and print how much is due by every activity that is meaningful to the user(s), and must be self-
client for the previous months, compute the number of contained and leave the business of the application being
subscriptions that include the given service in a given period, counted in a consistent state.
and record the results of a health check. The detailed Rule 2: Relationship among the use case, extension, include,
requirements for the transactions are not presented here. The generalization, must be correctly presented.
complete FURs of the GymIS can be found in [15]; they were Rule 3：A use case that cannot be instanced must be noted
measured according to FPA rules on the basis of a traditional as "abstract" stereotype. The base use case of a cluster of use
description. The result was that the application is 67 FP. case formatted by generalization must be noted as "abstract"
stereotype.
B. SiFP-oriented modeling By applying the rules above to the GymIS the use case
UML-based SiFP estimation method works well only if the diagram reported in Fig. 5 is obtained.
given models incorporate all the required information at the
proper detail level and the modeling and measure rules are
defined according to the SiFP theory. In this sub-section we
define the SiFP-Oriented modeling methodology as a set of
guidelines. For the purpose of modeling, we use UML as
defined in [16]. We do not define extensions or force the
semantics of the language. This choice contributes to
minimizing the impact of the measurement-oriented modeling
on the development process, and to make the adoption of the
method as seamless as possible.
Usually, the activity of creating OO models is not
sequential; rather, it is often iterative, with several refinements, Fig. 5. Use case diagram of the GymIS
deletions, extensions, and modifications of the model. In order
to keep the presentation clear, we present the modeling Step 3: Present UGDG using domain class
methodology as a sequence of conceptual steps. Usually, the methods proposed in the literature for
measuring the functional size of UML models map the concept
Step 1: Present application boundary of data functions onto (sets of) classes. The difficulties in
The first objective of the model is to represent the matching classes and logic files are exemplified very well in
application boundaries and the external elements that interact [18], where four different manners of identifying logical files
with the system to be measured. are defined, according to the different possible ways to deal
A use case diagram is a graphic depiction of the with aggregations and generalization/specializations
interactions among the elements of a system. A use case relationships.

Copyright (c) IARIA, 2016. ISBN: 978-1-61208-498-5 41

 ICSEA 2016 : The Eleventh International Conference on Software Engineering Advances

Although in several cases it is possible to identify a class as Rule 5: Entity classes that appear in the domain model
a logic file, it is also quite common that a single logic file diagram are the candidates for UGDG. Entity classes appear in
corresponds to a set of classes. domain model must be complete, namely, no entity class be
In object-oriented development process, such as ICONIX missed. Each entity class should have its name, and the
processes [17], the modeling process of static model can be relationships among the entity classes should be complete.
split into three stages: 1) requirements definition, 2) analysis, Rule 6: Each entity class must be noted as stereotype
conceptual design and technical architecture, 3) design and <<Entity>>.
coding. The obtained models are domain model, updated Rule 7: In general, a UGDG corresponds to an entity class
domain model and Class model -as shown in Fig. 6- which (see the class User and Payments in Fig.7). A relevant
separately correspond to three types of diagram: domain class exception is given by clusters of classes that are connected by
diagram, updated domain class diagram and class diagrams. composition relations (see the set classes consist of
HealthRecord and Result in Fig.7), or generalization relations
(see the classes Subscription, MonthScription and
AnnualScription in Fig.7). A cluster of classes that are
connected by composition or generalization relations is defined
as one UGDG.

TABLE III. MAPPING OF THE ELEMENTS

SiFP UML Class(es) #UGDG
Fig. 6. Static domain model of OO development using ICONIX process
UGDG association 1 1
Information presented by domain diagram contains names UGDG aggregation 1 1
of the entity objects, and the relationships among these entity UGDG composition a cluster of 1
objects; updated domain class diagram is added boundary
UGDG generalization a cluster of 1
objects and controllers. Also the attributes of each entity class
abstracted from use case specification are equipped; Class UGDG locating out of logic data
1 1
the system boundary component
diagram contains all the information mentioned above, and
some controllers are changed into one or more operations and
Rule 8: When necessary, add to the domain model one or
those operations are assigned to corresponding class. Analysis
more special class(es) to present the external system logical
and comparison about different types of objects at different
data: these class(es) are named as external UGDG(s) and are
stages is shown in Table II. Through the above analysis we can
stereotyped <<XUGDG>> (see class otherSystem in Fig.7). A
see the domain class diagram already fully meets the demand
class diagram with added special classes is called an extended
for measuring the data "storage" part of SiFP except that it
class diagram.
doesn't have the ability to present the UGDG located outside
By applying the rules above to the Gym IS, the extended
the system boundary.
class diagram reported in Fig. 7 was obtained.
TABLE II. ANALYSIS ADN COMPARISON ABOUT DIFFERENT TYPES OF
OBJECTS
Update
Domain Class
Domain
Model Model
Model
Entity Yes Yes Yes
Stereotype
Controller / Yes Yes
of Class
Boundary / Yes Yes
Class Name Yes Yes Yes
Information Relationship Yes Yes Yes
about entity
class Attributes / Yes Yes Fig. 7. Extended Class diagram of the Gym IS
Methods / / Yes C. Counting and summing
Suitable for SiFP measure Yes Yes Yes Here our SiFP counting procedure is redefined with respect
to the UML model with the following goals: it must be
coherent with the principles reported in SiFP reference manual
Since for any BFC there is no need to identify [13]; it must be precise, without ambiguities, thus leaving no
subcomponents in order to determine BFC complexity. We space to the measurer for interpretation; it must require little
define some rules as following: effort; it must be executable by people without big skill in FP
Rule 4：SiFP does not distinguish between internal and counting and with little knowledge of the requirements.
external UGDG, but in order to facilitate the later statements, As mentioned earlier, a UGEP is represented as a use case,
we divided UGDG into two types: external UGDG and internal but not every use case should be counted as a UGEP. By
UGDG. Internal UGDG is the UGDG that locates inside of the analyzing the role and the characteristics of each use case
system boundary, external UGDG locates outside of the system belonging to a set of use cases connected by include, extension
boundary.

Copyright (c) IARIA, 2016. ISBN: 978-1-61208-498-5 42

 ICSEA 2016 : The Eleventh International Conference on Software Engineering Advances

or generalization relations (see Table IV), and according to company which holds the application (see Fig. 9), the measurer
SiFP rules, we define rule 9. that carries out the measurement are all recorded by the tool to
meet the needs for analysis and inquiries.
TABLE IV. COMMON ELEMENTS FROM GENERAL MODEL AND FPA
ORIENTED UML MODEL
for
Type of UC Role of UC Complete Abstract measure
unit
Base UC Yes No Yes
Include
Inclusion Yes No Yes
Base UC Yes No Yes
Extension
Extension Yes No Yes
general UC No Yes No
Fig. 9. Information input interface of the tool
Generalization Specialized
Yes No Yes
UC
We measure the GymIS software application using our tool
Rule 9：In general, a use case is counted as a UGEP. A SiFPOOTool: 5 UGDG and 7 UGEP were identified, thus the
total size is 67.2 SiFP.
relevant exception is that the use case noted as abstract is not
counted as a UGEP. IV. EMPIRICAL VALIDATION
Rule 10: As defined by the rules 4-8, whether it is a single
class or a group of classes, as long as it is defined as a UGDG, We aimed to validate the two issues: the first one is
it is counted as a UGDG. whether the tool can be used to replace the manual SiFP
Rule 11：A class stereotyped <<XUGDG>> is counted as measurement, when a UML requirement model is available.
a UGDG. The second is to validate whether our SiFP-oriented UML
Once the UGEP and UGDG lists are complete, the scores modeling rules are correct. The validation overview is shown
are assigned to the individual BFCs and added together as in the Fig.10.
shown below. The scores to assign to each individual BFC are:
UGDG = 7.0 SiFP and UGEP = 4.6 SiFP.
So the size of a whole application is:
SiFP=M(UGEP)+M(UGDG)= #UGEP*4.6 + # UGDG*7.0.
Here #X means the number of X.
According to the conversion between SiFP and UFP
defined in the SiFP reference manual, we can draw the
following equation to calculate the FPA functional size from
the SiFP value:
UFP = #SiFP /0.998
Fig. 10. Validation overview
D. Measure Tool for SiFP
There are several UML modeling tools which support OO
We used 17 projects' models mainly prepared during
modeling, such as Visio, Rational Rose, Power Designs, EA
previous work [19]. The FURs, UML models (use case
and StarUML. These tools not only provide a graphical
diagram, class diagram, components diagram, and sequence
modeling function, but also export the model as XMI and/or
diagram) and size measures (in UFP) of those projects are
XML file. Measurement tools can be designed by parsing
available.
XMI/XML document and using measurement rules. We
The experimental validation procedure was organized as
designed a measure tool SiFPOOTool to automatically
follows:
measure the SiFP size of an application by its UML model,
−Firstly, for each project, the use case diagrams are
precisely use case diagram and class diagram. The high-level
reviewed and modified according to the rules 1, 2 and 3
structure of the tool is shown in Fig.8.
defined in Section III.B.
−Second step: the class diagrams are reviewed and
modified according to the rules 4-8 in Section III.B.
−Third step: The activities involved in steps 1 and 2 are
repeated until all the projects' use cases and class diagrams
comply with the rules 1-8 in Section III.B. Using StarUML, the
XMI/XML files are exported from UML model.
Fig. 8. Theory of SiFPOOTool − The fourth step: those 17 projects are manually measured
using the SiFP method: the results are given in columns 2-4 of
The tool provides some functions, such as, reading and Table V. The correspond SiFP and UFP are also calculated
parsing XML file derived from UML model, recording and automatically and inserted in the 4th and 5th columns of the
reporting the measure result. Moreover, the related Table V. The UFP values are computed according to the
information about the application being measured, the

Copyright (c) IARIA, 2016. ISBN: 978-1-61208-498-5 43

 ICSEA 2016 : The Eleventh International Conference on Software Engineering Advances

function SiFP = #UFP*0.998 described in the reference manual the manual measurement(Column 5) and the UFP(Column 10),
[13]. the datasets of measurement based on the tool(Column 9) and
− Then we use our tool SiFPOOTool to measure each UFP(Column 10), both the two-tailed test p-values are
model XMI/XML file obtained at step 4. The results and their approximately 0.001. Then we analyzed the average of
corresponding UFPs are inserted in columns 6-8 of Table V. absolute value of the ratio of UFP based on the tool(Column 9)
To automatically obtain the UFP values, the previous function and the UFP(Column 10), it is approximately 9.95%, which is
SiFP=#UFP*0.998 was used in our tool. less than 10%, so the results obtained based on the tool is
− Finally, we copied into Column 10 the functional size acceptable. Our approach (based on UML model) belongs to
measures in UFP manually measured in the previous work. the third level, detailed measurement level, of the six accuracy
When all the preparatory work was finished, we performed levels for software sizing defined in [20][21].
three paired sample t-Tests on the datasets of manual In conclusion, our estimation tool SiFPOOTool can be used
measurement (Column 5), of the measurement based on to replace manual SiFP measurement in the early phases of the
SiFPOOTool (Column 9) and of UFP values (Column 10) software development cycle, namely domain modeling phase,
obtained in the previous work. As usually the level of to measure the functional size of software project. As it turns
significance is set as 5%. Test results are as follows: on the out, our modeling and measure rules (Rules 1-11 presented in
datasets of manual measurement (Column 5) and of the Section III. B, C and D) lead to good experiment results.
measurement based on SiFPOOTool (Column 9), the two-
tailed test p-value is approximately 0.104. For the datasets of

TABLE V. DATASETS OF MEASUREMENTS BY HAND, USING SIFPOOTOOL

Manual Measurement Measurement Using SiFPOOTool Ratio of Ratio of Ratio of
P.ID UFP 5th/9th 5th/10th 9th/10th
#UGEP #UGDG SiFP UFP #UGEP #UGDG SiFP UFP column column column
1 15 13 160 160.3 15 13 160 160.3 160 0.00% 0.20% 0.20%
2 15 15 174 174.3 15 14 167 167.3 140 4.19% 24.53% 19.52%
3 12 6 97.2 97.4 12 3 76.2 76.4 84 27.56% 15.95% -9.10%
4 22 10 171.2 171.5 22 11 178 178.6 163 -3.93% 5.24% 9.54%
5 20 6 134 134.3 20 6 134 134.3 128 0.00% 4.90% 4.90%
6 18 8 138.8 139.1 18 9 146 146.1 130 -4.80% 6.98% 12.38%
7 16 3 94.6 94.8 16 3 94.6 94.8 78 0.00% 21.53% 21.53%
8 15 8 125 125.3 15 6 111 111.2 107 12.61% 17.06% 3.95%
9 17 7 127.2 127.5 17 5 113 113.4 102 12.37% 24.96% 11.20%
10 7 8 88.2 88.4 7 8 88.2 88.4 79 0.00% 11.87% 11.87%
11 18 7 131.8 132.1 18 5 118 118.0 105 11.88% 25.78% 12.42%
12 28 4 156.8 157.1 28 4 157 157.1 138 0.00% 13.85% 13.85%
13 22 5 136.2 136.5 22 5 136 136.5 124 0.00% 10.06% 10.06%
14 13 2 73.8 73.9 13 2 73.8 73.9 73 0.00% 1.30% 1.30%
15 20 3 113 113.2 20 3 113 113.2 106 0.00% 6.82% 6.82%
16 27 6 166.2 166.5 27 6 166 166.5 159 0.00% 4.74% 4.74%
17 14 5 99.4 99.6 14 5 99.4 99.6 86 0.00% 15.81% 15.81%

established in September 1989. The committee investigated

V. RELATED WORK whether FPA can be used to perform an indicative size
estimate before a complete logical (detailed) design is available
The generic concepts of FPA were published in the late [23].
1970s. Later, more detailed measurement rules were developed Many techniques for early size estimation have been
to improve consistency of measurement. Due to lack of good proposed for FP, such as component sizing technique by
software documentation, it is not always possible to apply all Putnam and Myers [24] and the Early and Quick Function
the detailed rules, and measurers must fall back on Point size estimation techniques by Conte et al. [25]. These
approximation techniques [22]. methods – such as Estimated NESMA method [8], ISBSG
In [22] M. Lelli and R. Meli announced this as a paradox: average weights, simplified FP [13], prognosis of CNV AG [11]
Size estimation is necessary when we do not have enough and so on - do not require the weighting of functions; instead
information (thus, early estimation methods must be used to each function is weighted with average values.
obtain it). When we can measure with the greatest accuracy, Some methods extrapolated the FP counts from the
we no longer need that information any more. countable components (usually the ILFs) using statistical
In order to figure out whether FPA in the early phases is a methods (mostly regression analysis). Some simplified
realistic option, the committee "FPA" in the early phases” was

Copyright (c) IARIA, 2016. ISBN: 978-1-61208-498-5 44

 ICSEA 2016 : The Eleventh International Conference on Software Engineering Advances

methods – Mark II, NESMA’s Indicative FP, Tichenor ILF [7] "Early & Quick Function Points for IFPUG Methods v.3.1 Reference
Model, Prognosis by CNV AG, and ISBSG Benchmark – were Manual 1.1", April 2012.
constructed according to such technique. [8] ISO/IEC 24570: 2004, "Software Engineering-NESMA Functional Size
Measurement Method version 2.1 - Definitions and Counting Guidelines
In [15] Lavazza et al. proposed a FPA-oriented UML for the Application of Function Point Analysis", International
modeling technique that can make FPA performed in a Organization for Standardization, Geneva, 2004.
seamless way, while yielding reliable results. In [26] del [9] J. Geraci and C. Tichenor, "The IRS Development and Application of
Bianco et al. introduced the model-based technique into the Internal Logical File Model to Estimate Function Point
COSMIC method and suggested a simplified model-based cost Counts,"1994. Presented at the Fall 2000 IFPUG Conference.
estimation models. By using the data from a large popular [10] L. Bernstein and C. M. Yuhas, "Trustworthy Systems Through
public dataset Lavazza and Meli confirmed that SiFP can be Quantitative Software Engineering", John Wiley & Sons, 2005.
effectively used in place of IFPUG [14]. However, there has [11] M. Bundschuh, "Function Point Prognosis Revisited", FESMA 99,
been no measure tool for SiFP so far. Amsterdam, The Netherlands, October 4-8, 1999, pp. 287–297.
http://www.academia.edu/1024603/FUNCTION_POINT_PROGNOSIS
_REVISITED, retrieved:June, 2016.
VI. CONCLUSIONS AND FUTURE WORK [12] R. A. Monge, F. S. Marco, F. T. Cervigón,V. G. García, and G. U. Paino,
"A Preliminary Study for the Development of an Early Method for the
Performing Function Point measurement according to the Measurement in Function Points of a Software Product", Eprint Arxiv
Cs, 2004.
traditional process is expensive and time consuming. The SiFP
was proposed as a replacement of FPA. Functional size is [13] SiFPA, "Simple Function Point Functional Size Measurement Method -
Reference Manual, V. SiFP-01.00-RM-EN-01.01",
mainly used for estimating development costs and project http://www.sifpa.org/en/index.htm, retrieved: June, 2016.
planning. Many software developers use UML, hence they are [14] L. Lavazza and R. Meli, "An Evaluation of Simple Function Point as a
interested in basing functional size measurement on UML Replacement of IFPUG Function Point", in 9th Int. Conf. on Software
models. In principle, UML-based estimation can be used Process and Product Measurement (Mensura) IWSM-MENSURA 2014,
effectively at the earliest stage of software: our proposal makes October 6-8, 2014, Rotterdam.
this possibility practical and viable. Additional researches [15] L. Lavazza, V. del Bianco, and C. Garavaglia, "Model-based Functional
(concerning both measurement technology and measurement Size Measurement", 2nd International Symposium on Empirical
Software Engineering and Measurement (ESEM 2008), Oct. 9-10, 2008,
tools) are necessary to support functional size measurement in Kaiserslautern, Germany.
different stages of software development. [16] OMG–Object Management Group, "Unified Modeling Language:
ACKNOWLEDGMENT Superstructure", version 2.1.1, OMG formal/2007-02-05, February
2007. (available from http://www.omg.org)
[17] D. Rosenberg and M. Stephens, "Use Case Driven Object Modeling
The authors thank Prof. Luigi Antonio Lavazza from the with UML Theory and Practice", Apress, Berkeley, USA, 2007.
University of Insubria in Varese, Italy, for his constructive [18] G. Antoniol, C. Lokan, G. Caldiera, and R. Fiutem, "A Function Point-
suggestions and comments on this research. The authors also Like Measure for Object-Oriented Software", Empirical Software
thank Jun Wu for his contribution to the implementation of the Engineering , Volume 4, Issue 3, pp 263–287, Sept. 1999.
first version of the tool. The research presented in this paper [19] G. Liu, "Towards Making Function Size Measurement Easily Usable in
has been supported by the Start Project Foundation of Practice", PhD thesis, University of Insubria, Varese, Italy, 2014.
Hangzhou Dianzi University under Grant No. KYS105614069, [20] P. Hill, "Software early lifecycle- Function sizing", SoftwareTech, June
by the Defense Industrial Technology Development Program 2006, Vol. 9, No.2.
under Grant No. JCKY2013415C001 and Grant No. [21] Total Metrics, "Levels of Function Points, Version 1.3", January 2004,
JSZL2014415B002, and by Weapon Equipment Pre-Research http://www.totalmetrics.com/total-metrics-articles/levels-of-function-
point-counting, Total Metrics, 2004.
Foundation under Grant No. 9140A15040214DZ04221.
[22] M. Lelli and R. Meli, "from Narrative User Requirements to Function
Point", IN: Proceedings of Software Measurement European Forum-
REFERENCES SMEF 2005, Mar. 16-18, 2005, Rome, Italy.
[1] A. J. Albrecht, "Measuring Application Development Productivity", [23] NESMA, "The Application of Function Point Analysis in the Early
Joint SHARE/ GUIDE/IBM Application Development Symposium, pp. Phases of the Application Life Cycle - A Practical Manual: Theory And
83-92, 1979. Case Study, V. 2.0",
[2] International Function Point Users Group, "Function Point Counting http://www.nesma.nl/download/boeken_NESMA/N20_FPA_in_Early_P
Practices Manual - Release 4.3.1", January 2010. hases_(v2.0).pdf, retrieved:June, 2016.
[3] ISO/IEC 20926: 2003, "Software engineering – IFPUG 4.1 Unadjusted [24] L. H. Putnam and W. Myers, "Measures for Excellence: Reliable
Functional Size Measurement Method – Counting Practices Manual", Software on Time within Budget", Prentice Hall, UpperSaddle River,
Geneva: ISO, 2003. 1992.
[4] A. J. Albrecht and J.E. Gaffney, "Software function, Source Lines of [25] M. Conte, T. Iorio, R. Meli, and L. Santillo, "E&Q: An Early & Quick
Code and Development Effort Prediction: a Software Science Approach to Function Size Measurement Methods", In Proceedings of
Validation", IEEE Transactions on Software Engineering, vol. 9(6), Software Measurement European Forum-SMEF 2004, January 28-30,
pp.639-648,1983. 2004, Rome, Italy.
[5] C. Jones, "A New Business Model for Function Point Metrics", [26] V. del Bianco, L. Lavazza, and S. Morasca, "A Proposal for Simplified
http://www.itmpi.org/assets/base/images/itmpi/privaterooms/capersjones Model-Based Cost Estimation Models", In Proceedings of 13th Int.
/FunctPtBusModel2008.pdf, retrieved: June, 2016. Conf. on Product-Focused Software Development and Process
[6] Total Metrics, "Methods for Software Sizing – How to Decide which Improvement, pp. 59-73, June 13-15, 2012, Madrid, Spain.
Method to Use", http://www.totalmetrics.com/function-point- [27] F. Ferrucci, C. Gravino, and L. Lavazza, "Assessing Simple Function
resources/downloads/R185_Why-use-Function-Points.pdf, retrieved: Points for Effort Estimation: an Empirical Study", 31st ACM
June, 2016. Symposium on Applied Computing, April 4-8, 2016, Pisa, Italy.

Copyright (c) IARIA, 2016. ISBN: 978-1-61208-498-5 45