Information Technology Reference
In-Depth Information
Figure 5.1 shows the software measurement process . The process is generic in
that it can be instantiated at different levels (e.g., project level, divisional level, or
organizational level). This process links the measurement activities to the quantifying
of software products, processes, and resources to make decisions to meet project goals.
The key principle shared by all is that projects must assess their environments so
that they can link measurements with project objectives. Projects then can identify
suitable measures (CTQs) and define measurement procedures that address these
objectives. Once the measurement procedures are implemented, the process can
evolve continuously and improve as the projects and organizations mature.
This measurement process becomes a process asset that can be made available
for use by projects in developing, maintaining, and implementing the organization's
standard software process (Paulk et al., 1993).
Some examples of process assets related to measurement include organizational
databases and associated user documentation; cost models and associated user docu-
mentation; tools and methods for defining measures; and guidelines and criteria for
tailoring the software measurement process element.
5.3
SOFTWARE PRODUCT METRICS
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
Integration (CMMI) include measurement.
Companies are using metrics to better understand, track, control, and predict soft-
ware projects, processes, and products. The term “software metrics” means different
things to different people. The software metrics, as a noun, 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. Goodman
(1993) expanded software metrics to include software-related services such as instal-
lation and responding to customer issues. Software metrics can provide the informa-
tion needed by engineers for technical decisions as well as information required by
management.
Metrics can be obtained by direct measurement such as the number of lines of
code or indirectly through derivation such as defect density
number of defects
in a software product divided by the total size of product. We also can predict
metrics such as the prediction of effort required to develop software from its measure
of complexity. Metrics can be nominal (e.g., no ordering and simply attachment
of labels), ordinal [i.e., ordered but no quantitative comparison (e.g., programmer
capability: low, average, high)], interval (e.g., programmer capability: between 55th
and 75th percentile of the population ability) ratio (e.g., the proposed software is
twice as big as the software that has just been completed), or absolute (e.g., the
software is 350,000 lines of code long).
If a metric is to provide useful information, everyone involved in selecting, de-
signing, implementing, collecting, and using, it must understand its definition and
=
Search WWH ::
Custom Search