Functional Size Measurement (FSM) page
Functional Size Measurement
View available documents with Acrobat Reader - Search PDF files on line
FSM roots
Functional Size Measurement (FSM) affords its roots in the late '70s, in the so-called productivity paradox well described by Capers Jones, trying to solve it overseeding the Lines Of Code (LOC) metric.
First and most used attempt in the field currently named FSM was the one by Allan J. Albrecht, from IBM, in 1979, that developed his well-known metholodology called "Function Point Analysis" (FPA). Basic point was to approach the dimensional software measurement not against an "internal" attribute such as a LOC, but facing the external functional viewpoint of a User that represents, also from a business viewpoint, the closer mechanism to the way a software contract is concluded. For a quick view on the basics for FPA counting rules, please click here.
After a revision dated 1984 by Albrecht, FPA evolution are maintained from the mid '80s by IFPUG (International Function Points User Group). Current version of the CPM (Counting Practices Manual) is the 4.2, recently released (Summer 2004). Both the CPM and related case studies are available from the IFPUG website, while a free training manual is available from David Longstreet's website.

FPA variants and evolutions
Several variants to the original Albrecht's method have been developed during years, but the most relevant ones remains mainly (in order of appearance):

COSMIC (Full Function Points)
But the most interesting FPA evolution is the Full Function Points (FFP), proposed from 1997 by and International Consortium (COSMIC - Common Software Measurement International Consortium) on lead by Dr. Alain Abran (UQAM - Université du Québec à Montréal, Canada). The method, mainly oriented towards real-time and embedded systems, can be adopted in a general-purpose context. Current version is the 3.0 (September 2007) and the Measurement Manual is downloadable for free at the UQAM FFP webpage or at the COSMIC website.

The main advantage is using COSMIC (note that from v3.0 the "FFP" suffix was deleted from the name of the method) is the usage of a process-based view with a simplified counting logic, based on four Transactional Controls (Entry, Exit, Read and Write) and two Data Groups (Updated Control Group and Read-Only Control Group) that easily allow to calculate the final (not weighted) number of FFPs. A series of case studies on COSMIC-FFPs is freely downloadable here, with particular attention to this one by Thomas Fetcke.
On December 2005, COSMICON released a new "Guideline for Sizing Business Application Software using COSMIC-FFP", with the aim "to provide additional guidance beyond that given in the ‘Measurement Manual’ on how to apply the COSMIC-FFP Functional Size Measurement (FSM) Method to size software from the domain generally referred to as ‘Business Application’ software and specifically from the End-user Measurement Viewpoint."

The following figure shows the evolution of FSM methods along these years.

ICT Standards
Furthermore, the group of experts composing COSMIC has originated an ISO proposal for the new upcoming 14143 standard. This project, developed in the JTC1/SC7/WG12 context, takes into account all the efforts profused for the FFP method, trying to generalise a way for FSM-compliant methods, according to Part 4 (Reference Model). Currently, the 14143 standard is a 5-part standard, composed as follows:

After the 14143 standard, also the single FSM methods are under ISO standardization: IFPUG FPA (20926), Mark II FPA (20968), COSMIC-FPP (19761), NESMA FPA (24570) and in a while FISMA FPA (29881).
Note that, from the field experience, for all these manuals the ISO version considers only the unadjusted value, excluding from the final count the Value Adjustment Factor.

FSM and the Web
Another open point often discussed in technical forums is the applicability of FSM to Web applications.
Because of the inner differences the programming outcomes for the Web have against the traditional ones, two main streams are concurrently going on:

FSM and UML
Again, a further discussed point is about the commonalities of UML Use Cases with the boundary drawn for establishing what to be counted in Function Point Analysis. Several studies during last years have been produced: a particular attention must be deserved to the Use Case Points, derived in the early '90s (1993) for OO software projects by Gustav Karner. Main free references to go in detail on this issue on it are:

