10.6 MAP BASE METRICS TO AVAILABLE DATA

 < Day Day Up > 



10.6 MAP BASE METRICS TO AVAILABLE DATA

Defining the metrics and identifying the tools to support, say, cost estimation means that you have defined a set of base metrics and this raw data needs to be collected. Of course, you do not want to reinvent the wheel so it makes sense to use data that is already collected by the organization if possible.

This has two distinct benefits. First, it reduces the amount of work that you have to do as you do not need to design the collection system from the ground up and, second, it means that you reduce the amount of additional work that your data suppliers, often the engineers, have to do. This is always a good idea because any time spent filling in data sheets is time that could have been spent on system development.

There are some problems and disadvantages to using existing mechanisms and these should not be ignored. Very often the data supplied will not be exactly what you want. For example, if you have a defect reporting system it may not record the root cause of the defect. In this case you are going to need management commitment to enable you to change the existing system to record that data element but this is much less of a commitment, because of a lower cost, than that required for the development and implementation of a completely new system.

Another serious problem with existing systems is that they are often viewed as part of the unavoidable bureaucracy associated with, or perhaps more correctly hindering, "real" work. This often means that very little care is taken over filling in the "form" and that the data is then incorrect. The classic example of this is timesheets but you often see it in defect reporting systems. In this case, the system may record the root cause of the defect, perhaps in terms of the development lifecycle stage that injected the fault, but the field that records this may be filled in with the lifecycle stage where the fix was made. After all, why worry about it, nobody does anything with the data!

As mentioned earlier I have seen cases where defect reports have been re-analyzed, the percentage split between code defects and earlier lifecycle stages change dramatically. The problem was that engineers were fixing the fault by changing the code so that was what went into the "cause" field. Never mind that the design or the requirement specification was wrong.

If the problem with an existing system is that the specific data you require is not there then the obvious answer is to change the system so that it will supply the required item. This is often the best option. Another option is to change the requirement on the existing system. You will often find that there is another data item available that can almost give you what you want or alternatively that there is another system or method by which could provide the data. For example, in one case an organization I was involved with was looking for a way to measure software product size. The first choice was to use a tightly defined Line of Code count but we found that this data was generally unavailable, strange as that may sound. What was available was a measure of memory required by the system and investigation showed that there was a reasonable relationship between this and Line of Code size. Not a perfect solution by any means but a pragmatic one given the particular circumstances.

This idea of changing the requirement can be taken one step further. You are looking for base metric data because you have identified a model-based, composite metric that will give you useful information. You could always change the composite metric or the model if the raw data is not available. This does require that you be very objective about "your" measures but it is an option and should be considered. After all, these measures are not cast in stone.

If the data is being supplied but is inaccurate you have to deal with a more fundamental problem. You could just accept the data. From a theoretical point of view this is not a sound approach but it can be valid in some cases. If you consider the situation where an individual is booking time to two projects you may not get accurate data. He or she may book more time to one project during one week based on nothing more than a guess. Rather than spending time trying to impose accuracy you may just assume that if more time is booked to one project this week then the reverse will be true next week, or the week after, so things will even out. Not very accurate but it could be acceptable if coarse measures are required.

Of course, you will eventually have to bite the bullet and try to improve the accuracy of recorded data. I have more to say on this topic elsewhere.



 < Day Day Up > 



Software Metrics. Best Practices for Successful It Management
Software Metrics: Best Practices for Successful IT Management
ISBN: 1931332266
EAN: 2147483647
Year: 2003
Pages: 151
Authors: Paul Goodman

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net