Ask Carol: Sizing Alternatives When Cost Is an Issue

QSM hosts a free advice column for software professionals who seek help to solve project management, communication and general software project issues. Carol Dekkers is a QSM consultant and IT measurement and project management expert who speaks internationally on topics related to software development. Send your questions to Ask Carol!

Hi Carol:

Thanks for this excellent initiative. One of my key clients is planning to move away from FP counting as they think it’s expensive, takes time, does not measure non-functional work and also they do not want to invest in auditing the FP results. Instead, they are considering using LOC. We have tried explaining them all the shortcoming of LOC but no use. In fact we advised them to use SNAP along with FP but looks like they are just focusing on cost!

In your article on 'Size Matters', I noticed you had mentioned few other techniques to measure size like RICE Objects and Implementation Units. Would like to learn more about these and would like to understand if these are industry standards. Can you please share some insights?

— Sizing Enthusiast

Dear Sizing:

Because you are someone who knows the value of functional sizing (aka function points,) it is frustrating when management focuses on the cost of measurement rather than the value delivered.  I’m wondering whether there is a disconnect between the perceived value and the cost of FP counting. There are a couple of potential issues here that I’d like you to consider before we get into the sizing alternatives

• Pursuit of premature precision: When FP are used to estimate the size of a set of high level requirements (i.e., early, incomplete and without details), it is folly to “count” anything other than average complexity on any functions. This dramatically speeds up the FP process — especially since the details to do a “count” are not yet there.
• The “measure with calipers, cut with an axe” syndrome: Why is your client using FP?  If the reason is to do rough order of magnitude budgeting or to gauge the relative size of various projects, then doing extensive (and detailed) FP counts may not be prudent.  Some companies get lost in the minutiae of documenting every aspect of a count (i.e. lots of effort attributed to FP) that is simply not justified.
• Adhoc metrics program design: It would be folly to go grocery shopping for the week without some sort of list or meal-planning, yet in software metrics this is often what we do — we start collecting data (sizing, defects, effort, and cost) haphazardly and with the intention of using it all... someday.  As a result, we end up with a cache of data for which we may not have any real use.  The Software Engineering Institute (SEI) adapted Victor Basili’s Goal-Question-Metric (GQM) approach to measurement and it is sound advice.  Figure out the goals for measurement first, then the questions you would ask to be able to know whether those goals are being achieved, and then (and only then) select the appropriate metrics that will answer those questions.  In this way, every measurement collected feeds into answering a question that will attain the goal(s).  I’ve seen many companies do it backwards — collect the data first (especially if the data appears easy to collect), assemble it into some sort of metrics database, then try to figure out what to do with it.  I’m not saying this is what is happening with your client, but it may contribute to their frustration.

Let’s assume none of these is happening and FP are simply too labor intensive for the value perceived.  RICE objects and Implementation Units are an option (especially if the intention is to determine product size for use in estimating cost of effort of the software development using a product such as SLIM).

• RICE objects: Emerged from SAP projects, are a count of product components, and breaks down into:
  • R — Reports (number of unique report outputs)
  • I — Interfaces (number of unique interfaces into or out of the application in question)
  • C — Conversions
  • E - Enhancements
• Implementation Units: is a QSM SLIM term used as the base unit from which size in SLOC (Source Lines of Code), FP (function points), RICE objects, functional requirements, use cases, etc. can be converted.  The conversion ratio is based on thousands of completed projects and parametric equations used in SLIM.  Implementation units are not in and of themselves a sizing method.

More information on RICE objects, Implementation Units, SLIM and even the GQM approach to metrics are available from QSM, Inc. — just contact us and be connected with someone who will be happy to talk to you further.

Thanks for your question, Sizing Enthusiast, and hopefully this gives you a few ideas on how to keep your metrics client happy.