Simple Function Point: a new Functional Size Measurement Method fully compliant with IFPUG 4.x

Abstract

The IFPUG Function Points method has originally been developed almost 35 years ago. The need was for a way to capture in numbers the functional value for users of a certain software application. At that moment the development process was largely "handmade" and "Lines of Code" was the main measurement method available. Detailed statements of functional user requirements (in terms of elementary fields, logical files, references to files etc.) are still used to produce a measurement of the functional value of an application. Unfortunately producing such a measure is quite costly and time consuming and requires very high professionalism in counters. In addition there are often endless discussions between customers and suppliers about complexity of Base Functional Components (BFC) due to extreme detail in elements to be used and the ambiguity of many counting rules when applied to actual specific systems. Production people are often forced to accept measurement as a necessary step but unsatisfied by the subjectivity and cost of the measurement process. Essentially, analysts and programmers consider measurement as a "unavoidable waste of time". The need for a simpler, faster and cheaper functional measurement method is there. On the other hand there are a lot of studies, contracts and asset measures made up using the IFPUG method so it is a pity to lose those resources. Simple Function Point (SiFP) is a new measurement method based only on two BFCs which is totally compliant with the IFPUG one. All the resources and contractual frameworks developed for IFPUG are valid for Simple FP as well, starting from the ISBSG productivity data base. The usage of the new method reduces cost, time and disputes, the translation of an entire measured application portfolio is immediate.

Full text

Simple Function Point: a new Functional Size Measurement
Method fully compliant with IFPUG 4.x
Roberto Meli
Abstract
The IFPUG Function Points method has originally been developed almost 35 years ago.
The need was for a way to capture in numbers the functional value for users of a certain
software application. At that moment the development process was largely “handmade” and
“Lines of Code” was the main measurement method available. Detailed statements of
functional user requirements (in terms of elementary fields, logical files, references to files
etc.) are still used to produce a measurement of the functional value of an application.
Unfortunately producing such a measure is quite costly and time consuming and requires
very high professionalism in counters. In addition there are often endless discussions
between customers and suppliers about complexity of Base Functional Components (BFC)
due to extreme detail in elements to be used and the ambiguity of many counting rules when
applied to actual specific systems. Production people are often forced to accept measurement
as a necessary step but unsatisfied by the subjectivity and cost of the measurement process.
Essentially, analysts and programmers consider measurement as a “unavoidable waste of
time”. The need for a simpler, faster and cheaper functional measurement method is there.
On the other hand there are a lot of studies, contracts and asset measures made up using the
IFPUG method so it is a pity to lose those resources. Simple Function Point (SiFP) is a new
measurement method based only on two BFCs which is totally compliant with the IFPUG
one. All the resources and contractual frameworks developed for IFPUG are valid for Simple
FP as well, starting from the ISBSG productivity data base. The usage of the new method
reduces cost, time and disputes, the translation of an entire measured application portfolio is
immediate.
1. Quick overview of existing functional measurement methods
As of January 2011 there are two main methods for functional measuring of software that
are competing on the market: IFPUG and COSMIC. There are also other ISO certified
methods but they are basically limited to the territories from which they come from
(Netherlands, UK, Finland). All methods include the steps of identifying very granular BFC
and the appreciation of complexity is based on a very detailed view of functional information.
The IFPUG method identifies transactional and data BFC types while the COSMIC method
identifies only transactional BFC, although it is also necessary to identify business objects
that have a strong correlation with data elements but which do not contribute directly to the
numerical value in FP.
1.1. Advantages and disadvantages of the existing FSMM
The main advantages of the IFPUG method are that:
• It is established by some decades of long usage
• There are many benchmarking data available in the public domain
The main disadvantages of the IFPUG method are that:
• It does not provide a layered model compatible with a modern architecture for the
development of components
• Valorizing the shared static component of data, it brings the metrics not to satisfy the
distributive property of the counts: FP (A union B) is generally lower than FP (A) +