FSM and Business Rules
Other criticisms moved to IFPUG FPA were that in an enhancement count, the IFPUG method does not account for the impact of a change to an existing function, enumerating trivial and complex changes equally; and that the IFPUG method does not account for functions (other than logical files) that do not give rise to the movement of data across the application boundary.
For this reason, Softmet in 1996 proposed a new method, called IBRA (Internal Business Rules Analysis), measuring that part of a software project and cumulative with other traditional FSMMs. Latest release is 2.1, dated May 2003.

FSM and ERP/COTS
Since the purpose and scope of a FSMM is to count the solely functional requirements of a software application, there are some difficulties in applying them to an ERP/COTS application for an enhancement count.
In particular, it is often difficult to have access to all the information useful to derive a baseline count, in particular for the data component. For instance, SAP R/3 contains closely 40000 tables and the solely HR module quite 12000. And according to the enhnancement counting rules, a huge part of the work to be performed to customize a package such this is non-functional (therefore out of the scope of the FSM count, as a simple parameters configuration or the copy of a yet existing transaction), having as a consequence a lower productivity level than for others types of "enhancement" projects.
A possible verification can be done taking a look to the ISBSG latest repository version or to any other benchmarking data source.

Some possible sources of information about functional counts for SAP R/3 are @:

Productivity Data
There are three questions stricly linked to FSMMs: how the common productivity definition is applied in ICT projects, how much an Organization is productive in order to calculate the project duration and - if we do not have FP data - how to convert our data expressed in LOCs in order to determine the project size and then all the derived metrics from the number of FSMs.
Too often there are no projects' historical databases with size data, with a consequence to search for average productivity data on the web, in publications, at the aim to derive some figures allowing the calculation of project duration. The problem is that there is no access to the original databases from which those figures have been calculated. We cannot know which kind of organizational and technical information impacting on productivity figures is behind those numbers (i.e. project typology - MIS, R/T, Web, ...- programming languages, number of project team members and expertise, tools used, ...). Therefore looking - for instance - at SoftwareMetrics.com) website, the information (derived from closely 1000 projects) that for producing 500 FPs we need 1.6 hours/FP, it is not sufficient to us for using this info in our calculations. Another webpage with productivity values is this one from Garmus & Herron, where - for instance - an "Average (number of IFPUG 4.1 FPs) of Recent Projects Across Different Platforms" for a client-server project should be equal to 16. And just comparing two authoritative sources, the discrepancy is huge, because we do not know on which data they have been calculated and therefore it is not possible to verify if those productivity data can be applied to our organization (too many information is not available).
So, which should be the right productivity to consider? The suggestion is to create as soon as possible a project database gathering main project figures - including its size (see the "Effort Estimation page") - and derive the related effort using Regression Analysis (whatever the type: Linear, Exponential, ...).
If internal data are not available, another possibility could be to use complete benchmarking project data, such as those from the ISBSG repository, filtering ad-hoc according to your needs and choosing from a dataset of more than 2000 worldwide IT projects sized with FSM methods (not only IFPUG FPs). An interesting Charismatek presentation dated 2001 about the considerable variation of PDRs using different estimation tools running the same query stresses several points to note when approaching to an effort estimation tool (and related database).

Backfiring
A related question is the one about the conversion rate between LOCs and FPs, known as backfiring. Caper Jones started to produce a Programming Languages Table derived from his own project database (thousand of projects from several application domains, as explained in his book "Applied Software Measurement"), where the average source statements per FP were reported for a series of programming languages. For instance, using COBOL we would need 107 LOCs for 1 FP; 53 LOCs in Java for 1 FP and so on. A newer and more recent backfiring table is the one by QSM (last updated in July 2005), including also data from the DavidConsulting Group. Using these figures is very quick to determine the number of FPs knowing the number of LOCs of your application (using counting tools as "Counting" for Visual C++ apps; here there is a list of other source code counter by programming language) but is heavily dependent on several factors such as the programming style, LOC definition, and so on. Imagine that a simple statement could be counted, according to the style it is written, as:
* a single physical LOC (for:command:next)
* two physical LOCs (for:command and on the following line the "next")
* three physical LOCs, one per each statement (for-command-next)
with a variability up to 3x the number of physical LOCs counted, with huge impacts when LOCs would be used directly/indirectly for estimating the project effort.
So, as said before about productivity, great attention must be paid in managing LOCs; first point should be a common and shared definition of what is a LOC inside the Organization (you can refer to a well-known SEI 1992 Technical Report by Robert Park).
The suggestion is to make a native FP count wherever possible, otherwise to consider what we call a controlled backfiring, derived only from your own project database, where it will be possible to isolate all the proxies impacting on productivity, including the FP value for such application (at least using the Application Count formula) for deriving conversion values. Also in this case, it should be considered just the sub-set of projects filtered from the database by likeness criteria. A well-known paper discussing the pros&cons of backfiring is the one by Dekkers & Gunter (pp.1-8).

