Pros and Cons of Backfiring function points

For estimating the size of IT systems, Backfiring is a faster, cheaper but less accurate method than traditional function point analysis. Backfiring is a useful method for estimating existing systems but less suitable for new software development.

Function Point Analysis

Functions Point Analysis (wikipedia) is a method for estimating the size of an IT systems. The method was developed at IBM in the 1970s by Allan Albrecht, when IBM had a huge software development organisation. IBM was experimenting to improve its software development productivity and quality, but had no way of accurately measuring whether it was improving. The traditional methods based on lines of code were not working, since a line of code in one language is completely different from a line in another language. Function Point Analysis only looks to the functionality that a system provides and is therefore language independent. The method has been standardized over the years and has become the only practical way to measure the size of applications across teams. (Agile projects have a very practical method called story points, but this method is team dependent). Functions points are now used for measuring and benchmarking organisations, for managing application portfolios and also in software maintenance and outsourcing contracts.

Problems of Function Points

When Function Points are used for important investment decisions and for contract negotiations, certain drawbacks have come to light. First of all, function point estimation is not cheap. To get an accurate estimate, a certified expert has to look at the functional specification and data model and spend several days per system. The cost of analysing a large group of systems is significant. Secondly, one needs to have accurate functional specifications in order to make an estimate. For traditional waterfall organisations this was no problem, but for many agile organisation or organisations with many systems in continuous maintenance or legacy systems, this is a problem. Without a specification, it is not possible to do a normal function point count and one would end up with either a lot of extra documentation work or only a subjective estimate.

The backfiring method for function points

Like function points itself, the backfiring method was alse first used within IBM. IBM initially used both line of code metrics and function point metrics in parallel. They noticed that within each language, there is a strong correlation between lines of code and function point. This correlation was investigated further by software productivitiy research, who has measured the average number of lines of code per function point for each language. Using their data, one can reliably estimate the number of function points based on the source code only. The company SPR from software quality expert Capers Jones popularised the use by publishing accurate tables with language level data. Companies like SIG and CAST are using this data as standard benchmarks. The method has been used at many companies in The Netherlands (Belastingdienst, ProRail, Rijkswaterstaat, ING, Rabobank, Essent to name just a few). Backfiring gives objective insights into the size of systems and application portfolios. The method is especially useful for estimating rebuild value and maintenance effort for existing applications. In these situations one does not want to invest in rewriting functional specifications, but one does need an objective measurement, for instance for contracts and proposals.

Pros and Cons of backfiring

Backfiring is especially suited for estimating maintenance effort. In this case the method can even be more accurate than a traditional function point analysis: if a system is developed in a way that it has more code than one would expect based on the functional specification, the maintenance effort is probably also higher.

Backfiring is not a good method for systems not yet developed or halfway in development. For these systems it makes sense to investigate the required functions and data model needed further. This information is needed anyway, for instance for a privacy impact analysis. Bypassing this valuable step by doing a backfiring analysis does not help the project in this case.

An important remark to make is that backfiring function points is accurate at the portfolio level. The method is based on averages, and averages are comparable when working with multiple systems. For individual systems, the estimate is less accurate. Function Points are therefore not the best way to measure team productivity or improvement. The agile method of using story points and measuring velocity per sprint gives a much more accurate image.

More information

With ICT Institute we do code reviews, IT due diligence and other advisory projects where we look at the source code of systems. As part of these projects we typically do a backfiring function point analysis and can provide estimates of rebuild value and expected maintenance effort. If you would like to measure yourself, recommended resources are SPR for the industry standard benchmarks, data from ISBSG for estimating, function point standard initiatives such as IFPUG,  Cosmic and Nesma. An important source of various benchmarks are also the books from Capers Jones, especially applied software measurement.This books gives a background of all available function point variants, an in-depth explanation why function points are preferred over lines of code, and data across industries, types of systems and project sizes.

Image Allan Albrecht: from IFPUG; Abacus: Will Jackson CC