BRITISH STANDARD BS IEC

60300-3-6:1997

Dependability
management —
Part 3: Application guide —

Section 6: Software aspects of

dependability

ICS 29.020
BS IEC 60300-3-6:1997

National foreword

This British Standard reproduces verbatim IEC 60300-3-6:1997 and

implements it as the UK national standard.
The UK participation in its preparation was entrusted by Technical Committee
DS/1, Dependability and tetrotechnology, to Subcommittee DS/1/1,
Dependability, which has the responsibility to:
— aid enquirers to understand the text;
— present to the responsible international/European committee any
enquiries on the interpretation, or proposals for change, and keep the UK
interests informed;
— monitor related international and European developments and
promulgate them in the UK.
A list of organizations represented on this subcommittee can be obtained on
request to its secretary.
From 1 January 1997, all IEC publications have the number 60000 added to
the old number. For instance, IEC 27-1 has been renumbered as IEC 60027-1.
For a period of time during the change over from one numbering system to the
other, publications may contain identifiers from both systems.
Cross-references
The British Standards which implement international or European
publications referred to in this document may be found in the BSI Standards
Catalogue under the section entitled “International Standards Correspondence
Index”, or by using the “Find” facility of the BSI Standards Electronic
Catalogue.
A British Standard does not purport to include all the necessary provisions of
a contract. Users of British Standards are responsible for their correct
application.
Compliance with a British Standard does not of itself confer immunity
from legal obligations.

Summary of pages
This document comprises a front cover, an inside front cover, pages i and ii,
the CEI IEC title page, page ii, pages 1 to 18 and a back cover.
This standard has been updated (see copyright date) and may have had
amendments incorporated. This will be indicated in the amendment table on
the inside front cover.

This British Standard, having Amendments issued since publication

been prepared under the
direction of the Management
Systems Sector Board, was
Amd. No. Date Comments
published under the
authority of the Standards
Board and comes
into effect on
15 January 1998

© BSI 05-1999

ISBN 0 580 29414 5

 BS IEC 60300-3-6:1997

Contents

Page
National foreword Inside front cover
Foreword ii
Introduction 1
1 Scope 2
2 Normative references 2
3 Definitions 2
4 Software aspects 2
5 Software life cycle phases and processes 3
6 Application of dependability programmes to products
containing software 3
7 Tailoring of dependability programmes 10
Annex A (informative) Typical relationship of product life
cycle phases and software life cycle phases 12
Annex B (informative) Selection of dependability programme
elements 13
Annex C (informative) Software life cycle processes 14
Annex D (informative) Association of the software life cycle
processes with the product life cycle phases 16
Annex E (informative) Cross-references between
IEC 60300-2 and ISO 9000-3 17
Annex F (informative) Bibliography 18

© BSI 05-1999 i
ii blank
BS IEC 60300-3-6:1997

Foreword
1) The IEC (International Electrotechnical Commission) is a worldwide organization for
standardization comprising all national electrotechnical committees (IEC National Committees).
The object of the IEC is to promote international co-operation on all questions concerning
standardization in the electrical and electronic fields. To this end and in addition to other activities,
the IEC publishes International Standards. Their preparation is entrusted to technical committees;
any IEC National Committee interested in the subject dealt with may participate in this
preparatory work. International, governmental and non-governmental organizations liaising with
the IEC also participate in this preparation. The IEC collaborates closely with the International
Organization for Standardization (ISO) in accordance with conditions determined by agreement
between the two organizations.
2) The formal decisions or agreements of the IEC on technical matters express, as nearly as possible,
an international consensus of opinion on the relevant subjects since each technical committee has
representation from all interested National Committees.
3) The documents produced have the form of recommendations for international use and are
published in the form of standards, technical reports or guides and they are accepted by the National
Committees in that sense.
4) In order to promote international unification, IEC National Committees undertake to apply IEC
International Standards transparently to the maximum extent possible in their national and
regional standards. Any divergence between the IEC Standard and the corresponding national or
regional standard shall be clearly indicated in the latter.
5) The IEC provides no marking procedure to indicate its approval and cannot be rendered
responsible for any equipment declared to be in conformity with one of its standards.
6) Attention is drawn to the possibility that some of the elements of this International Standard may
be the subject of patent rights. The IEC shall not be held responsible for identifying any or all such
patent rights.
International Standard IEC 60300-3-6 has been prepared by IEC technical
committee 56: Dependability.
The text of this standard is based on the following documents:

FDIS Report on voting

56/583/FDIS 56/600/RVD

Full information on the voting for the approval of this standard can be found in the
report on voting indicated in the above table.
Annex A, Annex B, Annex C, Annex D, Annex E and Annex F are for information
only.

ii © BSI 05-1999
 BS IEC 60300-3-6:1997

Introduction The availability performance of a product can be

affected by hardware failures, software faults, or
Dependability is the collective term describing the
human errors. Product malfunction causing
availability performance of a system or product. The
downtimes can be traceable to its internal design
availability performance is influenced by the
anomalies, or due to external interference including
reliability, maintainability and maintenance procedural errors. Product failures can arise from
support performance factors. In many systems and internal design faults relating to hardware or
products, reliability, maintainability, and
software problems. Failed hardware and worn-out
availability rank amongst the dominant
parts can be identified and isolated, repaired or
performance characteristics of importance to the
replaced to maintain the same level of product
users seeking cost-effective operation. Reliability
reliability. Unlike most physical hardware,
and maintainability are performance software, once created in the form of codes or
characteristics inherent to the product design. instructions, will not wear-out or deteriorate.
Maintenance support is external to the product
Hence, some of the software processes may be
itself, and will affect the quality of service.
different from those applicable for the hardware
Maintenance support performance reflects the
implementation. The intent of this application guide
ability of the maintenance organization to provide
is to relate the software life cycle processes with the
the necessary resources to sustain a level of product life cycle phases within the dependability
maintenance support effort to achieve availability management framework.
performance objectives.
Dependability management is defined in
A dependability programme must be tailored to the
IEC 60300-1. Dependability programme elements
product for effective application. The dependability
and tasks are specified in IEC 60300-2. This
programme should form part of the overall project
application guide complements IEC 60300-2 in
management programme for proper coordination terms of dependability programme implementation
with product development, manufacture, of systems or products containing software.
verification and deployment. Dependability
Emphasis is placed on the time-phase application of
programme elements and tasks should be consistent
relevant software activities associated with the
with the other support programmes such as quality
implementation of IEC 60300-2 as shown in
management, configuration management, data
Annex A. Annex B presents the selection of
collection etc. dependability programme elements associated with
The dependability management process includes the software life cycle phases.
project planning, specification, design analysis,
Efforts have been made to harmonize this
verification and validation, implementation,
application guide with ISO/IEC 12207 on software
evaluation, and data feedback of the product or
life cycle processes. An overview of the software life
service. Modern systems and products often contain
cycle processes is provided in Annex C.
software as a functional entity to achieve
Cross-references are identified in Annex D to
operational performance objectives. The software facilitate association of software life cycle processes
contained in the system or embedded in the product with relevant dependability elements and product
is subject to the dependability management process.
life cycle phases.
This application guide addresses the software
aspects of dependability. It provides specific The relationship of dependability (IEC 60300 series
guidance on the selection and application of of standards) and quality (ISO 9000 series of
relevant activities in dependability programmes standards) is addressed in IEC 60300-1/ISO 9000-4
associated with products containing software, or and will not be elaborated in this application guide.
systems configured by software with hardware However, the guidelines contained in ISO 9000-3 for
elements. application of ISO 9001 to software should be noted
in terms of quality factors influencing the
dependability characteristics of software elements.
Cross-references between IEC 60300-2 and
ISO 9000-3 are shown in Annex E.
A bibliography is provided in Annex F for additional
references to software aspects of dependability.

© BSI 05-1999 1
BS IEC 60300-3-6:1997

1 Scope In the application of a dependability programme to

a system or product, it is important to address the
This application guide complements IEC 60300-2
dependability issue from a system view point. A
and provides guidance for selection and application
product is an entity which may contain hardware or
of dependability elements and tasks with respect to
software components or both. A system is an
systems or products containing software. integrated composite entity, which may include the
This application guide is intended for use by project product, supply material, personnel, and related
managers, contract administrators, product support facilities and services. The system
designers, software developers, dependability environment defines the operating conditions and
specialists, quality specialists, support personnel interactions of the system components. The
and system maintainers who contribute to the availability performance of the system is measured
dependability of products or systems. or assessed to validate the achievement of stated
dependability objectives in terms of reliability,
2 Normative references maintainability, and maintenance support.
The following normative documents contain Dependability is a collective measure of the
provisions which, through reference in this text, performances of a system in its actual state of
constitute provisions of this section of IEC 60300-3. application or use, with or without the operation of
At the time of publication, the editions indicated specific software functions which may form part of
were valid. All normative documents are subject to an integrated system.
revision, and parties to agreements based on this It should be noted that software cannot function by
section of IEC 60300-3 are encouraged to itself but forms part of a system to provide specific
investigate the possibility of applying the most application. Software is a medium for realization of
recent editions of the normative documents a system performance objective. Software is
indicated below. Members of IEC and ISO maintain characterized in particular by its application
registers of currently valid International Standards. function, operating environment, size, language and
IEC 60050(191):1990, International complexity, installation and upgrade processes. The
Electrotechnical Vocabulary (IEV) — software aspects of dependability address the
Chapter 191: Dependability and quality of service. software components within a system in the context
IEC 60300-1/ISO 9000-4:1993, Dependability of dependability performance of the system. They do
management — Part 1: Dependability programme not address the quality of the software as a stand
management. alone item. Software quality is described in
ISO/IEC 9126 [1]1).
IEC 60300-2:1995, Dependability management —
Part 2: Dependability programme elements and The software aspects of dependability are associated
tasks. with the integrity of the software component in
system operation. Integrity is an inherent design
IEC 61160:1992, Formal design review.
attribute associated with risk containment. Risk is
Amendment 1 (1994)
an undesirable exposure or threat associated with
ISO 8402:1994, Quality management and quality the system operation. Risk is characterized by its
assurance — Vocabulary. probability of occurrence and its impact or
consequence of the event outcome. The ability of a
3 Definitions system and its software component to contain risk is
For the purpose of this section of IEC 60300-3, the dependent on the system architecture, fault tolerant
terms and definitions of IEC 60050(191) and design, and the degree of rigour in the application of
ISO 8402 apply. relevant methods to the software. The integrity
level is the assigned risk associated with the system
4 Software aspects operation which is to be contained. The relationship
between dependability and integrity is closely
The software aspects of dependability deal with the linked by the criticality of software application
specific software issues in the establishment and associated with the assigned integrity levels when
implementation of a dependability programme for a dealing with the software affecting system
system or product containing software. Emphasis is performance.
placed on achieving dependability in the product
design and performance objectives in reliability,
maintainability and maintenance support.

1) Figures in square brackets refer to the bibliography given in Annex F.

2 © BSI 05-1999
 BS IEC 60300-3-6:1997

5 Software life cycle phases and 6 Application of dependability