Converting fsu among FSM methods
One of the more relevant issues when dealing with FSM methods is the convertibility of results from a method to another one. First experiences were done comparing IFPUG CPM 4.0 and Mk-II FPA in the late '90s (see this note), after the intra-conversion studies among IFPUG CPM versions (the so-called 'Impact Study' in Appendix B: e.g. the change from CPM 4.0 to 4.1 evaluated a -3.24% difference on 17 projects evalauted by 35 CFPS)
. More recently, there was an interest for understanding the conversion equations for moving from the so-called 'first generation FSM methods' (as IFPUG, MkII) towards the COSMIC method in order to re-evaluate the organization's project portfolio against this new method. In the COSMIC-FFP v2.2 measurement manual, Chapter 6 faced the convertibility topic; in the newest v3.0 it will be developed in a next guide entitled "Advanced and Related Topics" (coming out during 2008). Other experiences to be noted are those from:

Estimating effort using BFC
Another research topic recently started was about the evaluation if it could be better to use the overall fsu value as a independent variable in a single regression analysis or two/more BFC (Base Functional Components) for such projects, analyzing the so-called 'functional profiles'. First studies done on samples from the ISBSG repository r10 for COSMIC-FFP projects are going to support the second hypothesis.
Anyway, more research on this topic will be done in the near using different samples and criteria for a stronger validation.

Validating FPA (or another FSMM) counts
Along time, the greater attention has been devoted to the counting process for determining the functional size of a software, but few time is usually spent for discussing a formal review process for validating the number of functional units counted.
Some useful resources could be:

Quick Guides
When dealing with FSM Methods, you have to read a hundreds of pages. Therefore, in the everyday practice, it could be useful a 'summary' of main elements. Here in the following there are some 'quick guides' on a two-fold A4 sheet. In particular:

Mailing Lists - Newsletters on FSM
There are several mailing lists and Newsletters about Functional Size Measurement methods. Most important are:

