Chapter 8: Measuring Software Evolution

8.1 Introduction

As software systems change over time, it is very difficult to understand and measure the effect of the changes. We would like to be able to describe, numerically, the way that each system increment, or build, is different from its successor and its predecessor. This is a very complex problem in that most modern software systems consist of thousands of program modules, on each of which there may be as many as 20 to 30 distinct metrics collected. For any one build, there may be tens of thousands of metrics collected on a typical large system. Knowing what to measure, how to measure, and when to measure will be a key step in understanding the software evolution process.

We accept the fact that our children develop and change on a daily basis. We measure their height and weight to track their development as they grow. Software systems grow and mature in just the same way. We would not measure a child at birth and think that we know what there is to know about that child. Measurement is an ongoing process. We must, therefore, come to understand that our software systems change rapidly over time. Whenever they are changed, they must be remeasured. To understand what a software system is today, we must have current measurement data on the system, together with data on its evolution. We know that faults are removed over time. Modules that have not changed very much are likely to have had most of their faults removed. Modules that have changed a lot are very likely to have had new faults introduced into them. Hence, understanding change activity is vital to our understanding of where the problems in the system might be.