FP (B) where A and B are two sets of requirements considered in the first case as a
single application and the second as two separate applications sharing logical files.
This is because of the rule for the elimination of identical BFC within the same
Measurable Software Application (ASM).
• It is usually considered not adequate for technological software
The main advantages of the COSMIC method are that:
• It is suitable for a wide range of types of software (business, real time, networks ..)
• It introduces the concept of layers and layered architectures
• It introduces the concept of measurement “viewpoint”
The main disadvantage of the COSMIC method are that:
• the numerical value of a measurement strongly depends on the selected viewpoint
The main common disadvantages of both methods are that:
• they require a very detailed documentation of functional user requirements
• they provide a large amount of rules that are not always easy to apply
• they are relatively easy to calculate for development by scratch but difficult to apply
to ordinary maintenance and asset management measures (the detailed functional
information is usually very unstable and the alignment among measurements and
“living software” it is costly and time consuming).
1.2. Market needs
The market requires fast, agile measurement methods, with low impact on production
processes and that require not too much specialized skills, which is reliable in results, not
dependent on technology, correlated to work, cost, duration of a project. The current metrics
only partially address these needs.
2. Research Project Goals
Establish a new functional size measurement method consistent with the framework of the
ISO 14143 family of standards that is fully compatible with the IFPUG method at the level of
results if applied to the same extent, but which is:
• easier to apply
• easier to learn
• less subject to interpretation
• less subject to "manipulation" by the technical personnel
• easier to keep aligned with the evolution of operational systems
• quickly convertible from the IFPUG method

3. Assumptions of “functional size / effort” correlation
Functional metrics are generally considered useful to give a significant contribution to the
estimation of effort, durations, staff and costs for a development by scratch or a functional
enhancement maintenance intervention.
Until the availability of public productivity data (ISBSG essentially) the expert’s
community has accepted an implicit assumption like the following:
“To obtain an acceptable statistical correlation between work necessary for the
development or enhancement maintenance of software and functional size one must
necessarily consider both the number AND the internal complexity of Base Functional
Components.”
Research conducted by DPO on a sample of over a thousand projects, counted with the
IFPUG method, showed that this assumption, at least in the context of this methodology, it is
not true. Instead the following is true:
“The accuracy of a model of relationship between work effort and functional size of
software does not diminish even when you consider exclusively the number of BFC in the
same class (transactions or data type).”
These findings (documented below) allow to consider redundant the whole system of
IFPUG rules aimed at differentiating between EI, EO, EQ and between ILF and EIF and for
determining the complexity of the single BFC (using DETs, RETs, FTRs). The consequences
of this discovery are truly extraordinary in terms of impact on the method and process for
measuring Function Points.
Using only the number of BFC, however, does not allow an immediate adoption of all
models and results obtained by the application of the IFPUG method. The research, therefore,
had also, as an essential objective, to find a weight for the new adopted BFCs that would
make the two metrics (IFPUG FP and SiFP) reliably convertible.
4. Simple Function Point base features
The new Simple Function Point (SiFP) metrics has the characteristic of measuring the
functional user requirements with the same accuracy of standard IFPUG method and of being
fully compliant with it in terms of results: that is, the conversion ratio between IFPUG FP
and SiFP is equal to 1. This means that all the available results based on the IFPUG
measures, from ISBSG productivity data to the FP unit prices in contracts, from the defect
rates to asset valuations, can be used without any modification or conversion calculation !
The Simple Function Point method is not a new technique for estimating IFPUG Function
Point metrics but it is an easily convertible alternative.
5. The measurement model
The underlying measurement model of the SiFP metrics coincides with the IFPUG 4.x
regarding the general approach, the boundary, scope, definition of the elementary processes
and logical files, with its practice, the formulas. It is different for the introduction of
viewpoints and layer (that may be used when a conversion from IFPUG is not needed) and
the use of only two BFCs:
Unspecified Generic Elementary Process (UGEP)
Unspecified Generic Data Group (UGDG)
The first is a transactional function type while the second is a data function type. No need
to differentiate EI, EO, EQ, ILF and EIF, the 'primary intent' and inherent complexity.

