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:
estimates of project effort, schedule, and reliability
- control of the
project during its course
- ability to replan an errant project along the
- master-planning the assignment of resources to all projects within
- 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
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"?
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
Risk. A software product of some size and novelty
- Critical risks: Elders determine that the product
is within the current state of the art and within the capabilities of the project
- Significant risks: Elders establish that the
project can surmount these risks within the schedule and effort planned.
"things" and the metrics that measure them are what we mean by "the
intelligence behind successful software management."