processes programmes to products containing
The life cycle of software is very much intertwined software
with the life cycle of its parent system. A typical 6.1 General
relationship of the software life cycle phases and the
The guidance given in IEC 60300-2 provides a basis
conventional product life cycle phases in accordance
for dependability programmes for products
with IEC 60300-1/ISO 9000-4 is shown in Annex A.
including those containing software. This standard
An example for the selection of dependability
does not duplicate the basic requirements described
programme elements associated with the software
in IEC 60300-2 but identifies additional task
life cycle phases is presented in Annex B.
requirements relevant to software aspects of
A software life cycle process is a set of planned dependability, to complement IEC 60300-2.
activities or tasks performed accordingly to achieve Guidance is provided on the selection and
a stated goal or objective of a software project. The application of dependability tasks for formulating
process involves activities pertaining to a software and implementing specific dependability
product from its conception to the termination of its programmes of products containing software. The
use. Detailed information is contained in following subclauses correspond to the project or
ISO/IEC 12207 [2]. Annex C provides informative product specific dependability programme elements
notes on the software life cycle processes. and tasks described in IEC 60300-2 to facilitate
Annex D shows the association of software life cycle cross-referencing.
processes in a typical dependability programme. 6.2 Planning and management
IEC 60300-2 describes the various elements of a
dependability programme in terms of product life 6.2.1 Dependability plans
cycle phases. The software life cycle processes do not Dependability plans should be established in
always relate directly to the product life cycle. The accordance with 6.1.1 of IEC 60300-2.
process relationships with respect to time are only A dependability plan for a system or product
approximate as considerable variation may occur containing software should be an integrated plan
between different software projects. For example, in that shows the relevant dependability tasks
some cases software release has to occur before applicable to the system or product, and its
hardware product manufacturing can start. constituent hardware and software components.
However, the relevant dependability elements and The dependability plan should form part of the
tasks are incorporated here to illustrate the essence overall project management plan.
of time-phase applications in dependability
Planning for software aspects of dependability
programmes. This time-phase representation
should take into consideration:
provides a useful framework for integrating
software elements into a hardware system or — the system or product requirements pertaining
product. to the software contained in the system or
product;
There are related dependability and quality
activities associated with the implementation of a — specific contract requirements affecting the
software project or programme. Annex E provides delivery targets and deployment schedule of the
cross-referencing of IEC 60300-2 dependability software involved;
programme elements and tasks to ISO 9000-3 [3]. — the criticality of the software function affecting
system or product performance in actual
operating environment;
— the feasibility of reusing pre-developed
software or off-the-shelf software products;
— timing and resources for the software
development if required by the project;
— functional interface of the software involved;
— documentation requirements;
— software test and system integration
requirements;
— software maintenance support requirements;
— software update and release requirements.

© BSI 05-1999 3
BS IEC 60300-3-6:1997

6.2.2 Project decision management There are two aspects related to the function and
Project decision management should be conducted responsibility of the management representative;
in accordance with 6.1.2 of IEC 60300-2. one is at the organizational level, the other is at the
project level.
The management of a software project should be an
integral part of the overall project management for The management representative at the
the system or product containing the software. organizational level is responsible for the quality
Milestone objectives related to software should system implementation within the organization.
reflect a coordinated set of deliverables at scheduled This is in conformance with the ISO 9000 quality
targets to facilitate project decision at management management standards. Dependability as a specific
reviews. technical discipline contributes to the
organizational infrastructure in terms of value
6.2.3 Traceability management added dependability management principles and
Traceability management should be in accordance practices. The dependability effort within the
with 6.1.3 of IEC 60300-2. organization enhances the overall effectiveness of
Traceability of software development and support the quality system. Where necessary, the
efforts, functional test data, software release management representative may seek technical
schedules, and field performance data of the product assistance from other quality and dependability
or service deliverables should reflect the specialists for resolution of generic or systemic
requirements stipulated in the overall issues related to the quality system at the
dependability plan. Relevant records pertaining to organization level. A typical position in an
software activities should be maintained along with organization for the management representative is
other project activities to facilitate source the quality director, manager, or administrator.
identification and data correlation for tracking root The management representative at the contract or
cause problems. project level deals with the specific issues related to
6.2.4 Configuration management contract delivery of the product or system. The
management representative is responsible for
Configuration management should be in accordance interfacing with the customer and suppliers of a
with 6.1.4 of IEC 60300-2. specific project by ensuring the quality and
A configuration management plan should be dependability of the deliverables. The management
established and implemented for the software representative at the project level should have
project. This plan is used for identification, control, adequate knowledge concerning the specific project
status accounting, evaluation, change management, involved. Where necessary, technical experts may
release management and delivery of the software be sought to resolve project or contract related
involved in the overall project. problems. A typical position for the management
Software configuration management should be a representative in a project is the project manager,
functional deliverable item as part of the system or principal or lead engineer.
product configuration management plan of the 6.4 Dependability requirements
overall project.
6.4.1 Specification of dependability
6.3 Contract review and liaison requirements
6.3.1 Contract review Specification of dependability requirements should
Contract review should be in accordance with 6.2.1 be in accordance with 6.3.1 of IEC 60300-2.
of IEC 60300-2. Specification of dependability requirements for
Specific issues concerning the software involved in a software should consider:
contract should be reviewed in conjunction with the — operating environment of the system or
overall project review process. Specific contract product containing the software and affecting the
requirements pertaining to the software functional requirements of the software;
deliverables are reviewed with the customer for — the criticality of the software application in the
acceptance and, where applicable, with the system or product to achieve the overall
suppliers of subcontract items. Where discrepancies availability performance objective;
occur, the specific issues should be resolved and the
— permissible downtime duration and outage
contract amended to reflect the latest status.
frequency allocated or contributed by software
Contract review records should be maintained.
problems in relation to the overall system
6.3.2 Management representative downtime;
Management representatives should be selected in — software diagnostic and test coverage
accordance with 6.2.2 of IEC 60300-2. requirements;

4 © BSI 05-1999
 BS IEC 60300-3-6:1997

— software qualification and acceptance 6.5.2 Maintainability engineering

