Implications of software measurement to Lehman's eight laws

Abstract

Software systems change dramatically as they go through their various stages of development. From the first build of each such system to the last build the differences may be so great as to obscure the fact that it is still the same system. Developers commonly make this mistake when they talk about the system that they are developing. It might be referred to as the "File Management System" or whatever name seems to describe the software. This seems to imply that there is but one File Management System. The fact that is obscured when we talk about the File Management System is that today's build of the File Management System is probably vastly different in composition and in functionality from the original first-born File Management System of the first system build. We would like to be able to quantify the differences in the system from its first build, through all builds to the current one. Then and only then will it be possible to know how these systems have changed. The focus of my recent research in software maintenance has been in the area of measurement of software evolution. This research has led to some interesting empirical results that have direct implications for Lehman's eight laws of software evolution. Not all aspects of these eight laws of software evolution lend themselves to direct measurement. In particular the First Law suggests that a system must be continually adapted. This law is driven by forces outside of the software development arena that are very difficult to quantify. The third law is very similar from a measurement perspective. Self regulation is again a property that is attributable to outside forces. The 8th law is confined to the feedback systems nature of the processes controlling software evolution. This, again, is outside the purview of direct measurement. The remaining five laws do lend themselves to direct measurement from the products of software evolution. The main problem with measuring evolving software is that software systems have multiple attribute domains that are changing simultaneously. The size of a program changes. The data structures of that program change. The control complexity changes. In essence, measuring the software evolution process is a multivariate problem. The measurement of an evolving software system through the shifting sands of time is not an easy task. Perhaps one of the most difficult issues relates to the establishment of a baseline against which the evolving systems may be compared. When a number of successive system builds are to be measured, we will choose one of the systems as a baseline system. All others will be measured in relation to the chosen system. Sometimes it will be useful to select the initial system build for this baseline. If we select this system, then the measurements on all other systems will be taken in relation to the initial system configuration. Within this context, laws 4, 5, and 6 lend themselves directly to measurement directly from a baseline system. Data from the several projects at the Jet Propulsion Laboratory support this conjecture. Until very recently, it would have been very difficult to