Software of Safety Important I&C Systems - Nuclear Power Plant Instrumentation and Control Systems for Safety and Security - page 164

in the software requirement specification. For
reusable software an evaluation of the conformity
of functions implemented in the software to the
requirements is determined based on the context
of the intended usage.
The first of the listed tasks is universal in na-
ture and therefore can be partially or completely
formalized. To this end, general methodology
should be defined. Such methodology can include:
obtaining the normative profiles (requirements)
of the software; development (systematization,
profiling, selection) of parameters for evaluation
of characteristics (properties) of software and the
established requirements; analysis of the results
of evaluation and determination of the level of
satisfaction of the requirements established for
software; procedures (algorithms) of software
evaluation using different parameters.
The evaluation of software requires determi-
nation of the composition of the corresponding
characteristics and parameters, and also methods
of their evaluation. Software quality can be evalu-
ated by several characteristics, among which there
are functionality, reliability, usability and so forth.
The significance of each of these characteristics
depends on the area of software application. For
software systems that are important to safety a
determining characteristic is reliability.
Given the controversies regarding the under-
standing and use of the term “software reliability”
two existing approaches to its evaluation, which
conventionally are called “qualitative” and “quan-
titative,” can be considered.
The qualitative approach is used everywhere
and is oriented to a system (hierarchy) of require-
ments, i.e. profiles determined by standards,
industry regulations and normative documents
of companies, the fulfillment of which is checked
during software reliability evaluation. Results of
reliability evaluation in this case are formulated
in the form of the conclusions “corresponds” or
“does not correspond” for individual components,
which directly or indirectly affect reliability.

The quantitative approach to evaluation is
oriented to the development of models, that re-
ceive as input parameters characteristics of both
processes (development and verification) and
software itself, and gives as output the indicators
that characterize reliability (Lyu, 1996).
These indicators most frequently are analogues
of reliability indicators of equipment with the dif-
ference that such events as “component failures,”
are formulated as “manifestation of software
defects.” Moreover, special indicators (metrics)
are also used that determine the level of residual
defects, rate of their discovery during testing and
so forth.
Nevertheless, the instability of the manifesta-
tion of defects in sophisticated software systems
and their uniqueness do not allow one with high
degree of accuracy to determine quantitative values
of the characteristics of quality and reliability.
To solve this problem, the special methods of
analysis such as FTA (Fault Tree Analysis), RBD
(Reliability Block Diagram), FME(C)A (Failure
Modes, Effects (and Criticality) Analysis) and
others, can be used.
Metrics, indicators and raw data for evalua-
tion: There are different approaches to defining
of metrics and their relationship to the concepts
of software quality and reliability indicators
(Pressman, 1997).
The first approach (in accordance with the
IEEE standards (IEEE, 1990), (IEEE, 1988, a)
and (Pressman, 1997)) views this relationship on
the basis of the categories “absolute-relative” and
is based on the following definitions.
Absolute indicators (measures) are quantita-
tive indicators that characterize absolute values of
different attributes of software and the develop-
ment process (for example, the number of defects
discovered in each software module, the number
of lines of initial software text and so forth). In
this approach the metrics, in contrast to absolute
indicators, are intended especially for compari-
son of different software designs. For example,
comparison of two software applications based