There are several approaches and sets of rules for counting Function Points (e.g. IFPUG, COSMIC, Mk II, etc.).  They are all designed to use that most powerful of processors, the human brain.  Designing a computer program to automate function point counting has proved impossible to date (and maybe forever) for two main reasons: the current rules assume the pattern recognition and variable input capabilities of the human brain.  Put more simply, the rules assume that the counter can receive information (in a wide variety of formats including subject matter interviews) and pick out relevant architectural information.

However,  software has evolved for other uses -mainly static code analysis - which uses algorithms to understand the structure of code to evaluate its quality from a code design and implementation perspective.  Clearly, such code analyzers can do a good job of measuring software size in the form of lines of code but as we all know that is not particularly useful.

Some vendors are now modifying these algorithms to develop software size metrics based on the underlying architecture and using the sort of rules that an IFPUG function point counter would use.  It is not realistic to expect these tools to exactly replicate IFPUG function point counts in all circumstances because the IFPUG rules (embodied in the IFPUG Counting Practices Manual) are simply not written in a way that allows a program to encapsulate them all (and the input format variability problem remains).  However, these tools are now exhibiting significant signs of being a disruptive technology in the Christensen sense in that while they may not be great at doing everything that a human function point counter can do, they may be better (cheaper) at doing some things e.g. a monthly or quarterly recount of an application portfolio.

Here at DCG, I am committing us to work with vendors of these new tools to see if we can develop them together to improve the overall software sizing services that we can deliver to users. For a longer explanation of where we are, please see the presentation that I made to the 2009 UKSMA Conference in London.

One of the ideas that I float in the presentation is the possibility of creating a different, new software size metric that can be automated - a sort of Automated Function Point.  A good client of ours, Thierry Fraudet, thought about this and wondered how it might work for COTS or SaaS software?  True to form, Thierry answered his own question by suggesting that users could require vendors of COTS or Saas to provide function point counts with their software.  What a great idea?  And why limit it to automated function points?  Why not start asking COTS and SaaS vendors for IFPUG function point counts now?  As Thierry says, “What an interesting way to compare license fees!”

If you are interested in automated function points, I would love to hear from you.

The May/June 2009 issue of IEEE Software contains a paper by Onur Demirors and Cigdem Gencel describing some excellent work they have done to build a universal model for functional sizing that incorporates models of the three main approaches: IFPUG, Mk II and Cosmic.  That this is possible should not be surprising because they are all derivatives of the original work by Albrecht et al.  What is refreshing is that someone has risen above the battles over the relative merits and provided a useful comparison of the techniques.  The conceptual map diagram in the article is particularly useful as a tool to explain functional sizing to new counters or managers.

The model doesn’t handle all the detailed rules of each approach but the authors have included a couple of case studies to illustrate their success with the model.  Obviously, two data points do not make a conclusive proof and I am not advocating that we should use the universal in place of the three more established approaches but this article is both interesting and useful.  I recommend it and would welcome feedback after you have read it.

Conceptual Association of Functional Size Measurement Methods

My colleague, Tom Cagley, has an excellent continuing series of interviews (podcasts) in our field of software measurement and software process improvement.  I commend the whole series to you but I want to particularly draw your attention to Tom’s interview with Joe Schofield which is an excellent conversation on the choice between function points and lines of code as an organizational software size metric.

Tom Cagley’s interview with Joe Schofield

I had another conversation last week with a potential client interesting in implementing measurements in their software development group.  This conversation is so common that I thought it might be worth capturing here.  Their current state is capturing staff time (effort) information on projects and tasks and capturing budget (cost) information through their normal budget management process.  Their pain is that their annual budgeting cycle has been and gone again without any sensible discussion between IT and the business about the futility of the business(es) expecting everything on its wish list to get done without any regard to the capacity of the software development group.  Why is this a repeated annual frustration?  Because the software development group don’t know their own capacity.  Why don’t the software development group know their own capacity?  Because they don’t have any information about the quantity (size) of software that they have produced in previous years for a given head count or effort hours or, logically, the quantity of software they will be able to produce next year for the same budget (or a different budget).

I always recommend some sort of implementation of function points in this scenario but I am always quick to add, “or any other method of software sizing to get you started.”  I try to explain at this point that ther is no such thing as “accurate” software sizing because there is no arbitrary scale against which comparison can be made as they can for, say, metres.  Hence, the trick to an acceptable software sizing approach is not “accuracy” but “consistency.”

What makes function points stand out is the tremendous body of research and usage that allows organizations like IFPUG to claim with some certainty that any set of Certified Function Point Specialists (CFPS) will produce the same result +/- 10% for function point analysis carried out on the same documentation of a project or application.

Counting lines of code (LOC) is simple and a place of last resort if all other options are ruled out.  Among the well-documented challenges with lines of code are the difficulty in getting consistent usage of code by programmers even within one company and the difficulty of making realistic comparisons (and hence summations) across different programming languages.

If function points are really not feasible, an option better than LOC’s is a specific internal framework based upon the structure of typical in-house problems.  For example, browser-based projects might use counts of parameters such as pages, user inputs, etc.  This approach can be quite effective if it is calibrated over time against actual in-house experience.  It’s limitations are that comparison and summation across different types of projects is inconsistent and comparison to external benchmark data is impossible.