by Arlene Minkiewicz
| September 26, 2014
Whether you’re doing a software cost estimate to support a Bid and Proposal effort, a software valuation, should cost analysis, or to develop a detailed project plan, it is vitally important to understand the ‘size’ of the software you are estimating. The problem with software size is that it tends to fall into the intangible realm of reality. If you tell me you are building a widget that weighs 13 pounds, I can really start to get my head around the task at hand. If I’m chatting about this with my European colleagues, I can apply a universally accepted conversion to put it into a context they are more familiar with. Software offers no such tangible or easily translatable type of metric for size. If you tell me you’re writing 100,000 lines of code I am still left scratching my head in wonder as to how big the project really is.
Many methods have been postulated over the years to help the software engineering community do a better job of assessing software size based on the functionality it delivers to provide better cost realism (makes sense to me!). The International Function Point User Group (IFPUG) has maintained and updated counting practices for IFPUG Function points for well over 20 years. IFPUG Function Points, likely to be the most popular and widely used functional size measure for software, have gained much popularity in many communities but there are two areas where their detractors have focused. One area is that they are costly and time consuming to use and that automated counting of Function Points is not possible. The second is that they fail to take into account non-functional requirements when they are used as an estimation tool.
IFPUG has recently introduced a potential solution to the non-functional requirement criticism. IFPUG Software Non-functional Assessment Practices (SNAP) has been developed to act as a companion to the IFPUG Function Point count. SNAP counts make allowances for things such as logical or mathematical operations, user interface, multiple platforms, multiple methods, etc. The techniques are recently introduced and the jury is still out on how well they are working for folks. There is, however, one caution I would put forth for those thinking of using SNAP. Keep in mind this capability was introduced to help those who choose to use Function Points as an estimation technique. In other words they assess project productivity by determining an average of the labor hours necessary to deliver a function point, then estimate forward using this average value. If you are using Function Points in the context of a commercially available or home grown software estimation tool – it is important to understand that some of the non-functional requirements may have already been accounted for through other model inputs or modeling techniques derived to work around the IFPUG limitation. Make sure you understand what’s in there (your model and your SNAP count) to minimize the chance of double counting and maximize the chance of a more accurate total cost of ownership model.
For more information on Function Points and SNAP check out these resources: