Software Metrics: Best Practices for Successful IT Management

3.6 WHAT ABOUT USABILITY?

As a starting point you could do worse than looking at the number of user complaints, defect, fault or error reports, from the field where the root cause is not related to the reliability of the software. Here I intend that you should consider all such reports and not reduce the set by considering only validated non-duplicates. The reason for this is that you are looking for the "pain" level felt by the customer as a result of your not providing sufficiently good documentation, training or support to that customer. This is an incredibly simplistic approach to usability measurement and I would accept that it ignores the ergonomic aspect of systems. In defense of this measure I would say again that it is a "pain" measure and that pain is really the inverse of usability.

Maintainability, as I consider it as corrective maintenance, results in the most complex of the suggested models. I find that there are three parameters that affect managers and users view of the system maintainability. These are:

• The number of defects fixed

• The time it takes to fix a defect

• The number of defects outstanding, i.e., not fixed.

Combining these, I suggest that a maintainability metric can be derived from the following model:

• For a given time period, say one calendar month, consider the average time taken to fix a defect multiplied by the sum of the defects fixed and the defects outstanding.

• In this model, if any parameter worsens, the overall result also worsens and the source data, the three parameters can be investigated to identify the cause. Simply recording the parameters separately can cause you to miss a developing problem, especially when the three parameters all start to get slightly worse at the same time. You do not see a problem but the user does.

• Finally, for enhanceability, the ease by which requested changes can be made to a system, you can consider the number of components affected by a change divided by the total number of components in the system. The reasoning behind this model is that systems do degrade as more and more enhancements are made and the system level cohesion and coupling properties worsen. In other words, the mix of functionality within a given system component tends to increase and the number of links between components increases. This tends to reduce enhanceability. This model reflects those effects and enables corrective action such as strategic rewrites, namely work that adds no functionality to the system but which is intended to improve enhanceability, to be carried out.

Again, these models are presented as suggestions or starting points. I do not claim that they are perfect models, or even the best available, simply that they have worked for me. What you use in your organization is up to you.