on target

How to measure applications

No matter if you are a developer, an IT manager or the owner of a software house, you need some metrics to measure the application system you produce, manage or sell. When you plan a car trip you decide how many miles you will drive, allowed speed and required time. Why don't you do the same for the applications you produce? Let's look at some common ways of measuring systems.

SLOC (Source Lines of Code) is the most traditional way of measuring how "big" a system is. To measure a system in SLOC you shall dispose of its source code (and some tool to count source lines). SLOC are related to system cost and can be used to estimate maintenance effort.

SLOC heavily depends on language and technology used but, in general, language and technology are constant inside same organization and SLOC is a good metric to measure size.

On the other side SLOC can't be used to measure system value: being big does not mean being useful and it is possible to write 10 million SLOC application with absolutely no value.

Se we need a second measure to assess value. For business and information systems a widely used and accepted metric is Function Points Analysis (FPA).

How does FPA work? By assigning a predefined number of points to each "function" visible to user, you can compute the total number of function points of your application. A simple input, like a login dialog, for example, gets 3 function points (FP) and a complex report gets 7 function points.

SLOC and FP are different measures and both are needed to size an application system: SLOC is an internal measure of application size and FP is an external measure of its value as shown by the following figure.

Keep in mind that FPA only consider functions that are "visible" to user, in fact whatever is not visible (for example a log file) has no value to him.

Function Points "bible" is Function Points Counting Practices manual, but there is an excellent alternative and practical guide on FP analysis: Function Point Analysis: Measurement Practices for Successful Software Projects by David Garmus.

Function Point Analysis (FPA) is an effective technique that allows correct estimates, clear identification of overruns causes (usually due to new functions added during project) and performance evaluation (including used technology and libraries). I pretend to address specific techniques in future posts.

FPA major drawback is counting effort. To take advantage of FPA, counting shall take place at different times from requirements to maintenance. There are several automated tools to perform FPA but they all require manual input of counted elements, this is usually an overkill for the constantly under-pressure IT staff.

At Component Based Solutions we have developed a simple and practical extraction method based on annotations that automatically extracts FP count from requirements, use cases (or stories) and source code. Anybody interested? Just post a comment and I will make the program freely available online.

Interested in partnership?

Would like to try or coach this technique with your clients, do you need any additional or technical detail? Please let me know! Component Bases Solutions has great interest in partnership with consultants. We can help you automate your proposed solutions in a very short time. We can also help to increase your visibility through links from many management tools we make freely available on the Web. Please contact for more detail.

Did you like this post?

Please, spend a few seconds and click on button below to socially bookmark it or tweet it. It will help to promote this blog and improve its content, Thank you!

Posted at 03:30PM Jan 14, 2009 by admin in IT  |