Customer Reviews

Practical Software Metrics for Project Management and Process Improvement

5 star:		(7)
4 star:		(2)
3 star:		(0)
2 star:		(0)
1 star:		(0)

 

 

I was introduced to Mr. Grady's work when I borrowed a copy of Software Metrics: Establishing a Company-Wide Program. Where that book interwove a storyline into metrics and how they support mature process improvement, this book is more like a desk reference. Mr. Grady has divided this book into two parts: tactical metrics, which are project-oriented, and strategic metrics which address process improvement.

The first part starts with a collection of practical rules of thumb for software managers. This collection of heuristics covers every phase of the development life cycle and are backed up with data gathered during 125 software projects at Hewlett-Packard. An example of one of these rules of thumb is that you will find 1 defect after software has been released into production for every 10 defects caught during testing. This, of course, is purely empirical, but is an interesting rule that I mentally filed away. Some highlights of the first part are: a good introduction to the goal-question-metric approach to determining what to measure based on your objectives, and a focus on project goals of maximizing customer satisfaction while minimizing project schedule and costs, and product defects. This is followed by chapters that address each of these goals. One of the best chapters in the first part of this book is work analysis. While I am more focused on the service delivery side of metrics (after the project has produced something that has been released into production), some of the metrics were very valuable to me - especially the ones that revolved around testing and QA.

Part 2 is squarely in my domain - production and application support, and service delivery. The best chapter, Dissecting Software Failures, was one of the most insightful descriptions of the defect life cycle I have ever read. It fully addresses defect data collection and analysis, and how to use this data to effect process and product improvement. Even better is the chapter on investing in process improvement. Here Mr. Grady gives a workable approach to using the defect data to developing a business case for process improvement. He guides you through developing a plan, selecting from among an array of solutions, and case studies.

This book is a quick read. It's main value lies in the many tables and facts provided on nearly every page. I use it as a desk reference, especially the appendices that summarize defect origins, types and modes, and metrics definitions. It spans both project and production metrics, and is as valuable to project managers as it is to application support professionals.

While the book (like most other books of its kind) is a very high-level overview of its subject matter, it discusses many new and compelling ideas that you should find of great use for your own development efforts. Of particular note is the author's discussion of the FURPS+ system, in which functional and nonfunctional requirements are melded into an easily-readable matrix, and all requirements are assigned numerical grades for priority and technical risk. (FURPS+ was developed at HP, where the author works.) And project leaders should pay careful attention to the chapters on project phase metrics, where the author provides average project percentages for the major phases of development.

This is Grady's first book and it sets the tone for his later two books, Successful Software Process Improvement and Software Metrics: Establishing a Company-wide Program. What makes this book so important is that it is one of the first to integrate software metrics with project management metrics.

What I particularly like about this book includes:

(1) Complete view of metrics that matter, and the chronicle of how these metrics evolved in a large company (Hewlett-Packard).
(2) Recognition that any software metrics initiative extends beyond the project that delivers the software - Grady examines post-production metrics and ties them back to not only the development life cycle, but the product life cycle as well. Ten years after this book was published there are still large organizations that are struggling with doing this, yet Grady's book provides a clear roadmap to achieving this elusive goal.
(3) Continuous improvement is the central theme in this book. Grady does not stop with collecting and analyzing metrics, but how to effectively employ them to spot improvement opportunities and develop a strategy to effect those improvements.

The book is written as both a story of how a successful metrics program evolved, complete with anecdotes that will prove helpful, and as a collection of data that illustrates what is and is not important to a comprehensive metrics program.

Among all of Grady's books I like this one the best; however, I recommend that his other two also be carefully read if software process improvement is your goal. He has much to say and backs it up with data and a chronicle of his experiences from real projects.

Although this book is over 10 years old, it could have been written this year. The concepts are still relevant.
The author concludes that there are 2 primary reasons to undertake a metrics program for software development -- 1) tracking progress and 2) identifying improvements. The book is divided into 2 parts, with the first part discussing project management metrics and the second part metrics to improve your software development processes. I particularly liked the goal/question/metric approach to validate the metrics you are collecting. The text is loaded with examples from the author's experience at HP. There are several charts and diagrams. This is not an academic read, but as the title says -- practical. The author also covers people issues, such as selling your metrics program to management and staff. It is a quick read and a very useful reference book.

This book is for anyone who has a novice-level knowledge of the subject of metrics. It reinforces previously gained knowledge and expands your dossier of techniques considerably. My main use is to learn how to perform metrics gathering/analysis for the sole use of process improvement.

I bought this book about 5 years ago after getting certified as a project manager. This book give me a holistic view of how to intepret data collected from tracking the entire software lifecycle and manage and integrate best practices into a software business.

The author's vast experience in HP helps to provide good assurance that his concepts used were tried and robustly tested. Therefore, software failures, internal flags and customer feedbacks can immediately give you a fairly visible prognosis to the robustness of a release and flashes early warning signs of how you should manage that product to reduce damage to your business, etc.. Practical for technical managers having to manage the business operations.

The rules of thumb section was very useful. I have used the software project estimation techniques to great advantage in our consulting work at journyx.com.

This book is a classic on one of the earliest efforts to collect software metrics. It's getting a bit dated for today's webdev efforts, but still worth a read to understand how we got where we are today.

Whether you're a fledgling company trying to design quality software with no guidelines to go by or a well-developed organization with processes in place, this book offers up many ways that you can improve your software quality.