1.2 AREAS OF APPLICATION

< Day Day Up >

There are many different ways in which Software Metrics can be used, some of which are almost specialties in their own right. There are also many ways in which the domain of Software Metrics can be divided. The approach I prefer is to consider specific areas of application of Software Metrics.

The most established area of Software Metrics has to be cost and size estimation techniques. There are many proprietary packages on the market that will provide estimates of software system size, cost to develop a system and the duration of a development or enhancement project. These packages are based on estimation models, the best known of these being the Constructive Cost Model (COCOMO), developed by Barry Boehm, Boehm(1) and subsequently updated based on the experiences of many companies and individuals, Boehm et al (1) . Various techniques, that do not require the use of tools are also available.

There has been a great deal of research carried out in this area and this research continues in the United States, Europe and elsewhere. The Department of Defense in the United States, various governments around the world and the European Economic Community sponsor much of it. One thing that does come across strongly from the results of this research work is that organizations cannot rely, solely, on the use of proprietary packages.

Controlling software development projects through measurement is an area that is generating a great deal of interest, both in Europe and the United States. This has become much more relevant with the increase in fixed price contracts and the use of penalty clauses by customers who deal with software developers, not to mention outsourcing, facilities management or "partnership" arrangements that are so prevalent today.

The prediction of quality levels for software, often in terms of reliability, is another area where Software Metrics has an important role to play. Again, there are proprietary models on the market that can assist with this but debate continues about the accuracy of these. The requirement is there, both from the customers point of view and that of the developer who needs to control testing and proving costs. Various techniques can be used now, and this area will become more and more important in the future.

The use of Software Metrics to provide quantitative checks on software designs is also a well established area. Much research has been carried out, and some organizations have used such techniques to very good effect. This area of Software Metrics is also being used to control software products that are in place and that are subject to enhancement.

Other applications of Software Metrics include research into the effect of soft or environmental factors on the effectiveness of the development process. Some years ago, this prompted one large organization to build a development complex specifically designed with the needs of engineers or programmers in mind, (McCue 1978). This option is not open to most organizations but there is usually a great deal that can be done to improve the development process by making changes to the environment that process operates in.

Measurement can be used to identify where change should be concentrated. Just starting to measure soft factors can often lead to useful insights regarding the way in which a process operates and this can lead to benefits to a business by improving performance in key areas such as lead time to market (Ahlgren 1992).

Using measured quantities to compare your own organization with others is an extremely popular area of Software Metrics, especially for senior managers. This is most commonly referred to as "Benchmarking" and indeed, it is often why a measurement program starts in the first place. Benchmarking does, however, involve effort on the part of the organization, so the benefits must be weighed against the costs. One result of using such an approach is that you can actually discover that you were as bad as you thought but that most other organizations are also as bad! This can be very useful information, but even more importantly such a service can help you identify who is "best in class." Once you have this information you can learn a great deal from it.

Finally, we come to the most common use of Software Metrics: the provision of management information. This includes information about productivity, quality and process effectiveness. It is important to realize that this should be seen as an on going activity. Snapshots of the current situation have their place, but the most valuable information comes when you can see trends in data. Is productivity or quality getting better or worse over time? If so, then why is this happening? What can management do to improve things? The provision of management information is as much an art as a science. Statistical analysis is part of it but the information must be presented in a way that managers can make use of, at the right time and for the right reasons.

All this shows that Software Metrics is a big field! Recognizing this fact is an important step in that it presents a choice. You can probably see many of the areas identified above as having relevance to your business. Do you try to implement Software Metrics in these many forms or do you adopt a "softly-softly" approach tackling one or perhaps two areas first? Both approaches have benefits and dangers associated with them. Resolving this issue within an organization brings us to the first principle of Software Metrics implementation: pragmatism and compromise.

At this point I would like to make a number of points regarding certain principles that, while I will attempt to justify them, I suggest are treated as axioms as far as this book is concerned. These are some of the concepts that form the foundation for the core of this book. I will also take the opportunity to discuss some of the dangers inherent if the approach taken to software engineering and its management excludes Software Metrics.

< Day Day Up >