requirements; Maintainability engineering should be in
— software test and system integration accordance with 6.4.2 of IEC 60300-2.
requirements; Maintainability engineering effort applicable to
— software documentation requirements; software is associated with the degree of
— software configuration management engineering rigour in the application of relevant
requirements; methods.
— software release and update requirements; 6.5.3 Maintenance support engineering
— software maintenance requirements. Maintenance support engineering should be in
6.4.2 Requirements interpretation accordance with 6.4.3 of IEC 60300-2.
Requirements interpretation should be in It should be noted that all software maintenance
effort is in response to discovered errors in the
accordance with 6.3.2 of IEC 60300-2.
software design, changes to the software application
The requirements interpretation should requirements, or the perfective maintenance of the
distinguish: software (software enhancement) to reduce a
a) those requirements affecting the overall shortcoming in the software implementation rather
system or product performance; than reacting to a system failure occurrence.
b) those requirements related to the intended use 6.5.4 Testability engineering
or application of the software.
Testability engineering should be in accordance
The list of dependability requirements provided with 6.4.4 of IEC 60300-2.
in 6.4.1 is not exhaustive. There may also be
The engineering effort to ensure software testability
differences in the requirements interpretation when
includes:
the same basic software is used in a system or
product for different applications or operating in — design specifications for testability;
separate environments. — test methods and standards;
6.4.3 Requirements allocation — test coverage of the software component;
Requirements allocation should be in accordance — test coverage of system requirements;
with 6.3.3 of IEC 60300-2. — software integration and testing for
Emphasis should be placed on the allocation of conformance.
dependability requirements in accordance with the Testability is the extent to which an objective and
system structure. Mapping of the dependability of feasible test can be designed into the software to
requirements onto the system architecture determine whether a requirement is met. Test
consisting of hardware and software components is coverage is the extent to which the test cases are
a key process. This top down approach provides a developed to test the system or the software
means to allocate proper resources relevant to the components for conformance to established
total system requirements. It facilitates functional requirements.
design trade-off, permits rationalization of It should be noted that the purpose of testing during
make/buy decisions, and allows planning and software development is to find faults within the
implementation of the appropriate level of effort or software components. The purpose of diagnostic
the degree of engineering rigour required in the testing during software maintenance is to
development, acquisition, or support of the software determine the root cause of an identified system
for various levels of critical applications. failure or malfunction.
6.5 Engineering 6.5.5 Human factors engineering
6.5.1 Reliability engineering Human factors engineering should be in accordance
Reliability engineering should be in accordance with 6.4.5 of IEC 60300-2.
with 6.4.1 of IEC 60300-2.
Reliability engineering effort applicable to software
is associated with the degree of engineering rigour
in the application of relevant methods.
Reliability contribution of software components to a
system or product containing the software is highly
dependent on the development process and the
design of the software.

© BSI 05-1999 5
BS IEC 60300-3-6:1997

Human factors have significant impact on system — integration and test requirements;
performance. The level of engineering effort relates — a review process in case of host system failures
directly to the planning, design and execution of the traceable to customer-provided software faults;
software involved in system operation. Design
— configuration management requirements.
guidelines and standards should be used to ensure
consistency in software design to facilitate 6.7 Analysis, prediction and design review
testability and integration. Documented test cases 6.7.1 General
and test procedures should be extended to include
Software analysis methodology in general is based
human factor elements relating to the operation and
on practical experience and test data with specific
maintenance of the software to ensure that the
software applications and associated operating
overall dependability requirements of the system
are met. environments. Software performance models,
including those that emulate reliability
Depending on the criticality of system application, performance of software systems, are being
the level of human engineering effort required formulated for reliability prediction and reliability
should be consistent with the project application. growth assessment purposes. These models
The potential impact on its immediate environment represent the mathematical functions relating to
in case of a system malfunction due to human error specific software performance parameters to
should be explored. Human engineering effort provide a quantitative output using the engineering
applicable to software is associated with the degree data input. Hence these software performance
of engineering rigour in the application of relevant models are application specific.
methods.
There are no generic models or standards for
6.6 Externally provided products software analysis and evaluation that will meet all
6.6.1 Subcontracted products application requirements and contract situations.
However, there are numerous industry best
Requirements dealing with subcontracting and
practices developed for specific software analysis
subcontracted products should be considered in
such as:
accordance with 6.5.1 of IEC 60300-2.
— software complexity analysis to estimate the
The following issues may be applicable to
fault content in a given set of software modules;
subcontracted software products for integration into
the host system: — analysis of code coverage to determine test
completeness;
— subcontracting complete development of the
software component or subsystem; — correlation of software defects classification for
rapid root cause analysis and in-process
— acquisition or out-sourcing of off-the-shelf
improvement.
software packages;
The following subclauses present the standard
— subcontracting for modification of existing
methods identified in IEC 60300-2.
software.
Where applicable, the dependability requirements 6.7.2 Fault mode and effects analysis
of the host system should be reflected in the Fault mode and effects analysis (FMEA) [4] should
subcontract statement of work. Subcontract plans be conducted, where applicable, in accordance
should include schedule and milestone deliverables, with 6.6.1 of IEC 60300-2.
supplier monitoring, contract reviews, FMEA [4] applicable to software systems should be
documentation, acceptance criteria and software dealt with at the architectural design level and
maintenance support requirements. cascaded down to the functional level as appropriate
6.6.2 Customer-provided products for critical applications. At the functional level the
software component is treated as a black box. The
Customer-provided products should be considered
effect of a software fault should be analysed to
in accordance with 6.5.2 of IEC 60300-2.
determine its criticality to the system operation.
Customer-provided software products may be Where applicable, quantitative assessment should
existing software products or a subsystem needed be conducted to determine the failure impact for
for integration and operation with the host system design trade-off and system performance
under contract for delivery. The following improvement.
requirements should be considered:
Examples of software fault modes may include:
— specifications of the customer-provided
— a wrong output is provided for a correct input;
software product or subsystem;
— an incorrect input is not recognized;
— interface requirements;

6 © BSI 05-1999
 BS IEC 60300-3-6:1997

— the software is corrupted indicating a Predictions associated with software products

