Introduction to Function Point Analysis

by: SMS

We often find senior managers have only a vague understanding of software size measurement and Function Point Analysis. This article continues our efforts to introduce some of these basic concepts.

Defining the ‘size’ of software has been described as like ‘trying to nail jelly to a wall’. Why should we want to? The two commonest reasons are interrelated.

• If we want to understand the productivity of a software development project, we need a measure of work-output from the project, such as the size of the software delivered. Productivity is then defined as ‘software size / development effort’
• If we want to estimate the effort to develop a new piece of software, it is clearly helpful if we can get some idea of its size early in the development life-cycle when we start to gather the user requirements. Then with measures of productivity from past developments, we can make a first estimate of the development effort which will be needed.

The problem is there are endless ways in which one can define the size of a piece of software. One way is to count the lines of code of the software program. But there are serious problems with this measure. First there are no accepted standards for line-counting, so different approaches can give sizes varying by a factor of at least ten. Second, software is produced in an ever-growing variety of programming languages, and the equivalencies between these languages are only known approximately. (For example it is generally reckoned that you need three lines of the Assembler programming language to express the same amount of logic as one line of COBOL.) Third, you do not really know the number of lines of code until the program is delivered. So using lines-of-code as a size measure for early life-cycle estimating is very difficult.

In the late 70’s Allan Albrecht of IBM had a brilliant lateral thought. He proposed to construct an artificial size index for software based on the logical requirements, independently of how they are implemented, that is independently of the programming language and technology used. Albrecht’s original idea has been refined and his method is now standardised and maintained by the International Function Point User Group (‘IFPUG’), a US-based organisation. The latest definition of Albrecht’s method is known as ‘IFPUG 4.0’.

Briefly, Albrecht proposed that we can think of any piece of software in terms of its user Inputs, Outputs, Inquiries, Internal Logical Files and External Interface Files. If we can identify and count these components from the requirements, we can weight them in a particular way, and the sum of the weighted counts is known as ‘Unadjusted Function Points’. Albrecht then proposed another factor to account for varying quality and technical requirements, such as ease of maintenance, response time needed, etc., and applying this factor, the result is a size measure in units of Function Points.

Albrecht described this size index as a ‘Dow Jones’ measure of software size. The general industry consensus is that, particularly for business or ‘MIS’ applications, IFPUG FP’s are a useful size measure for performance measurement and early life-cycle estimating, and certainly far better than trying to use program lines-of-code.

About ten years ago, Charles Symons, now a Director of GIFPA and SMS, found that the Albrecht size scale did not seem to properly reflect the internal processing complexity of certain business software he was studying. He proposed a variant of Albrecht’s method, which he called ‘MkII’ FP Analysis. In this approach, a piece of software is viewed as a collection of ‘Logical Transactions’, each comprising an input, processing and output component.

MkII FPA also involves identifying, counting and weighting the components of the software to produce a size in ‘MkII FP’s’, in this case according to rules now maintained by the UK Software Metrics Association. The factor to deal with quality and technical requirements has recently been dropped from the MkII method, as it has been shown to be inaccurate for the ways we develop software nowadays.

Early experiments to compare software sizes measured on both the IFPUG and MkII scales resulted in a recommendation to use the MkII method in UK Central Government. It has also been adopted by a majority of the UK’s major financial institutions, and in other industries such as telecomms and utilities. But the IFPUG method was already well established by the time the MkII method was proposed, and with IBM’s marketing weight behind it, it has become the dominant method in use today.

There are now said to be over 30 variants of FPA, but the MkII method is probably the second most commonly used. Interest is growing in this method because it can be applied more easily to modern development methods such as Object-Oriented methods, and its underlying model is fundamental for all types of software.

Function Point Analysis, whatever variant is used, is a manual process which requires skilled and experienced practitioners to get reliable size measures. But FPA remains by far the most practical and commonly used method of software sizing, especially in the world of business information systems.

Performance measures based on IFPUG or MkII FP’s are routinely used to help control major outsourcing contracts, and many IS departments use early life-cycle estimating methods based on FPA. Software sizing with FPA is common to all the major commercial performance benchmarking services. Some organisations even size their application portfolio using FPA so that they can determine its replacement value and include software as an asset on the balance sheet.

So the uses and benefits of software size measurement with function points are becoming ever more widely recognised.