Functional Size Measurement methods

This is the second part of the blog focusing on a number of popular software size measurement methods and their usefulness for software project estimation. In this second part the functional size measurement methods IFPUG, NESMA and COSMIC are covered. In future blogs I will cover non-functional size measurement methods and hybrid methods.

Readers interested in this topic are very much recommended to first read the first part of this blog, before reading this second part.

For a particular software size measurement method to be useful for software project estimation, the following characteristics should apply:

• The size measurement method can be carried out in an objective (independent of the person doing it), repeatable, verifiable and therefore defensible way;
• Size in itself is only useful when historical data is available of projects measured in that size measurement method;
• The size measurement methods should be supported by parametric models and/or tools in order to accurately factor in project specific characteristics that influence the estimate, like for instance COCOMO II, SLIM, SEER for Software or Trueplanning.

Of course, any software size measurement method that does not comply to one or more of these criteria may still be very useful for an organization, provided they draw up a procedure to ensure repeatable size measurements, collect and analyze historical data and/or build their own estimation models based on the data collected. For this blog however, the focus is on the theoretical usefulness of the specific measurement method for software project estimation purposes in the context of organizations that don’t have a parametric estimation process in place yet. For these organizations, that are willing to implement a size measurement method in order to estimate software projects, this blog can serve as a guideline to select a specific method.

I encourage everybody to submit comments and/or feedback on this blog.

Nesma FPA

Nesma FPA is very similar to IFPUG as it measures the same base functional components (BFC’s [24]) (ILF, EIF, EI, EO, EQ) and there are very few differences now between the counting guidelines of the two methods. Many experts use the size measured in IFPUG function points as equal to the size in Nesma FP. The main advantages of Nesma over IFPUG for estimation purposes is the availability of a number of derived methods that are considered to be part of the ISO/IEC standard:

• Indicative FPA – This method can be used very early in the project lifecycle when only the data model is specified. The accuracy is not very high (-30% / +50%), but usually enough to be useful in an early stage of the project lifecycle when only a ROM estimate is needed.
• High level FPA (a.k.a. estimated FPA) – This method is considered to be the main method nowadays, since most functional documentation lack the detail to be able to use the standard Nesma (or IFPUG) FPA. The high level FPA uses a fixed complexity assessment per base functional component: low complexity for logical files and average complexity for functions. This method can be used when the data model and the functions are known, but the details of which attributes are used in which functions are lacking or incomplete (which is often the case). The accuracy of this method is around -8% till +15% (see this paper).

In addition, Nesma distinguishes between project size (the number of function points added to an existing system, plus the number of function points changed in the system, plus the number of function points deleted, plus function points of software needed to realize to complete the project, for instance conversion software) and product size (the functional size of the application that is delivered to the users).

Nesma is a very active community of volunteers that are constantly working on new ways to use the method on new types or special types of software projects. Although these are not officially part of the ISO/IEC standard, these methods can be very useful for software estimation purposes. Widely used guidelines are for instance:

• FPA for software enhancement
  the use of this method is actually mandatory in some countries for contractors to be able to bid on government projects.
• FPA in SOA environments (only in Dutch)
• FPA in data warehouse projects
• FPA in the early phases of the project lifecycle
• FPA applied to Usecase / UML documentation

The Basis of Estimate (BoE) for software services as published by Nesma and the AACE International, the authority for total cost management,  is a very useful way to baseline any software project estimate, while also proving that the estimator has taken into account all the aspects that are important in his estimate. The Nesma (IFPUG) method is supported by most of the commercial and non-commercial parametric software estimation models and tools.

The characteristics to assess the usefulness of this method for software project estimation are listed in the next table:

Characteristic	Y/N	Remarks
Objective, repeatable, verifiable and defensible	Yes	ISO/IEC 24570:2004
Historical data available	Yes	ISBSG R13: 187 projects (5433 when combined with IFPUG)
Supported by models/tools	Yes	QSM, SEER-SEM, Trueplanning, COCOMO II, ISBSG

 

IFPUG

The IFPUG method is the most-widely used method for functional size measurement. Of all the requirements, It measures only the functional user requirements and it does so in the way that internal logical files (ILF), external interface files (EIF), external input functions (EI), external output functions (EO) and external inquiry (EQ) functions are identified and classified in complexity. The complexity of the software is classified in the following way: Low, Medium or High, depending on items like the number of data attributes involved, the number of files referenced or the number of record types that are part of the logical file. For an internal logical file (ILF) for instance, the number of function points connected to a low complexity ILF is 7 function points (FP), an ILF of medium complexity gets 10 FP and an ILF of high complexity gets 15 FP. There is minimum number of points per function and a maximum number of points per function. Although this simplifies the analysis process somewhat, it is perceived as a drawback that there may not be enough nuance between the size of different logical files and functions. For instance, the size of a complex External Input function is 6 FP, but he size of a very complex EI is 6 points as well and the size of an extremely complex EI is also 6 FP.

