Aspects of Function Point Analysis

Search:   

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

Related Info...
Articles
Services
Training

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

by: Paul Goodman

Analysis

There is a very important word in the term Function Point Analysis, namely ‘Analysis’.

We tend to think of FPA as providing a size measure, which enables meaningful comparison of productivity across projects, systems and enterprises. We also concentrate on the use of FPA in cost estimation. However, the most important factor is that FPA views systems from the users’ perspective.

figure 1

Users put information into an application, they get information out and they recognise discrete groups of data, entities or files, that the system will use and maintain. If we keep decomposing our system, we reach the lowest level of user recognisable functionality.

The International Function Point User Group (IFPUG) Counting Practices Manual (CPM) calls these “elementary processes”, the MkII Function Point CPM calls them “Logical Transactions”. The figure, below, shows this for part of a warehouse system.

figure 2

In order to apply FPA you define not the layout of reports but the information contained in the output. That is all you need for FPA. One of the problems analysts have is that so called requirements specifications often express how the system will do things rather than what it will do. Also, the specifications are invariably incomplete!

Well defined specifications that can be sized can become the basis for contracts. Project constraints and service level agreements can easily be added later.

Completeness

The relative proportions of the various function point components can inform us about the probable “completeness” of the specification. For MkII FPA, this involves comparing the ratio of input DET’s, entity references and output DETs. For IFPUG FPA we must compare the ratio of external inputs, outputs and queries and internal logical files and external interface files.

Component Ratios

figure 3

Omissions and Duplication

FPA can be used to size any business function whether or not that function is supported by a computer system.
This has been done in one Australian organisation and what did they find? Whole areas of business functionality that were unsupported. Massive duplication of supported functionality, implying significant maintenance costs that were unnecessary. A potential saving of millions!

Progress Tracking

Many of us have been asked to report progress in terms of “percent complete”. This is sometimes expressed in terms of components built vs. components to be built; actual lines of code delivered vs. estimated lines of code to be delivered; actual effort consumed vs. estimated effort still to be consumed (which seldom decreases!) or various combinations of these. These measures have serious defects. They tend to be meaningless until quite late in a project’s life and they are often based on estimated values.

figure 4

Yet in FPA, we have expressions such as “50% of our Logical Transactions have now been signed off”, or even “25% of the total Function Point Index has now been signed off.”

Related Information

back to top

Articles

Introduction to Function Point Analysis
Defining the size of software has been described as like "trying to nail jelly to a wall" ...

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.

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.

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 1999-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