The values associated with each BFC provided are:
UGEP = 4,6 SiFP
UGDG = 7,0 SiFP
6. Conversion between IFPUG FP and SiFP
To check the convertibility of the measure from IFPUG FP and SiFP we used a sample of
768 ISBSG counts for which we had the detail count in terms of BFC and whose distribution
of the FP value (after log transformation) has been very next to the normal distribution
allowing the application of all the typical tools for statistical analysis.
The linear regression on logarithmic transformed data (UFP vs. SiFP) indicates a
coefficient of exchange rate of 1.00045341, the statistical correlation index is equal to
0.998001323. This result indicates that the two metrics are nearly coincident. Analysis of
residues is smooth and normally distributed.
‐0,4
‐0,2
0
0,2
0,4
0,6
0,8
0123456789
Residui
ln(SiFP)
ln(SiFP)Tracciatodeiresidui
0
1
2
3
4
5
6
7
8
9
0123456789
ln(UFP)
ln(SiFP)
ln(SiFP)Tracciatodelleapprossimazioni
ln(UFP)
Previstoln(UFP)
The mean and median of percentage error (taken with the sign) is zero. The average
absolute percentage error is 12% and the median 10%. Of course the percentages are related
to different dimensions and therefore not comparable with each other in terms of absolute
importance.
0,00%
20,00%
40,00%
60,00%
80,00%
100,00%
120,00%
0
20
40
60
80
100
120
‐0,5 ‐0,45 ‐0,4 ‐0,35 ‐0,3 ‐0,25 ‐0,2 ‐0,15 ‐0,1 ‐0,05 0 0,05 0,1 0,15 0,2 0,25 0,3 0,35 0,4 0,45 0,5 Altro
Frequenza
Intervalli
Distribuzionedeglierroripercentuali
Frequenza
%cumulativa

The “assets error” - or the difference between the sum of all measures with the sign made
with the IFPUG method and the sum of all measures with the sign done by the SiFP - is equal
to 0.4%, which means that the absolute errors are compensated by combining the counts as if
they were a large portfolio of applications. In fact, the overall SiFP measure exceeds the
IFPUG value of FP of only 1101 from a total of 291'139 !
An audit was also conducted on a sample of 140 other projects independent of the ISBSG
DB providing similar results.
The transition from assets counted by IFPUG FP to SiFP values is immediate if one only
knows the number of EI, EO, EQ, ILF and EIF.
7. Functional Size/Effort correlation
The correlation between effort and SiFP is identical to that between IFPUG FP and effort
for a new development and for the enhancement maintenance. The two measurements can be
used interchangeably in the determination of cost models and with the same unitary prices in
outsourcing contracts.
8. Streghts of the SiFP method
The SiFP method meets all the goals set up in the research project, since it is:
• easier to apply
• easier to learn
• less subject to interpretation
• less prone to "manipulation" by developers
• easier to keep aligned with the evolution of operational systems
• immediately convertible from IFPUG FP
In particular, we observe that the alignment of asset values as a result of the continuing
operations of small enhancements conducted within the ordinary maintenance involves a very
low cost because there is no need to document DETs, RETs and FTRs changed but only BFC
added or deleted from the baseline.
9. Future research
It is ob obvious interest to understand if similar results may be obtained using the
COSMIC FP approach. The research is undergoing.
10. References
[1] ISO/IEC, "14143-1:2007 'Information technology - Software measurement - Functional size
measurement - Part 1: Definition of Concepts'", JTC 1 / SC 7, ISO/IEC, 2007
[2] IFPUG, CPM manual v4.3.1, 2010
[3] DPO, Early & Quick Function Point 3.0 – Reference Manual v.1.3, Feb 2011
[4] ISBSG, Estimating, Benchmarking & Research Suite Release 11, 2010