For more than 50 years software has been a troublesome discipline. Software’s problems are numerous and include cancelations, litigation, cost overruns, schedule overruns, high maintenance costs, and low levels of user satisfaction. The problems with software occur more often than not. My company’s research indicates that more than half of large software projects will encounter some kind of delay, overrun, or failure to perform when deployed.

But software does not have to be as troublesome as it has been. Some complex software projects do achieve their delivery schedules and cost targets, and behave properly when used. Throughout my career in software I’ve been interested in what distinguishes successful software projects from failures and disasters.

It happens that the main factors leading to software success are easily identified when side-by-side comparisons of similar projects are performed, where one set was successful and the other set was troublesome. The successful software projects achieve excellence in software quality control, and they are able to do this because of excellence in software quality measurements.

Although it might be thought that excellent software quality control is expensive, it turns out to yield a very positive return on investment. When canceled software projects and disasters are studied by means of “autopsies,” they all have similar patterns: Early phases of troubled projects are handled carelessly without adequate requirements analysis or design reviews. After rushing through the early phases and seeming to be ahead of schedule, problems begin to mount during coding and testing. When testing begins in earnest, serious problems are detected so that schedules and cost targets cannot be achieved. Indeed, some software projects have so many serious problems—termed bugs or defects—that they are canceled without completion.

By contrast, successful projects are more thorough at the start. The requirements are carefully analyzed and the designs are formally inspected. This takes some time and adds upfront costs, but once coding and testing begin, the value of careful quality control allows the projects to move rapidly to a successful conclusion.

Stephen Kan and I both learned the importance of software quality control and good software quality metrics at IBM. Even though Stephen and I worked in different IBM labs during different decades, we have some common viewpoints. We have both been convinced by empirical evidence that without excellent software quality control, large system development is hazardous and likely to fail. We also both know that effective software quality control is built on a foundation of careful measurements using accurate metrics.

Stephen and I both had access to IBM’s internal quality data—one of the best and largest collections of software data in the world. But one company’s internal information is not sufficient to be convincing unless other organizations replicate the findings. Stephen’s excellent book goes beyond IBM; it offers valuable information from many companies and government agencies. He cites studies by Hewlett-Packard, Motorola, NASA, and other organizations that have solved the problems of how to build software successfully.

I first encountered Stephen Kan’s Metrics and Models in Software Quality Engineering book in 1995 when the first edition was published. I found that the book contained solid research, and that it covered a broad range of topics and very clearly showed the relationships among them.

This new edition keeps all the virtues of the earlier work and adds substantial new information, such as a chapter on measuring quality within the object-oriented paradigm. Stephen Kan’s new edition contains an excellent combination of solid scholarship and breadth of coverage. This is the single best book on software quality engineering and metrics that I’ve encountered.