Environmental Engineering Reference
In-Depth Information
on an absolute indicator such as total number
of defects discovered is not informative because
lack of possibility for judging the size (measured
in the lines of source code or number of opera-
tors) of comparable programs, their complexity,
conditions of development, testing and other char-
acteristics. It is obvious that it is more expedient
in this example to use metrics that determine the
relationship of the total number of defects to the
size of software, quality of programming modules,
test time and so forth.
The special feature of the second approach is
the fact that metrics are interpreted as dedicated
indicators (supplemental with respect to known
indicators), which can be given as absolute or
relative evaluations of software.
It should be emphasized that the boundary be-
tween metrics and reliability indicators of software
is quite difficult to draw. Reliability indicators
are primarily quantitative characteristics similar
to indicators used in classic reliability theory
(probability of no-failure, mean time before failure
and so on), while metrics are specific indicators
for software, which can evaluate reliability indi-
rectly or with respect to other products (reference
standards).
Next we will discuss metrics with consideration
of the more common second approach. It should
be noted that metrics can also give a quantitative
evaluation of any given property as well as require-
ments for software. In this case, by raw data, or
parameters (primitives) of metrics we mean the
initial quantitative values that are needed for their
calculation. The raw data can be other indicators
or metrics as well as different constants, coef-
ficients and so forth.
Software developer organizations should be
encouraged to use various metrics, because they
allow one to evaluate the level of quality and
reliability of software being developed and their
design processes, and also to discover existing
problems (for example, inadequate testing of
software, failure to follow the standards, ineffec-
tive work of individual groups of developers and
so forth) and to take the necessary measures to
solve them. Moreover, the need for calculation
and analysis of various metrics arises during
verification and validation of software, because
these processes must rely to a greater degree on
accurate quantitative evaluations, and not on
subjective opinion of developers or customers.
Basic standards that define metrics and se-
quence of their computing are:
• IEEE standard 982.1-1988 (IEEE, 1988,
a), which deines the list and order of reli-
ability metric calculations.
• IEEE standard 982.2-1988 (IEEE, 1988,
b), which clariies the sequence of using
the standard IEEE 982.1-1988.
• ISO/IEC standard 9126-1:1999 (ISO,
1999), which deines the software quality
model.
• Technical report ISO/TEC TR 9126-
2:2000 (ISO, 2000), which establishes the
basic nomenclature of external software
quality metrics, including metrics of reli-
ability, and deines basic principles of their
selection and evaluation.
• Ukrainian standard DSTU 2850-94 (DSTU,
1994), which repeats the basic principles
of the international standard ISO/IEC 9126
(ISO, 1999).
A quality model is presented in standard (ISO,
1999), according to which software is evaluated
with a set of internal, external and quality in use
metrics. In this case software quality is defined as
the total set of properties that determine software
capability to satisfy assigned requirements in ac-
cordance with its purpose.
The application area of external quality metrics
is validation and expert evaluation of the software.
The group of external quality characteristics and
Search WWH ::
Custom Search