- Paperback: 328 pages
- Publisher: Dorset House (May 2003)
- Language: English
- ISBN-10: 0932633552
- ISBN-13: 978-0932633552
- Product Dimensions: 7 x 0.8 x 9 inches
- Shipping Weight: 1.2 pounds (View shipping rates and policies)
- Average Customer Review: 4 customer reviews
- Amazon Best Sellers Rank: #2,160,898 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Five Core Metrics: The Intelligence Behind Successful Software Management
Use the Amazon App to scan ISBNs and compare prices.
Fulfillment by Amazon (FBA) is a service we offer sellers that lets them store their products in Amazon's fulfillment centers, and we directly pack, ship, and provide customer service for these products. Something we hope you'll especially enjoy: FBA items qualify for FREE Shipping and Amazon Prime.
If you're a seller, Fulfillment by Amazon can help you increase your sales. We invite you to learn more about Fulfillment by Amazon .
Customers who viewed this item also viewed
Customers who bought this item also bought
About the Author
Larry Putnam, Sr., and Ware Myers have written three previous books and numerous articles together over many years. Mr. Putnam, a leading expert in the software estimation and management field, is the president of Quantitative Software Management, a software management consulting firm based in McLean, Virginia.
Ware Myers is an independent consultant and a long-time contributing editor to Computer and IEEE Software. His current interests include the application of metrics to software planning, estimating, bidding, and project control.
Excerpt. © Reprinted by permission. All rights reserved.
INTELLIGENCE CAN GUIDE US
Whether it's a single company making use of metrics or nine companies finding out from measurements how much difference a new technology made, metrics can tell us that we are doing things right. Metrics provide and enable the following:
* dependable estimates of project effort, schedule, and reliability
* control of the project during its course
* ability to replan an errant project along the way
* master-planning the assignment of resources to all projects within the organization
* monitoring process improvement from year to year
Furthermore, an organization can apply these same metric capabilities to the oversight of development subcontractors and outsourcing contractors.
But first we must ask, What do we mean by doing things right? We mean that, fundamentally, we are turning out software products in less development time, with less effort, at a better reliability level. What are those "things" we are trying to do right? If we do some "thing" and then make some measurements, the metrics tell us whether it was the right "thing" to do. Moreover, advancing metrics confirm our confidence in the value of continuing to do that "thing."
By now, enough organizations have done some "things" and tracked favorable metrics as a result that we have a pretty good idea of what the "things" are. In fact, the "things" plus the metrics to measure them constitute "the intelligence behind successful software management." What are the most important of these "things"?
Process. At a minimum, a software organization needs a process that it can repeat the next time. Repeatability lies at the heart of estimating and bidding. More importantly, it enables a project to meet the expectations of its own and the client's management. Beyond repeatability lie two more stages. The first is the employment of guides to improve the process, such as specifications and the Capability Maturity Model. The second is the move to a process standard, such as the Unified Software Development Process (described further in Chapter 3).
Standardization. We hesitate to bring the dreaded word standardization into play. Many software people regard the writing of code as more an art than a science. Indeed, at a certain point, there is art in it. But Shakespeare did write in the English of his day, then an emerging standard. Artists of software can work in standards intelligible to other artists, as well as to their other co-workers, managers, and certain of the client representatives. One of these "standards," dating from as recently as 1997, is the Unified Modeling Language (UML). It gives developers a "drawing" medium to work in. It enables them to recall their own work months later. It enables developers to read each other's work. It provides a permanent record of the work accomplished.
Software tools. An important outgrowth of standardization is software tools. When everybody does his own thing in his own way, you can't reduce that proliferation of half-formed methods to tools. Tool builders have to have a large market (in other words, some degree of standardization) to support their cost of development and marketing.
The software product. Before management can intelligently assign staff to a project and forecast the schedule it will take, it needs a clear grasp of what the product is to be. That preliminary task itself takes some staff and time, so people in a hurry sometimes bid before they have product functionality, commonly known as "size," as the basis for a more reliable bid. In other words, an effective software process provides for certain phases before formal construction under a bid (or other costing arrangement) begins.
Risk. A software product of some size and novelty involves risk:
* Critical risks: Elders determine that the product is within the current state of the art and within the capabilities of the project organization available.
* Significant risks: Elders establish that the project can surmount these risks within the schedule and effort planned.
These "things" and the metrics that measure them are what we mean by "the intelligence behind successful software management."
Try the Kindle edition and experience these great reading features:
Showing 1-4 of 4 reviews
There was a problem filtering reviews right now. Please try again later.
Material in this book is not done justice if you go solely by the table of contents. It contains deep thought and a wealth of information that support the five core metrics proposed. After introductory material in the first chapter, this book picks up pace by going into what the authors consider to be the right metrics and why. They follow this discussion with a chapter that shows how they align to a development lifecycle (using the RUP's inception, elaboration, construction and transition phases as a framework). This is followed by two chapters that address the five metric areas, time, effort, quality, workload and productivity, and sizing. Chapters 7 and 8 address productivity and reliability as they relate to the metrics.
I liked the material in the final chapters the most because it takes the concepts in the first eight chapters and applies them to problem spaces such as project control, requirements management, trade-off analysis, and how to use estimates to formulate accurate bids. This material is practical and reflects the real world. Among my favorite chapters are 15 (Replan Projects in Trouble), 17 (Evaluate Bids on the Facts), and 21 (Metrics Backstop Negotiation). However, each chapter in between was also on the mark and credible.
If you are immersed in an unmanageable morass of metrics and want to manage to a smaller set of key indicators in projects or maintenance this book is an essential resource. If you are using Ad Hoc metrics or none at all, this material is an ideal starting point.
three years now but our efforts were and are still fruitless.
Although we were recording four core metrics (we were using
conventional productivity not process productivity so I'm
counting this one out) -- effort, time, size and defects
(although not the defect rate), we didn't know their
relationship until now. The knowledge we have gained from this
book will help us renew our efforts next year.
Statistics know-how is somewhat needed to understand some of the
chapters although you won't actually be computing anything. I
mean if you don't know what normal curves, medians, standard
deviations are, then you'd be at a lost. I've bought a book
on statistics to relearn it along with my colleagues. However,
the graphs make up for it.
The book was also somewhat lacking in giving actual values to
put in the formulas. I think I'm interpreting the data
incorrectly because I'm getting very big or very small values
from the process productivity formula. I've e-mailed QSM but
they haven't replied yet but I do hope they will.
Nevertheless, the book is a good companion to other software
quality books that focus on people, methods, processes, tools
but don't mention how to measure them objectively.
Get this book if you're part of the software industry regardless
of your title, rank, responsibilities, or party (client or
I found the latter part to be excessive content, but all in all a good read.
Apart from mentioning tigers in Africa I didn't find any blatant errors
It is as if the authors never grasped the CTQS triangle, and such of project management. The 5 metrics are so obvious and unmeasureable that it is an exercise in no-kidding, now what.
The continual references to the third rock from the sun and such is just page filler.
A nice title but no beef here (to have a pharase from the time the authors seem to still be living in).
I suggest you find more meaningful books.