Introduction to Function Point Analysis

Search:   

Document Info.
First Published
SM&P Issue 2
Reference Category
Tools and Techniques

Related Info...
Articles
Services
Training

Reference
Categories
Articles by Title
External Ref's
Other Web Sites

by: GIFPA

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 GIFPA, 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.

Logical Transactions

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.

Related Information

back to top

Articles

Aspects of Function Point Analysis
There are more benefits from FPA than just deriving size.

Issues with IFPUG Counting Practices Version 4
Function Points is referred to as a measurement. It is important to realise it is a statistical measure. Function point counters are not measuring systems so much as statistically sampling them

A Comparison of the Mark II and IFPUG Variants of Function Point Analysis
Shows the similarities and main differences between the two variants documented in the IFPUG FPA Counting Practices Manual Release 4.0 and the UFPUG Mark II FPA Counting Practices Manual Version 1.0.

Come back Function Point Analysis (modernised) - All is Forgiven!
In this paper, Charles Symons examines the reasons for the decline, and the main advances in thinking on the more general topic of Functional Size Measurement (FSM) which have been made in the last 15 years. Specifically, the COSMIC FFP method is seen as a significant step forward in being the first method designed by an international group of software metrics experts to work for both business application and real-time software.

Using Measures to Understand Requirements
Many approaches fashionable with technically-oriented practitioners clearly fail to satisfy the need for clarity of requirements. Some even trade short-term acceleration for long-term maintenance & support costs. What is missing? What can be done to ensure that new technologies help rather than hinder? This paper suggests some simple process improvements that might have made all the difference in a number of cases.

Using COSMIC for Real-Time and Embedded Systems
Exploring the use of COSMIC-FFP based estimation in a real-time and embedded systems context.

Software Size Measurement
Undergoing a renaissance, Functional Size Measurement is applicable thorughout the development, maintenance and support lifecycles.

Services

Applying Software Metrics

Data Collection
Services for identifying, collecting and checking measurements.

Starting a Measurement Programme
A measurement programme is part of a means to an end (one or more business objectives). To deliver any benefit the objective(s) must be clearly understood first and then the measurement programme must be designed to support them.

Supporting a Measurement Programme
Once successfully started, there are various activities required to keep the measurement programme operating effectively and the results relevant.

Assessing Capability

Functional Sizing Audits
To ensure that the selected functional sizing method is being used to produce reliable consistent results.

Estimating and Risk

Estimating Size
Estimating Size from detailed requirements and detailed designs.

Measuring Requirements and Changes
Measuring the functional size of change requests and estimating their impact in terms of cost, duration, effort etc.

Measuring Performance

Performance Measurement and Analysis
A range of services to help organisations determine what measures, data collection and analysis techniques are appropriate.

Benchmarking
An accepted technique used to calculate and improve organisational performance with respect to appropriate benchmarks.

Sourcing

Contract Management
A set of processes for management of the work subcontracted to those suppliers, to ensure compliance and ameliorate the issues and risks involved.

Planning and Supplier Selection
A reliable process for identfying a suitable supplier or suppliers for given packages of work. This also identifies issues or risks to the work that may be a consequence of using each supplier.

Tools and Techniques

COSMIC FFP
A method designed to measure the functional size of real-time, multi-layered software such as used in telecoms, process control, and operating systems, as well as business application software, all on the same measurement scale.

IFPUG Function Point Analysis
The original method of sizing, it is currently at version 4. This method is still the most widely used and works well in the business/MIS domain. It is applicable to object oriented developments.

Mark II Function Point Analysis
This method assumes a model of software in which all requirements or ‘user functionality’ is expressed in terms of ‘Logical Transactions’, where each LT comprises an input, some processing and an output component.

Training

Applying Software Metrics

Uses and Benefits of Function Point Analysis  
Learn how FPA can help your projects manage the acquisition, development, integration and support of software systems

FPA Follow-Up Workshop  Advanced Workshop 
An advanced workshop to help experienced practitioners resolve the issues that arise when using unfamiliar technologies.

Function Point Counting Workshop   
Apply your skills in a coached workshop – consolidate your skills and experience on the job.

Sizing E-commerce Applications  Advanced Workshop
An advanced workshop for practitioners wishing to apply functional size measurement to internet-based solutions

Tools and Techniques

COSMIC FFP for Sizing & Estimating MIS and Real-Time Software Requirements  Formal Course 
Learn how to measure the software component of software-intensive systems using the latest ISO-standard method

Practical use of IFPUG Function Point Analysis  Formal Course 
Learn the most popular technique for measuring the functional size of software applications and projects

Practical use of MkII Function Point Analysis  Formal Course 
Learn the UK Government’s preferred technique for measuring the functional size of software applications and projects

GIFPA Ltd. 2016
    
  
 e-mail: sales@gifpa.co.uk
  www.gifpa.co.uk

Copyright 1998-2016 GIFPA Ltd. 2016 All rights reserved.

                                               
Applying Software Metrics
Assessing Capability     
Estimating and Risk       
Improving Processes     
Measuring Performance
Sourcing                       
Tools and Techniques   
             
                
Services               
Training                
Events                  
Reference             
                
About GIFPA         
Opportunities
Copyright & Legal