10.4 IDENTIFY EXTERNAL PRODUCTS

< Day Day Up >

I have used a model or technique for deriving metrics but there is no point in reinventing the wheel. You will come across situations where there are already proprietary products available on the open market or techniques in the public domain that you can adopt, thus circumventing the derivation process. This means that you can move onto implementing the use of those products or techniques very quickly.

This does not mean that no work will be required. You will find that many of these products and techniques need to be adapted to your own environment but much of the hard work has been done for you. To illustrate the GQM approach I have discussed to the case where external products or metrics already exist externally to the organization, I will use the same metric derivation model as a framework.

By far, the biggest market offering, in terms of proprietary products, is in the area of cost estimation so I will use these to illustrate the mechanism. Elsewhere I have discussed various of these software tools and it is sufficient to say here that the list is large with new packages being added, it seems, every week. I have also discussed the value, in my view, that these products can offer so I will confine myself to talking about the process of satisfying requirements within your own metrics initiative.

Essentially, the goals step of the model needs to be addressed as before. You still need an identified requirement and an identified customer and you should classify the requirement within the high level metrics program requirements. You may also find constraints creeping into your requirements. For example, you may be constrained to using PC-based software.

It is in the "Questions" area that the most significant difference is seen. What is needed is for you to investigate the market place to see what is available. Only you will be able to decide which of the many tools is best suited to your needs given your requirements, any constraints and the persuasiveness of the salesman. One thing I would strongly recommend is that you get a feel for the product through hands-on experience. This is the only way that you can tell if the tool is easy to use and suitable. Ideally you should carry out a full evaluation using historical data and comparing the results with the predictions from the tool, but this can be difficult, not least because much of the information you need may not be available. If it was, you might not need a Software Metrics program!

The tools will tell you what information they require as input and these are obviously the base metrics you need to collect. Another word of warning: many of these tools ask for a great deal of information but supplying all of these inputs can sometimes distort the accuracy of the predictions. Look instead for the key "cost drivers" that affect the model by playing with the tool and also determine, again by talking to the people who know (the project managers and engineers), what are the important drivers.

Having made your selection all you need do is implement the tools. Yes, the hard part again!

You can also modify the derivation model to apply it to the selection of "public domain" metrics. These include most variants of Function Point Analysis, McCabe metrics and Information Flow metrics. Many of these come complete with analysis techniques or guidelines for use and some, such as the McCabe metrics, are also supported by proprietary products.

Again you need to go through the Goals step of the derivation model and you need to research the market to see what is on offer. A good way of doing this is to attend some of the training courses that cover the theory of metrics, and more and more of these are being staged. Or, even better, you can attend some of the metrics conferences that are now regular events.

Once you have gone through the Goals step and identified a market offering you are in the position of having brought in a model. Then you simply apply the derivation model in the same way as I have outlined above through to determining the base metrics you need to collect.

< Day Day Up >