significant functional error; should consider the application environment,
— an infinite loop occurs and no output at all is operating load and complexity, architecture of
provided by the software function; system configuration, and the empirical data used
to base the reliability performance predictions of the
— no output is supplied within the required time
software products.
interval.
There are three generic approaches towards
6.7.3 Fault tree analysis prediction methods for software. The first is based
Fault tree analysis (FTA) [5] should be conducted, on the software development process properties.
where applicable, in accordance with 6.6.2 of The second is based on the software product
IEC 60300-2. characteristics. The third is based on empirical data
FTA is applicable to software at the functional level gathered from verification processes and actual
where the dependency of the software component in operation of the software.
the overall system performance may be assessed. Prediction models derived from software
FTA is a top down system approach to determine development process properties are influenced by
whether the probability of a lower system branch the process parameters. The concept is that the
containing the software component is critical. management disciplines used for software
FTA could also be conducted in conjunction with development could provide reliability projection
other analysis techniques as appropriate for targets for the software. In this respect, the process
determining the reliability performance of the parameters are used as benchmarks for reliability
software function for operation of critical systems. improvement.
The results of FTA and FMEA could be qualitative Prediction models derived from software product
or quantitative or both. However, it should be noted characteristics are influenced by the software
that most FMEA and FTA performed to date on product parameters such as form, structure and
software are qualitative. complexity of the software. Reliability prediction
6.7.4 Stress and load analysis based on such models is generally used for
off-the-shelf software product evaluation and
Stress and load analysis should be conducted, where comparative analysis.
applicable, in accordance with 6.6.3 of IEC 60300-2.
Prediction models derived from software
In the context of software application, stress and performance data are influenced by the specific
load analysis is associated with the speed and application and operating environment of the
capacity for the software function to process software. Statistical methods are used for reliability
information throughput. There are no specific prediction to estimate reliability growth projection
methods or standards established for stress and based on observed data.
load analysis for software.
Prediction methods for software are still evolving.
6.7.5 Human factors analysis Existing methodologies and models are very much
Human factors analysis should be conducted, where product specific and application oriented. There are
applicable, in accordance with 6.6.4 of IEC 60300-2. no standard methods available for generic
Human factors analysis is a technical discipline application of reliability prediction for software. At
which determines the effects of human errors this point, reliability contribution from software
affecting the design, analysis, execution and components within a system is mostly estimated,
maintenance of the software product or system. based on observed system performance data
There are no specific standards established for containing the software.
human factors analysis for software. However, in 6.7.7 Trade-off analysis
the application of FMEA, FTA, risk analysis and Trade-off analysis should be conducted, where
other applicable techniques, the human factors applicable, in accordance with 6.6.6 of IEC 60300-2.
element could be considered as input for the
assessment of dependability performance of systems
containing software.
6.7.6 Predictions
Predictions should be conducted, where applicable,
in accordance with 6.6.5 of IEC 60300-2.

© BSI 05-1999 7
BS IEC 60300-3-6:1997

By treating software components as functions For software it is important to confirm that the
within a system or product containing software, needs and expectations for the software are
conventional methods such as FMEA and FTA could understood. For high risk applications where
be effectively used for design trade-off, make/buy significant resources are being expended on the
decisions, and comparative analysis for alternate software, it is essential that necessary actions be
solutions. Trade-off analysis is used for decision taken to validate the user expectations of the
making to select an appropriate software approach, software or the system containing software. Some
an alternate hardware approach, or a combined examples of such actions are:
hardware and software solution in the design — the use of simulations to understand
architecture to achieve system performance to meet performance expectations;
cost-effective project requirements.
— the use of prototypes to clarify the user
6.7.8 Risk analysis interactions with the software;
Risk analysis should be conducted, where — the use of formal models to clarify the
applicable, in accordance with 6.6.7 of IEC 60300-2. functionality of the proposed software.
IEC 60300-3-9 [6] should be used as a reference for Activities associated with the validation of software
conducting risk analysis. should include:
6.7.9 Formal design review — preparation of selected test requirements, test
Formal design review should be conducted in specifications and test cases for analysis of test
accordance with 6.6.8 of IEC 60300-2. results;
IEC 61160 should be used as guidance to conduct — ensuring test requirements reflect the
formal design review. intended use of the software;
6.8 Verification, validation and test — testing;
— analysis of test results for conformity.
6.8.1 Verification, validation and test
planning Examples of software analysis and review include
techniques such as code inspection, walk through,
Verification, validation and test planning should be formalised descriptions, symbolic executions,
conducted in accordance with 6.7.1 of IEC 60300-2. programme proving, etc. Examples of software
Verification is the confirmation by examination and verification and validation testing include
provision of objective evidence that specified techniques such as black box, white box, load
requirements have been fulfilled. In design and testing, statistical testing, reliability growth
development of software, verification concerns the testing, etc.
process of examining the result of a given activity to Test planning includes all applicable verification
determine conformity with the stated requirement and validation activities for the specific software
for that activity. under contract. Test planning should be part of the
Activities associated with the verification of overall project plan.
software should include:
6.8.2 Life testing
— contract verification;
Life testing is a hardware activity and not
— process verification; applicable to software as a stand alone entity.
— requirements verification; However, life testing is applicable for life evaluation
— design verification; of products containing combined hardware and
software where the software is incorporated to serve
— code verification;
as a functional component.
— integration verification;
6.8.3 Dependability testing
— documentation verification.
Dependability testing should be conducted in
Validation is the confirmation by examination and accordance with 6.7.3 of IEC 60300-2.
provision of objective evidence that the particular
requirements for a specific intended use are Testing related to the evaluation, demonstration
fulfilled. Validation is normally performed on the and acceptance of the availability performance of
final product under defined operating conditions. the system containing software should be conducted
in conjunction with other test activities, where
applicable to the project. The data collected should
provide adequate information for analysis to
determine the availability performance of the
system for dependability acceptance.

8 © BSI 05-1999
 BS IEC 60300-3-6:1997

6.8.4 Reliability growth testing 6.10 Operation and maintenance support

