Metrics and Models in Software Quality Engineering

This book is a must have for all the managers and profesionals that need a complete and detailed reference for software metrics. It provides clear explanations and examples. It is very easy to read and very practical.

As the System Test Team Leader for the Quality Technology area, I had to certify many of the tools and procedures used by Stephen Kan. Prior to that, as a System Administrator, I had to run software metrics on those tools, like those shown in table 6.3. As a design review moderator, I was charged with leading a number of IR, IE and I0 reviews. THIS STUFF WORKS! I can attest personally to the great effort and many find minds that worked together to develop and implement fine tools such as DCR, PTR, PTF and APAR, as well as the brilliantly simple, effective ways of implementing Continuous Quality Improvement techniques such as DPP. What Kan has written is real-world honest and true, not some academic exercise. Kan is dead-right on the money. If you want to track, predict and manage things in the real world, this is how you do it. At PSQT '97, Tom Gilb told me that SEI should create a new CMM "Level Six" designation for the way Kan and the others at IBM Rochester have dealt with software quality. That's how good the stuff in this book is. I am particularly impressed by how Kan has woven in not only his work and IBM Rochester as a whole, but also the work of others throughout the industry in such a simple, clear, easy to understand manner. Yet, given that the book is an easy read, that many of the techniques are easy to do, and that I see this book on the shelves of many IT managers, it baffles me why so few people and so few companies actually implement this stuff. I suspect that politics and corporate culture is what's holding back so many companies from enjoying the success, efficiency, and frankly the FUN of working in a continually measuring, continually refining work environment such as Kan describes. For example, Defect Removal Effectiveness is a very simple metric to gather. In a typical medium sized software company, or in the I.T. department of a large company, the head of testing and the head of phone support could easily enough get together and compare the number of bugs found in testing the last release with the number of bugs found in the field after that release was deployed. Both areas already have their problem logs, and if they can't directly pull counts and totals, it's typically only a few minutes work for the right programmer. So what's the hold up? It's not that the metric is hard to understand, or an academic exercise, or that the numbers are hard to get. It's that people have a hard time admitting that "their baby is ugly". The good of the company, stopping bugs from getting to the field, conflicts with the good of the testing manager, who doesn't want to risk admitting that problems got past them. Therefore, I think it would be a fine addition to this book if Kan could write another chapter which deals with the human side of the equation. The book thus far presumes an interest in software metrics and appropriate management support from the top levels down. What would move this book from worker's booksh

This is one of the most highly regarded books on software quality. If you have never read the first edition it was one of the few books that covered software quality in depth, going well beyond metrics and models into strategies for achieving quality, and understanding the underlying principles and mechanics. That edition had a lot of life left in it, but this second edition is one of the most complete rewrites of any technical book I've read in recent memory, and if you own the first edition you may want to consider retiring it and investing in this edition.While the first edition packed a lot of information in 344 pages, the 560 pages that comprise this edition reflect new chapters and expanded content in the chapters that remain. Here is a list of the new chapters:- Chapter 10, In-Process Metrics for Software Testing- Chapter 12, Metrics and Lessons Learned for Object-Oriented Projects (in lieu of the old Chapter 12 titled AS/400 Quality Management)- Chapter 13, Availability Metrics- Chapter 15, Conducting In-Process Quality Assessments- Chapter 16, Conducting Software Project Assessments (the project assessment questionnaire example in the appendix is a valuable companion to this chapter)- Chapter 17, Dos and Don'ts of Software Process Improvement (contributed by Patrick O'Toole)- Chapter 18, Using Function Point Metrics to Measure Software Process Improvement (Contributed by Capers Jones)Among the new chapters I most like are Availability Metrics (Chapter 13), because of the direct tie to production, and Dos and Don'ts of Software Process Improvement (Chapter 17) because of the practical and objective advice. This book will remain, in my opinion, one of the definitive texts on software quality and is one I highly recommend.

I use this to teach a class on metrics for Drexel University.The material is inherantly dry, but Kan covers it clearly and well. Agood balance is struck between product metrics (e.g. reliability) and broader metrics (customer satisfaction).

Kan highlights a great many development and analysis techniques with just enough supporting detail to be instructional and informative without being pedantic. Good information pertaining to the overall development lifecycle as well as to components of various phases of a lifecycle (predictive analyses, reflective metrics, customer satisfaction measurement, etc) are included. Each chapter contains an excellent reference bibliography that allows the reader to pursue greater detail on a subject matter if necessary. And the book itself contains a very comprehensive index section that aids in topic referencing. Highly recommended.