Our Blog Excerpts Savings Contact


Dorset House Publishing
High-Quality Books on Software Engineering and Management.  Since 1984.
dorsethouse.com > features
Features       Excerpts       Interviews


iDH Sign-Up

Get Our e-News
Delivered by FeedBurner

Intelligence Can Guide Us

by Lawrence H. Putnam and Ware Myers

Adapted from Five Core Metrics. Reprinted by permission. All rights reserved. See below for copyright notice.

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."

AddThis Social Bookmark Button




COPYRIGHT NOTICE: This excerpt from Five Core Metrics: The Intelligence Behind Successful Software Management [ISBN: 0-932633-55-2] appears by permission of Dorset House Publishing. Copyright © 2003 by Lawrence H. Putman and Ware Myers. All rights reserved. See http://www.dorsethouse.com/books/fcm.html. The material contained in this file may be shared for noncommercial purposes only, nonexclusively, provided that this Copyright Notice always appears with it. This material may not be combined with advertisements, online or in print, without explicit permission from Dorset House Publishing. For copies of the printed book or for permissions, contact Dorset House Publishing, 1-800-342-6657, 212-620-4053, http://www.dorsethouse.com, info@dorsethouse.com, New: 3143 Broadway, Suite 2B, New York, NY 10027 USA. Additional rights limitations apply, as presented in the Legal Disclaimer posted at http://www.dorsethouse.com/legal.html.



New:3143 Broadway, Suite 2B  New York, New York 10027  USA
1-800-DH-BOOKS or 212-620-4053, fax 212-727-1044
Copyright © 1996-2008 by Dorset House Publishing Co., Inc. All rights reserved.
Home | Blog | Savings | Stores | Features | Titles | Authors | Subjects | Orders | About | Contact | Legal