Reliability growth testing should be conducted in planning
accordance with 6.7.4 of IEC 60300-2. 6.10.1 Maintenance support planning
IEC 61014 [7] provides guidance for development of Maintenance support planning should be in
reliability growth programmes and procedures. accordance with 6.9.1 of IEC 60300-2.
IEC 61164 [8] provides methodology for reliability Planning for software maintenance support
growth testing and estimation. includes estimation of maintenance effort and
Specific reliability growth models applicable to assignment of tasks and responsibilities for
software consist of the following elements: scheduled and unscheduled software release,
— a representation of the failure process by a set software update or modification, and perfective
of mathematical formulae incorporating certain maintenance for software enhancement.
parameters; Maintenance support plans should form part of the
overall project support plan. Logistics support,
— a method of estimating the parameters by
analysis of previous failure data; including resource allocation, facility and
equipment deployment, documentation, and
— a method of combining the estimated training of personnel, should also be considered as
parametric values with the formulae to obtain part of the planning effort.
numerical estimates of reliability measures.
6.10.2 Installation
6.8.5 Production testing
Installation should be in accordance with 6.9.2 of
Production testing should be conducted in IEC 60300-2.
accordance with 6.7.5 of IEC 60300-2.
Software installation is the execution of the project
Production testing is usually applicable to hardware plan for software delivery and installation in the
products and to systems containing both hardware system on site, final acceptance and commissioning
and software components as part of a of the software to operate in the system in its actual
manufacturing process. Production testing is not environment. In this respect, the software code and
applicable to testing software as a stand alone item. databases are initialized, the test routines are
6.8.6 Acceptance testing executed and terminated as specified in the contract
Acceptance testing should be conducted in specification and test plan. The installation events
accordance with 6.7.6 of IEC 60300-2. and results should be documented to facilitate
follow-up actions.
Acceptance testing is associated with software
verification and validation. There are three levels of 6.10.3 Support services
testing of software for acceptance: Support services should be in accordance with 6.9.3
a) testing of each software unit or component to of IEC 60300-2.
ensure conformance to established specifications Support services for software include the continuous
or standards; support activities for the maintenance and upgrade
b) testing of integrated software units and of the software in an operating system. Support
components as an aggregate; this is generally services may be performed by the supplier of the
known as integration testing; software, or they may be performed by contracting
to a third party, or they may be performed by the
c) testing of the software installation for final
users of the software with proper instructions. In all
acceptance and commissioning to ensure that the
cases, training of support personnel is crucial to the
software works in the system configured to
success of the support services.
operate in actual environment and established
conditions as specified in the contract. 6.10.4 Support engineering
6.8.7 Reliability stress screening Support engineering should be in accordance
with 6.9.4 of IEC 60300-2.
Reliability stress screening in accordance with 6.7.7
of IEC 60300-2 is applicable to hardware products. Support engineering is the engineering effort, the
It is not applicable to software. knowledge and skills required by the support
personnel to fulfil the requirement in performing
6.9 Life cycle cost programme
the support services.
Life cycle cost programme should be in accordance 6.10.5 Spares provisioning
with 6.8 of IEC 60300-2.
Spares provisioning is a hardware activity and not
Software life cycle cost should be treated as a cost
applicable to software.
element in the product or system life cycle cost
programme.

© BSI 05-1999 9
BS IEC 60300-3-6:1997

6.11 Improvements and modifications Data analysis is essential to provide availability

6.11.1 Improvement programmes performance trends and to identify anomalies for
initiation of corrective or preventive action, as
Improvement programmes should be in accordance appropriate. Analysis of software data derived from
with 6.10.1 of IEC 60300-2. test cases, test results, field performance data or
Improvement of software is related to software from other relevant sources could provide valuable
maintenance. Examples of improvement insights and information such as monitoring
programmes related to software could be an reliability growth, maturity indication for software
upgrade of the software features to provide more release and systemic problems for root cause
storage capabilities, or the simplification of analysis. The objective for data analysis should be
administrative or documentation procedures to clearly stated in the project plan. All analysed data
achieve cost-effective operations. should be interpreted and reviewed for
In all cases, event data should be maintained to management decisions and follow-up actions to
provide indications of improvement trends. effect the continuous improvement process.
Corrective and perfective maintenance for software
improvement should be considered in the
7 Tailoring of dependability
maintenance process as identified in Annex C. programmes
6.11.2 Modification control Tailoring is a process for matching the requirements
to meet a specific project objective.
Modification control should be in accordance
with 6.10.2 of IEC 60300-2. The criteria set forth in clause 5 of IEC 60300-2
should form the basis for the tailoring process.
Software modification control should conform to the
established software configuration management The general tailoring process activities include:
process where appropriate administrative and — identification of the project environment
technical procedures are applied. This is to identify, reflecting the organizational policy and
record, and report on the status of the modification infrastructure;
to ensure its completeness, consistency and — analysis of the contract requirements,
correctness for maintenance of continuous service criticality and impact of the deliverables,
quality and effectiveness. capability and resources available for project
Modification control resulting from corrective and implementation;
perfective maintenance for software should be — selection of applicable dependability elements
considered in the configuration management and tasks relevant to the project;
process as identified in Annex C. — documenting the rationale in formalising the
6.12 Experience feedback tailoring decisions as part of the project plan.
6.12.1 Data acquisition The following provides additional information to
Data acquisition should be in accordance facilitate tailoring of dependability programmes
with 6.11.1 of IEC 60300-2. applicable to systems or products containing
software.
Data acquisition should focus on data collection of
product or system performance, primarily from field Annex B provides general guidance for the principal
operation and experience feedback from users. (first level) selection and implementation of
Results from test cases and software verification relevant dependability programme elements for
and validation should be included as part of the specific products containing software. The selection
data. The data collection system should be simple process takes into consideration:
and adequate to provide the essential data — the product life cycle phases applicable to the
necessary for analysis of availability performance. project;
In an ideal situation, the raw data associated with — the dependability elements relevant to that
hardware failures, software faults, and procedural part of the product life cycle phases;
errors should be easily segregated for further
— the associated software life cycle processes
analysis. Hence, the design of the data acquisition
related to the dependability elements identified;
procedure and data collection system should be
considered. — the specific software process activities selected
for project implementation.
6.12.2 Data analysis
Data analysis should be in accordance with 6.11.2 of
IEC 60300-2.

10 © BSI 05-1999
 BS IEC 60300-3-6:1997

The association of the software life cycle processes

with the product life cycle phases is presented in
Annex D. This annex also cross-references the
respective dependability programme elements and
tasks applicable to products containing software
according to clause 6 of IEC 60300-2, and the
dependability management elements and project
generic elements according to
IEC 60300-1/ISO 9000-4. The respective software
life cycle processes are used to identify software
specific activities for further tailoring and
refinement (second level) in project task
implementation.
Annex C provides explanatory notes on the software
life cycle processes. Each applicable process
contains a set of specific activities for software
project implementation. The tailoring process
requires further refinement (second level) in the
selection and mapping of the appropriate software
process activities into the dependability programme
when software components are involved. Detailed
information on specific software process activities is
included in ISO/IEC 12207 [2].
Cost consideration should be given when tailoring a
dependability programme to meet specific project
objectives. Dependability effort selected for
programme implementation should be rationalized
to ensure that the selected activities add value.

© BSI 05-1999 11
BS IEC 60300-3-6:1997

Annex A (informative)
Typical relationship of product life
cycle phases and software life
cycle phases

NOTE This chart shows the relationship of the software life cycle phases and the conventional product life cycle phases in a typical
time-phase representation applicable to dependability programmes.

12 © BSI 05-1999
 BS IEC 60300-3-6:1997

