Original Post Date: Thursday, February 21, 2013

I recently attended a webinar presented by David Herron of the David Consulting Group (DCG) discussing a recently released specification for the automation of function point counting (available on the Consortium for IT Software Quality (CISQ) site .  Function point counting is a process through which software ‘size’ is measured by the amount of business value that the software delivers to the end user. 

Function Point counts are thought by many to be a far superior means of measuring software ‘size’ because they are technology neutral and not impacted by factors such as programmer style.  A major impediment to wholesale adoption of Function Point counting has been the fact that the process is manual, tedious and takes a lot of time. Source Lines of Code (an alternative means of software measurement) has many critics and yet many still tend to use them as their primary means of measurement because software can be developed to count them consistently on finished software applications.  To achieve consistent Function Point counts one must study the counting practices or standards for function point counting (there are actually 5 standards for different types of Function Point Counts – but we’ll cover that some other day!).  The International Function Point Users Group (IFPUG), focused on the IFPUG Function Point Counting method (the most widely used method of the 5 methods available), has developed and maintains a counting practices manual. To become a Certified Function Points Specialist one must pass an exam that IFPUG administers. 

In a previous life I thought that being a Certified Function Point Specialist would be a useful skill for a software estimation professional like me.  I studied, took the exam and was pleased to learn that I had passed and could now add CFPS to my business card.   Shortly afterward an opportunity presented itself for me to put my function point counting expertise to use on a relatively small software application (just a couple of days of counting).  Those were of course several of the longest days of my life.(Begging the question – certified or certifiable?) Quite frankly, Function Point counting is tedious and boring (or maybe I just landed a particularly boring application); any thoughtful effort to automate it gets the thumbs up from me.  Needless to say I decided to forego the business card update and stayed under the function point counting radar until my certification expired.

I believe automation will be a good thing and that it will benefit our industry.  If we are able to agree that the rules of automation are good enough to represent adequately most of the software that we develop, while also maintaining sight of the situations where manual intervention is required, we have a decent chance of being able to conquer some of the issues that have plagued our industry for years.  From an estimation perspective this would certainly facilitate the drive for delivering estimates that are data driven.

   
I have not taken a detailed dive into the specification recently released but it’s on my to do list as I am very interested in what artifacts in software code will be the things looked at to determine number of Function Points.  Clearly the developers of this standard had to make some adaptations to the actual rules to automate a pretty human reliant process.   There’s lots of passion in our industry for Function Point counts because of the promise they delivered, it will be interesting to learn where the industry experts fall on the feasibility and practicality of automating function point counting as they become familiar with the recommendations currently on the table.  What are your thoughts on the subject?