Software metrics
are an integral part of the state-of- the-practice
in software engineering.
More and more customers are
specifying
software and/or quality metrics reporting
as part of their contractual
requirements. Industry standards like
ISO 9000 and industry models
like the Software Engineering
Institute’s (SEI) Capability Maturity Model Integrated (CMMI®) include
measurement. Companies are using metrics to better understand, track,
control and predict software projects, processes
and products.
The term
software metrics means different
things to different people. When we buy a book or pick up an article on software metrics, the topic can vary
from project cost and effort prediction and modeling, to defect tracking
and root cause analysis,
to a specific
test coverage metric,
to computer performance modeling. These are
all examples of metrics
when the word is used as
a noun.
I prefer the activity
based view taken by Goodman. He defines software
metrics as, "The continuous application of
measurement-based
techniques to the software development process and
its products to supply meaningful
and timely management information, together with the use of those techniques
to improve that process and
its products." [Goodman-93] Figure 1, illustrates an expansion
of this definition to include software-related
services such as
installation and responding to customer issues. Software
metrics can provide the information
needed by engineers for technical decisions
as well as information required
by management.
If a metric is to provide useful
information, everyone involved
in selecting, designing,
implementing, collecting, and
utilizing it must understand its
definition and purpose. This
paper outlines twelve steps
to selecting, designing and
implementing software metrics
in order to insure this understanding.
No comments:
Post a Comment