Annex B (informative)
Selection of dependability programme
elements

Dependability programme elements

(IEC 60300-2)

6.9 Operation and maintenance support planning

6.6 Analysis, prediction and design review

6.10 Improvement and modifications

6.7 Verification, validation and test
6.5 Externally provided products
6.3 Dependability requirements
6.2 Contract review and liaison

6.8 Life cycle cost programme

6.1 Planing and management

6.11 Experiences feedback

6.4 Engineering
Product life cycle Software life cycle phases
phases

Concept and Requirements analysis X X X X X X X X X X

definition
System specification X X X X X X X X X X
High-level design X X X X X X X X X X
Design and
Detailed design X X X X X X X X X X X
development
Coding and unit test X X X X X X X X X X X
Integration test X X X X X X X X X X
Manufacturing and System test X X X X X X X X X X
installation Acceptance test X X X X X X X X X X
Software release X X X X X X X X X X
Operation and
maintenance Software maintenance X X X X X X X X X X
and enhancement
Disposal Software retirement X X
NOTE This chart presents a typical association of the software life cycle phases and the applicable dependability programme
elements for first level task identification in the tailoring process as described in clause 7.

© BSI 05-1999 13
BS IEC 60300-3-6:1997

Annex C (informative) c) The development process defines the

Software life cycle processes activities of the developer, that is the
organization that defines and develops the
C.1 General software product. The development process
Software life cycle processes are described in activities include:
ISO/IEC 12207 [2]. These processes apply to the — development process implementation;
acquisition of systems, software products and
— system requirements analysis;
services. They are applicable to the supply,
development, operation and maintenance of — system architectural design;
software products. A software product is a set of — software requirements analysis;
computer programs, procedures, and associated — software architectural design;
documentation and data. A process is a set of
interrelated activities, which transform inputs into — software detailed design;
outputs, in the context of process implementation — software coding and testing;
and throughput. — software integration;
The following provides an overview of the software — software qualification testing;
life cycle processes to facilitate their association — system integration;
with dependability programme elements and tasks.
— system qualification testing;
The software life cycle processes are grouped into:
— software installation;
a) primary life cycle processes;
— software acceptance support.
b) supporting life cycle processes;
d) The operation process defines the activities
c) organizational life cycle processes. of the operator, that is the organization that
C.2 Primary life cycle processes provides the service of operating a software
The primary life cycle processes are those processes system in its live environment for its users. The
that serve the primary parties who initiate or operation process activities include:
perform in the development, operation or — operation process implementation;
maintenance of software products. These primary — operational testing;
parties are the acquirer, the supplier, the developer,
the operator, and the maintainer of software — system operation;
products. There are five primary life cycle processes. — user support.
a) The acquisition process defines the e) The maintenance process defines the
activities of the acquirer, that is the organization activities of the maintainer, that is the
that acquires a system, software product or organization that provides the service of
software service. The acquisition process maintaining the software product; it consists in
activities include: managing modifications to the software product
— initiation of the acquisition; to keep it current and in operational fitness. The
maintenance process activities include:
— request for proposal or tender preparation;
— maintenance process implementation;
— contract preparation and update;
— problem and modification analysis;
— supplier monitoring;
— modification implementation;
— acceptance and completion.
— maintenance review/acceptance;
b) The supply process defines the activities of
the supplier, that is the organization that — migration from old operating environment
provides the system, software product or software to new operating environment;
service to the acquirer. The supply process — software retirement.
activities include:
— initiation of the supply process;
— preparation of response;
— contract;
— planning;
— execution and control;
— review and evaluation;
— delivery and completion.

14 © BSI 05-1999
 BS IEC 60300-3-6:1997

C.3 Supporting life cycle processes e) The validation process defines the activities
The supporting life cycle processes are those for validating the software products of the
processes that, individually, each supports another software project. The validation process activities
process and forms an integral part with the process include:
it supports. A supporting process is employed and — implementation of the validation process;
executed, as needed, by another process. A — performing validation by means of test cases
supporting process has its specific application and and analysis of test results.
purpose. It contributes to the success and quality of
f) The joint review process defines the
the overall software project. There are eight
activities for evaluating the status and products
supporting life cycle processes.
of an activity. The joint review process activities
a) The documentation process defines the include:
activities for recording the information produced
— implementation of the joint review process;
by a life cycle process. The documentation process
activities include: — project management reviews;
— documentation process implementation; — technical reviews.
— design and development of the documents; g) The audit process defines the activities for
determining compliance with the requirements,
— production of the documents;
plans and contract. The audit process activities
— maintenance of the documents. include:
b) The configuration management process — implementation of the audit process;
defines the configuration management activities
— conducting the audit.
on the administration and control of the baseline
software items in a system for their release or h) The problem resolution process defines a
modification. The configuration management process for analyzing and resolving the problems
process activities include: discovered during software development,
operation, and maintenance. The problem
— configuration management process
resolution process activities include:
implementation;
— implementation of the problem resolution
— configuration identification;
process;
— configuration control;
— problem resolution.
— configuration status accounting;
C.4 Organizational life cycle processes
— configuration evaluation;
The organizational life cycle processes are employed
— release management and delivery. by an organization to establish and implement an
c) The quality assurance process defines the underlying infrastructure, which is made up of
activities for objectively assuring that the associated life cycle processes, customer focus,
software products and processes are in management leadership, facilities and personnel,
conformance with their specified requirements for continuous improvement of the infrastructure
and adhere to their established plans. The and processes. There are four organizational life
quality assurance process activities include: cycle processes.
— quality assurance process implementation; a) The management process defines the basic
— product assurance; activities of the management, including project
management, during a life cycle process. The
— process assurance;
management process activities include:
— assurance of quality systems.
— initiation and scope definition;
d) The verification process defines the
— planning;
activities for verifying the software products of
the software project. The verification process — execution and control;
activities include: — review and evaluation;
— implementation of the verification process; — closure.
— conducting contract verification, process b) The infrastructure process defines the
verification, requirements verification, design basic activities for establishing the underlying
verification, code verification, integration structure of a life cycle process. The
verification, and documentation verification as infrastructure process activities include:
appropriate to the software project. — implementation of the infrastructure
process;

