Piggy Bank in G Clamp

Introduction

The benchmarking of software delivery processes is a standard activity for good governance of ICT. For this, an organisation may make use of external benchmarking specialists, benchmark  in-house or take a hybrid approach. However it is done, there is usually a significant cost associated with the benchmarking.

A key contributor to the cost is the activity of measuring the output produced by the software delivery processes – the size of the software. The dominant method used for sizing is Functional Sizing and, more specifically, International Function Point Users Group (IFPUG) Function Point Analysis. The IFPUG method has been in use for several decades and associated benchmarking databases, both public and private, are well established.

The method, however, is difficult to learn and apply, as evidenced by the 600 pages of its Counting Practices Manual. The complexity of the rules often leads to different interpretations and confusion and means that specialized skills are needed for successful application. All of these issues contribute to the cost of sizing.

Recently, two new but very different initiatives have sought to address some of these difficulties. In this issue of the newsletter, we will look at Automated Function Points and in the next issue look at  research undertaken which seeks to simplify the technique, as Simple Function Points.

Automated Function Points

The idea of automating Function Point Analysis is not new. In the past 20 years or so, there have been a number of attempts at automation encapsulated into software tools  – with largely  disappointing results. Roger Heller from QPMG has summarised this experience in his paper, Automated Function Point Counting – A Fact Based Analysis. Login at http://www.qpmg.com/Library/library_login.php to obtain the paper.

The majority of these past attempts were based on analysing source code and, perhaps, suffered from a simplistic or wrong view of the Function Point Counting rules.

The functional size of a software product is established through analysis of software requirements and expresses the logical solution.  When an analyst needs to size from physical artefacts – screens. reports, lines of codes, lists of files and so on, the analyst must work back to this logical view.  A specification for automating sizing from source code must somehow capture this process. It isn’t straight forward.

In recognition of this, an initiative was established by CISQ / OMG to put together a publicly available open  specification for “ automating the counting of Function Points that is generally consistent with the Function Point Counting Practices Manual, Release 4.3.1 (IFPUG CPM)”.  The specification is available for download from http://www.omg.org/spec/AFP.

Note that this specification, at this point in time, does not address the sizing of enhancements to an application – and it is ongoing enhancement work that forms a large part of benchmarking focus.

Sizing from source code requires, not surprisingly, access to source code.  This immediately limits the range of applications which can be sized using this method.   For a number of reasons, the source code may not be available. For example, many modern applications built using integrated development environments and / or Cloud (SaaS and PaaS) strategies, will not give access to the source code.

However, many organisations continue to maintain old, often undocumented ‘legacy’ systems and perhaps there is a useful application here.

Is this specification sound enough to achieve its objective of underpinning the automation of Function Point Counts? How can we test it?

CAST claims to have enacted this specification in its Application Intelligence Platform (AIP).  There may be other software tools using this but I am not aware of them at this time.

Looking at the CAST results may allow us to pass some level of judgement on the specification.

CAST’s AIP is a source code analyser. It produces a number of metrics, including Function Point Counts.  Additionally, (i.e. outside the specification), it claims to be able to size the output from enhancement projects.

How good are the CAST counts? How close are they to ‘normal’ IFPUG counts, as would be produced  by skilled counters? Are they close enough for some business purposes – or not?

A  PowerPoint presentation CAST Computed Function Points is available at http://www.slideshare.net/castsoftware/computed-function-points-cast.  It provides some insight – and the results are inconclusive.

Function Point Analysts who quality assure Function Point Counts have tests for “first pass” validation of counts . For example, a Function Point Count for an application should show a balance between Transactions  (activity) and Data.  Analyses of ISBSG data show a relative contribution of Data functions to a Function Point Count of less than 30%. My organisation’s experience is similar and note further that this contribution  drops as an Application ages,  to around 12-15%. To restate this in another way, the data footprint for an application stays more or less the same throughout its lifetime but, with time, more functions are provided to process that data in different ways.

The CAST presentation  shows the automated counts  for 17 Applications, ranging in size from very small to medium size applications.  The contribution of the Data ranges from 30% to 91%, average 62%. This marked skew towards files is highly unusual in an IFPUG Function Point count and needs further investigation.  Are there too many files or not enough transactions?

IFPUG have suggested to CAST that there should be validation of the computed counts  through open comparison with manual counts of the same applications. Unfortunately,  this conversation appears to have stalled.

Until such times as the CAST counts can be validated, it is recommended that the specification and the software tools making use of it should be viewed with caution.

Does the solution reduce the cost of counting?

Intuitively, the concept of automated Function Point Counting would indicate reduced cost of counting for those applications where it can be applied.

However, currently for CAST’s AIP, this does not appear to be the case. The upfront cost of CAST’s AIP  is not published but, anecdotally, it is very large, covering software purchase, configuration and calibration. The equivalent amount would keep most large organisations in Function Point Analysts for many years.

Once established, though, the ongoing cost of counting can be expected to be minimal, not withstanding further calibration.

However, there is an opportunity here for other software tool vendors to provide a cheaper solution.

In the next issue, I will discuss an alternative initiative which shows a lot of promise for use in the quest to reduce costs – Simple Function Points.

Tags: ,

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.