Publications:
L.Buglione Misurare il software. Quantità, Qualità, Standards e Miglioramento di processo nell'Information & Communication Technology, 3rd Edition, Franco Angeli, 2008 (Chapter 2)
L.Buglione, A.Abran & R.Meli, How Functional Size Measurement supports the Balanced Scorecard framework for ICT, FESMA-DASMA 2001 (4th European Conference on Software Measurement and ICT Control), Heidelberg, Germany, May 8-11, 2001, pp. 259-272 click to download the paper Click to read the abstract
L.Buglione, F.Gasparro, E.Giacobbe, C.Grande, S.Iovieno, A.Scarcia, H.Sedehi, & G.Raiss, A Quality Model for Web-based Environments: GUFPI-ISMA viewpoint, IWSM2003, in "Investigations in Software Measurement", Proceedings of the 13th International Workshop on Software Measurement (IWSM2003), September 23-25, 2003, Montréal (Canada), Shaker Verlag, ISBN 3-8322-1880-7, pp. 70-81 Click to read the abstract
L.Mancini, L.Buglione & R.Meli, L'associazione GUFPI-ISMA, i Function Point, e le metriche funzionali, Convegni di studio CNIPA 2003-2004 - “Metriche per lo sviluppo software: stato dell'arte”, 21/11/2003, Banca d'Italia, Roma, collana "I Quaderni", Anno I, N.1, Marzo 2004 click to download the paper Click to read the abstract
Buglione L., Dimensionare il software: qual è il giusto "metro"?, White Paper, Bloom.it - Frammenti di Organizzazione Ottobre 2003
L.Buglione, M. Lelli, E.Giacobbe, F.Gasparro, S.Iovieno, H.Sedehi, C.Grande & A.Scarcia, A Quality Model for Web-based Environments: First Results , SMEF 2004, Software Measurement European Forum, January 28-30 2004, Rome (Italy), ISBN 88-86674-33-3, pp.160-168 click to download the paper Click to read the abstract
A.Khelifi, A.Abran & L.Buglione, A System of References for Software Measurement with ISO 19761 (COSMIC-FFP), in "Software Measurement - Research and Application", Proceedings of the IWSM 2004 / MetriKon 2004 Software Metrik Kongress, 14th International Workshop on Software Measurement and Metrik Kongress, November 2-5, 2004, Konigs Wusterhausen (Germany), Shaker Verlag, ISBN 3-8322-3383-0, pp. 89-108 click to download the paper Click to read the abstract
M.Abu Talib, O.Ormandjieva, A.Abran & L.Buglione, Scenario-Based Black Box Testing in COSMIC-FFP , Proceedings of SMEF 2005, Software Measurement European Forum, 16-18 March 2005, Rome (Italy), pp. 173-182 click to download the paper Click to read the abstract
Buglione L., PSU e Metriche Funzionali per il Dimensionamento del Software: concorrenti o alleati?, White Paper, Bloom.it - Frammenti di Organizzazione 14 Marzo 2005
C.Gencel, L.Buglione, O.Demirors & P.Efe, A Case Study on the Evaluation of COSMIC-FFP and Use Case Points, Proceedings of SMEF 2006, 3rd Software Measurement European Forum, 10-12 May 2006, Rome (Italy), pp.121-140 click to download the paper Click to read the abstract
Buglione L., Dimensionare i progetti: che “metro” usare?, XPM.it, Giugno 2006
Buglione L., FORESEEing for Better Project Sizing and Effort Estimation, Proceedings of MENSURA 2006, Cadiz (Spain), November 6-8, 2006, ISBN 978-84-9828-101-9, pp. 119-130 click to download the paper Click to read the abstract
Buglione L., Meglio Agili o Veloci? Alcune riflessioni sulle stime nei progetti XP, XPM.it, Febbraio 2007
Buglione L., Project Size Unit (PSU) - Measurement Manual, v1.21, November 2007, Available versions: English, Espanol/Spanish and Italiano
Gencel C. & Buglione L., Do Different Functionality Types Affect the Relationship between Software Functional Size and Effort?, Proceedings of IWSM/MENSURA 2007, Palma de Mallorca (Spain), November 5-8 2007, pp. 235-246 click to download the paper Click to read the abstract
Buglione L., Some thoughts on Productivity in ICT projects, version 1.1, WP-2008-01, White Paper, March 2008
Buglione L. & Gencel C., Impact of Base Functional Component Types on Software Functional Size based Effort Estimation, Proceedings of PROFES 2008 Conference, Frascati, Rome (Italy), 23-25 June 2008, LNCS 5089, A.Jedlitschka & O.Salo (Eds.), pp.75-89 click to download the paper Click to read the abstract
Buglione L., Some thoughts on Productivity in ICT projects, version 1.2, WP-2008-02, White Paper, July 2008
Cuadrado-Gallego J.J., Buglione L., Rejas-Muslera R., Machado-Piriz F., IFPUG-COSMIC Statistical Conversion, 34th Euromicro/SEAA 2008, Workshop on Software Management, Parma (Italy), 3-5 September 2008 Click to read the abstract

Cross References to this page

Notes from the Field: Zarate-Terrani webpage (17/01/2002)
Notes on Software Engineering: Fred Swartz webpage
MIS Course at the University of Arizona (Tucson)
Jean-Claude Vauthier - Links
Silvia Mara Abrahão - Links

[Bio Sketch] [Misurare il Software] [Publications] Home Page [QEST & LIME models] [Presentations] [Links]
Last update: July 25, 2008
Previous update: July 7, 2008
Created on: December 5, 2000

1