© BSI 05-1999 15
BS IEC 60300-3-6:1997

— establishment of the infrastructure; d) The training process defines the activities

— maintenance of the infrastructure. for providing adequately trained personnel. The
training process activities include:
c) The improvement process defines the basic
activities that an organization performs for — process implementation;
establishing, measuring, controlling and — training material development;
improving its life cycle process. The improvement — training plan implementation.
process activities include:
— improvement process establishment; Annex D (informative)
— process assessment; Association of the software life cycle
— process improvement. processes with the product life cycle
phases

16 © BSI 05-1999
 BS IEC 60300-3-6:1997

Annex E (informative)
Cross-references between IEC 60300-2
and ISO 9000-3

Subclause in IEC 60300-2 Subclause in ISO 9000-3

6.1.1 Dependability plans 4.2, 5.4, 5.5
6.1.2 Project decision management 4.1
6.1.3 Traceability management 4.1
6.1.4 Configuration management 6.1
6.2.1 Contract review 5.2
6.2.2 Management representatives 4.1
6.3.1 Specification of dependability requirements 5.3
6.3.2 Requirements interpretation 5.3
6.3.3 Requirements allocation 5.3, 5.6
6.4.1 Reliability engineering 5.6
6.4.2 Maintainability engineering 5.6
6.4.3 Maintenance support engineering 5.6
6.4.4 Testability engineering 5.7
6.4.5 Human factors engineering 5.6, 5.7
6.5.1 Subcontracted products 6.7, 6.8
6.5.2 Customer-provided products 6.7, 6.8
6.6.1 Fault mode and effects analysis 6.5, 6.6
6.6.2 Fault tree analysis 6.5, 6.6
6.6.3 Stress and load analysis 6.5, 6.6
6.6.4 Human factors analysis 6.5, 6.6
6.6.5 Predictions 6.5, 6.6
6.6.6 Trade-off analysis 6.5, 6.6
6.6.7 Risk analysis 6.5, 6.6
6.6.8 Formal design review 5.5, 5.6, 6.1, 6.2, 6.3
6.7.1 Verification, validation and test planning 6.4
6.7.2 Life testing 5.7
6.7.3 Dependability testing 5.7, 5.8, 6.4
6.7.4 Reliability growth testing 5.7, 5.8, 6.4
6.7.5 Production testing 5.7, 5.8, 6.4
6.7.6 Acceptance testing 5.7, 5.8, 6.4
6.7.7 Reliability stress screening 5.7, 5.8, 6.4
6.8 Life cycle cost programme 4.2
6.9.1 Maintenance support planning 5.10
6.9.2 Installation 5.9
6.9.3 Support services 5.9, 5.10, 6.9
6.9.4 Support engineering 5.9, 5.10
6.9.5 Spares provisioning 5.9
6.10.1 Improvement programmes 4.3, 4.4
6.10.2 Modification control 4.3, 4.4
6.11.1 Data acquisition 6.2, 6.3
6.11.2 Data analysis 6.2, 6.3

© BSI 05-1999 17
BS IEC 60300-3-6:1997

Annex F (informative)
Bibliography
[1] ISO/IEC 9126:1991, Information technology — Software product evaluation — Quality characteristics
and guidelines for their use.
[2] ISO/IEC 12207:1995, Information technology — Software life cycle processes.
[3] ISO 9000-3:1991, Quality management and quality assurance standards — Part 3: Guidelines for the
application of ISO 9001 to the development, supply and maintenance of software.
[4] IEC 60812:1985, Analysis techniques for system reliability — Procedure for failure mode and effects
analysis (FMEA).
[5] IEC 61025:1990, Fault tree analysis (FTA).
[6] IEC 60300-3-9:1995, Dependability management — Part 3: Application guide — Section 9: Risk analysis
of technological systems.
[7] IEC 61014:1989, Programmes for reliability growth.
[8] IEC 61164:1995, Reliability growth — Statistical test and estimation methods.

18 © BSI 05-1999
blank 19
BS IEC
60300-3-6:1997
BSI — British Standards Institution
BSI is the independent national body responsible for preparing
British Standards. It presents the UK view on standards in Europe and at the
international level. It is incorporated by Royal Charter.

Revisions

British Standards are updated by amendment or revision. Users of

British Standards should make sure that they possess the latest amendments or
editions.

It is the constant aim of BSI to improve the quality of our products and services.
We would be grateful if anyone finding an inaccuracy or ambiguity while using
this British Standard would inform the Secretary of the technical committee
responsible, the identity of which can be found on the inside front cover.
Tel: 020 8996 9000. Fax: 020 8996 7400.

BSI offers members an individual updating service called PLUS which ensures
that subscribers automatically receive the latest editions of standards.

Buying standards

Orders for all BSI, international and foreign standards publications should be
addressed to Customer Services. Tel: 020 8996 9001. Fax: 020 8996 7001.

In response to orders for international standards, it is BSI policy to supply the

BSI implementation of those that have been published as British Standards,
unless otherwise requested.

Information on standards

BSI provides a wide range of information on national, European and

international standards through its Library and its Technical Help to Exporters
Service. Various BSI electronic information services are also available which give
details on all its products and services. Contact the Information Centre.
Tel: 020 8996 7111. Fax: 020 8996 7048.

Subscribing members of BSI are kept up to date with standards developments

and receive substantial discounts on the purchase price of standards. For details
of these and other benefits contact Membership Administration.
Tel: 020 8996 7002. Fax: 020 8996 7001.

Copyright

Copyright subsists in all BSI publications. BSI also holds the copyright, in the
UK, of the publications of the internationalstandardization bodies. Except as
permitted under the Copyright, Designs and Patents Act 1988 no extract may be
reproduced, stored in a retrieval system or transmitted in any form or by any
means – electronic, photocopying, recording or otherwise – without prior written
permission from BSI.

This does not preclude the free use, in the course of implementing the standard,
of necessary details such as symbols, and size, type or grade designations. If these
details are to be used for any other purpose than implementation then the prior
written permission of BSI must be obtained.

If permission is granted, the terms may include royalty payments or a licensing

agreement. Details and advice can be obtained from the Copyright Manager.
BSI Tel: 020 8996 7070.
389 Chiswick High Road
London
W4 4AL