When someone says ‘Function Point Analysis’ what passes through your mind? A crude method that was all the rage ten years ago for helping measure productivity of software development? Or one of the most powerful tools in the systems analysts’ and project managers’ arsenal for controlling requirements, estimating and project performance?
Traditional FPA is rather crude and limited in its applicability. With the emphasis now on object and web-based development, FPA has fallen off the radar screen in many organisations. However, with recent advances in functional size measurement, increasing need to quantify/control requirements and produce better estimates for component-based development, FPA (modernised) is undergoing a renaissance.
The key starting point is to produce quantifiable requirements or functional specifications. If we have to make requirements unambiguous, traceable and testable, why not make them measurable at the same time? Indeed, if you can’t measure them how can they be unambiguous or testable?
(For an example of how Use Cases can be written to make them measurable see Grant Rule’s paper 'Using Measures to Understand Requirements', presented at ESCOM 2001. Available on our website or via the Reader Enquiry Form.)
Measurable requirements provide the basis for:
Analysts who produce Business Cases to estimate, cost and, perhaps, evaluate and select suppliers
Development Project Managers to produce estimates and control ‘scope creep’
Maintenance and Support Managers to control and improve M&S performance
Process Improvement activities – measuring performance and planning improvement
Contract Managers to control supplier performance
Software Asset Management to value software at replacement cost so that it can be included in the Balance Sheet.
Perhaps you should update your views on the power of these measurement methods?
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.
Improve
M&S Productivity
Helpful analysis and key action priorities for improving software Maintenance and Support(M&S) productivity
Performance Assessment
To compare project performance, identify improvement opportunities and make good estimates for future projects, you need to assess the performance of existing projects.
The Importance of the Size of Software Requirements
Size measurement methods have played a key role in helping to solve real-world problems of estimating, supplier/customer disputes, performance improvement and the management of outsourced contracts. This paper discusses the history of functional size measurement and the status of the COSMIC-FFP method.
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.
Measuring Requirements and Changes
Measuring the functional size of change requests and estimating their impact in terms of cost, duration, effort etc.
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.
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.
When someone says ‘Function Point Analysis’ what passes through your mind? A crude method that was all the rage ten years ago for helping measure productivity of software development? Or one of the most powerful tools in the systems analysts’ and project managers’ arsenal for controlling requirements, estimating and project performance?