The IFPUG method is most useful as a sizing method to estimate projects that comply with the following characteristics (not limited):

• The software is data oriented, many CRUD (Create, Read, Update, Delete) functions are specified
• The software is administrative oriented
• A detailed functional design is available in which the data model is complete and clear and for all the functions it is clear which data attributes are used

When the size of the functional requirements is measured, there are numerous ways to convert it into an estimate. Using historical data of the organization that is going to realize the software is usually the best way to go, preferably supported by professional estimation tools. If historical data is not available, the open database of the International Software Benchmarking Standards Group can prove very helpful. It contains over 6700 projects (Release 13) and many of these were measured in IFPUG. The IFPUG method is supported by most of the commercial and non-commercial parametric software estimation models and tools.

The characteristics to assess the usefulness of this method for software project estimation are listed in the next table:

Characteristic	Y/N	Remarks
Objective, repeatable, verifiable and defensible	Yes	ISO/IEC 20926:2009
Historical data available	Yes	ISBSG R13: 5244 projects
Supported by models/tools	Yes	QSM, SEER-SEM, Trueplanning, COCOMO II, ISBSG

 

COSMIC

The Common Software Measurement International Consortium (COSMIC) is a voluntary, world-wide grouping of software metrics experts.  Started in 1998, COSMIC has developed a method of measuring the functional size of software that was designed to overcome some of the perceived flaws of Nesma and IFPUG FPA. While Nesma and IFPUG are mainly used to measure the size of administrative software, COSMIC is also applicable to measure the size of real-time and infrastructure software. The method is entirely ‘open’; all method documentation is available in the public domain for free download.

One of the main advantages of the COSMIC method is the fact that it allows the measurement specialist to divide the software into software layers and peer components, which enables the possibility to measure the functional size of the software residing in separate architecture layers or in different components that communicate with each other. This overcomes one of the perceived drawbacks of the Nesma and IFPUG methods, which don’t allow the software to be divided in such a way.

Another important advantage is the fact that the method follows a ratio scale. Therefore the functional size per functional process can be any size between 2 COSMIC function points (the minimum value per functional process) and (theoretically) infinity.

Usually the COSMIC method is very well applicable to use in projects developed with an agile methodology. The type of documentation that these type of projects often deliver (e.g. user stories, usecases, activity diagrams, sequence diagrams, class diagrams) are usually easy to measure with COSMIC in a very accurate way.

Although the use of COSMIC is increasing and also the number of certified practitioners are increasing, still not a lot of open benchmarking data is available. The ISBSG New Developments and Enhancements repository release 13 (released February 2014) contains about 500 projects measured in COSMIC, while the number of projects measured in IFPUG function points is well above 5000 projects.

The COSMIC method is usually particularly well applicable when using the functional size to estimate the following types of projects:

• Real-time software projects;
• Mobile app software projects;
• Infrastructure software projects;
• Software projects that deliver software in a layered architecture;
• Administrative software projects.

The functional documentation should at least show the functional processes that are implemented by the software and the data movements between the users and the software.

The characteristics to assess the usefulness of this method for software project estimation are listed in the next table:

Characteristic	Y/N	Remarks
Objective, repeatable, verifiable and defensible	Yes	ISO/IEC 19761:2003
Historical data available	Yes	ISBSG R13: 488
Supported by models/tools	Yes	QSM, SEER-SEM, Trueplanning, ISBSG

 

There are two more ISO/IEC standards for functional size measurement, FiSMA and Mark II, but as these methods are only used in specific local communities, they are not discussed in this paper.

All methods for functional size measurement are very well suitable for software project estimation. The software size however is only part of the estimate. The size should be converted to an estimate by using relevant historical productivity data. When the functional size in function points is known, it should be multiplied by the most likely number of hours per function point that is likely to be needed in the project. Although there are several professional parametric tools available, and also databases with historical data can be procured easily, many organizations feel that it is complicated and time consuming to use functional size measurement and they find it difficult to determine an accurate productivity rate for the projects they need to estimate. They prefer less time consuming methods or methods that are more easy to apply. Unfortunately, this also means that these methods may not be as accurate.

Next blog

In the next blog on this topic, I will give my opinion on the usefulness of the main non-functional size measurement methods for software project estimation.

 

About the author

Harold van Heeringen is a senior benchmarking consultant at Metri. Apart for his work for Metri, he is involved in Nesma (board member), the International Software Benchmarking Standards Group (ISBSG, current president) and the Common Software Metrics International Consortium (COSMIC, International Advisory Council, representing the Netherlands).

A blog post represents the personal opinion of the author
and may not necessarily coincide with official Nesma policies.