1、| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BRITISH STANDARD BS 5760 : Part 8 : 1998 I
2、CS 21.020; 35.080 NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW Reliability of systems, equipment and components Part 8. Guide to assessment of reliability of systems containing softwareThis British Standard, having been prepared under the direction of the Management Systems
3、 Sector Board, was published under the authority of the Standards Board and comes into effect on 15 October 1998 BSI 1998 The following BSI references relate to the work on this standard: Committee reference DS/1 Draft for comment 96/402282 DC ISBN 0 580 28207 4 BS 5760 : Part 8 : 1998 Amendments is
4、sued since publication Amd. No. Date Text affected Committees responsible for this British Standard The preparation of this British Standard was entrusted to Technical Committee DS/1, Dependability and tetrotechnology, upon which the following bodies were represented: Association of Consulting Engin
5、eers Association of Insurance and Risk Managers (Airmic) Association of Project Managers British Railways Board British Telecommunications plc Centre for Software Reliability, City University Chartered Institution of Building Services Engineers Civil Aviation Authority Consumer Policy Committee of B
6、SI Cranfield University Defence Manufacturers Association Federation of the Electronics Industry GAMBICA (BEAMA Ltd.) Institute of Logistics Institute of Quality Assurance Institute of Risk Management Institute of Value Management Institution of Chemical Engineers Institution of Electrical Engineers
7、 Institution of Mechanical Engineers Institution of Plant Engineers London Underground Ltd. Ministry of Defence Railtrack Railway Industry Association Royal Institution of Chartered Surveyors Safety and Reliability Society Society of Environmental Engineers Society of Motor Manufacturers and Traders
8、 Limited United Kingdom Cals Industry Council West Midlands Enterprise BoardBS 5760 : Part 8 : 1998 BSI 1998 i Contents Page Committees responsible Inside front cover Foreword iii 0 Introduction 1 Guide 1 Scope 1 2 Normative references 1 3 Definitions 1 4 Basic concepts 4 4.1 System reliability 4 4.
9、2 Physical failure and design failure 4 4.3 Software failure 4 4.4 Measurement 7 4.5 Software reliability 8 5 Management overview 10 5.1 A management framework for software reliability assessment 10 5.2 Purposes of measurement 11 5.3 Data collection 11 5.4 Product-based software reliability assessme
10、nt 11 5.5 Process-based software reliability assessment 12 5.6 Product models 13 5.7 Process models 13 5.8 Applicability and limitations of methods 14 5.9 Procedures 17 6 Software reliability assessment techniques 18 6.1 Classification of techniques 18 6.2 Software development process models 18 6.3
11、Software property models 22 6.4 Stochastic reliability models 24 6.5 Assessment of high reliability for software 48 7 Application procedures 49 7.1 Introduction 49 7.2 Procedures for use with process models 51 7.3 Procedures for use with product property models 52 7.4 Procedures for use with stochas
12、tic reliability models 52 7.5 Data collection forms 62 7.6 Logistics of software maintenance 63 Annexes A (informative) Forms used in data collection 68 B (informative) Mathematical descriptions of stochastic reliability models 71 C (informative) Predictive accuracy of stochastic reliability growth
13、models 81 D (informative) Bibliography 85BS 5760 : Part 8 : 1998 ii BSI 1998 Page Figures 1 Mistake, fault, error, failure relationship 5 2 Software failure mechanism in a simple hierarchical system 6 3 Classification of stochastic reliability models 26 4 Fundamental reliability assessment problem:
14、time to failure 29 5 Fundamental reliability assessment problem: failure count data 29 6 Example of failure history graphs and use of LCM 30 7 System failure due to activation of latent faults 34 8 Fault activation and correction in Jelinski-Moranda 35 9 Illustration of why the assumption of uniform
15、 fault size leads to optimistic estimates 36 10 Fault activation and correction in LSRG 38 11 Example of a u-plot: assessment of bias in predictions 44 12 Graphical notation for relationship database structure 58 13 Database structure: single product on single installation 58 14 Tables and attribute
16、s for single installation data 59 15 Database structure: multiple products on several installations 59 16 Tables and attributes: multiple products and installations 61 17 Interaction of support cost drivers 67 A.1 Form 1: incident report 68 A.2 Form 2: software item use log (calendar time) 69 A.3 Fo
17、rm 3: software item use log (usage time) 70 Table 1 Management overview table 10 List of references Inside back cover BSI 1998 iii BS 5760 : Part 8 : 1998 Foreword This Part of BS 5760 has been prepared by Technical Committee DS/1. It supersedes DD 198 : 1991, which is withdrawn. This Part of BS 576
18、0 describes some of the techniques available for assessing the reliability of systems containing software. It provides guidance to developers and procurers of such systems on how to apply some of the better established methods of assessment, and on which to avoid. The methods can be applied to any t
19、ype of system, regardless of its intended function (although there are certain limitations in the case of high-integrity systems). It is intended that these guidelines should be applied (in addition to any other necessary techniques) even for applications where extremely high reliability is required
20、, in case the assessed level turns out to be inadequate. Clause 4 identifies the basis on which this Part of BS 5760 is founded. It describes the fundamental concepts associated with software reliability and is intended to provide an easily understandable introduction for the non-specialist reader.
21、Clause 5 provides an overview of software reliability issues for those who need to understand the results of modelling software reliability and a non-technical summary of the available methods. It addresses the high-level issues associated with the measurement of software reliability. The different
22、categories of model and the management of issues associated with their application are described. The relationship between reliability and integrity is introduced, and limits of the levels of reliability which can justifiably be claimed for software are discussed. Clause 6 contains a more detailed t
23、echnical description of the methods under the headings of process measurement (assessment of the quality of the software development process) and product measurement (assessment of the delivered software product). Clause 7 contains a more detailed technical description of the procedures for applicat
24、ion of the methods. Annex A contains examples of forms used in data collection. Annex B contains mathematical descriptions of some of the better-known software reliability models. Annex C contains mathematical descriptions of some techniques which can be used to assess the accuracy of the prediction
25、s obtained from software reliability models, correct for bias in the estimates, and combine estimates obtained from using different models. Annex D contains a bibliography of the documents referred to in this Part of BS 5760. Numerals in square brackets throughout the text refer to items in the bibl
26、iography. Annexes A to D are informative. Summary of pages This document comprises a front cover, an inside front cover, pages i to iv, pages 1 to 88, an inside back cover and a back cover.iv blank BSI 1998 1 BS 5760 : Part 8 : 1998 Introduction Techniques for measuring and predicting the reliabilit
27、y of hardware are already widely applied. With the increasing use of computers there is a need to establish equivalent methods for evaluating the reliability of systems containing software. The failure mechanism of software is not a physical process. A system containing software can fail when a late
28、nt fault within a software component is activated. Such faults are introduced by human error in the definition, design or development of the software, and are activated when particular circumstances are encountered during the operation of the system. Latent faults may also be present in the design o
29、f hardware, but are usually assumed to have been removed before the system is put into service, and are therefore discounted in the prediction of reliability. However in complex hardware, such as a microprocessor chip, design faults also contribute significantly to failure, and such complex designs
30、pose similar problems of reliability assessment to those encountered with software. This Part of BS 5760 describes the methods that are currently available for assessing the reliability of systems with respect to failures due to software faults. Many of these methods can also be used to assess syste
31、m reliability with respect to the activation of design faults in hardware. Suppliers and users need to be able to specify and measure the reliability of all kinds of systems containing software ranging from commercial billing systems to automotive electronic control units, nuclear reactor control sy
32、stems and computer controlled missiles. In some cases the probability of failure of such systems due to software faults is of greater concern than the probability of their failure due to physical causes. An assessment of the total reliability of any such system cannot afford to ignore the effect of
33、latent design faults. This British Standard provides a structure within which software reliability assessment issues can be addressed from the early stages of system requirements definition, through design, development and testing, until the actual reliability can be assessed during system trial and
34、 operation. The setting of achievable reliability targets and the prediction of reliability in the early phases of development requires the use of expert judgement based on experience and historical data. The monitoring of the ongoing development process and the assessment of the level of reliabilit
35、y achieved requires careful measurement. All of the relevant data should be collected and then analysed using statistical methods. Guidance is given on all of these aspects of the prediction and assessment of system reliability with respect to the manifestation of software faults. Guide 1 Scope This
36、 Part of BS 5760 gives guidance on the assessment of reliability of systems containing software with respect to those failures that are due to the activation under certain environmental circumstances of latent design faults located in software items. NOTE. Latent software design faults are due to hu
37、man error during the definition, design and development phases of system production. Guidance is provided on the assessment of system reliability both by assessment of the product (the software) and by assessment of the process (the means by which the software is developed). This guidance applies to
38、 any system containing software regardless of its intended function. There are limits to the level of reliability that can be assessed quantitatively. This Part of BS 5760 seeks to classify some of the more established methods and to provide guidance to the practitioner in applying them. A bibliogra
39、phy is provided in annex D. 2 Normative references This Part of BS 5760 incorporates, by dated or undated reference, provisions from other publications. These normative references are made at the appropriate places in the text and the cited publications are listed on the inside back cover. For dated
40、 references, only the edition cited applies; any subsequent amendments to, or revisions of the cited publications apply only when incorporated in the reference by amendment or revision. For undated references, the latest edition of the cited publication applies, together with any amendments. 3 Defin
41、itions NOTE. These definitions cover the field of software reliability measurement. They have been made as consistent as possible with the terms employed in general reliability, availability and maintainability work, and in particular with the definitions in BS 4778. In some cases it has been necess
42、ary to extend or modify the BS 4778 definitions slightly, since it does not take into account some aspects of systems containing software. Where this has been necessary, the BS 4778 definition is quoted with a note or amendment (see for example 3.11). 3.1 activation (of a fault) The event in which a
43、 latent fault gives rise to a failure in response to a trigger. NOTE. Also referred to as manifestation of the fault. 3.2 attribute Any observable property of an entity. 3.3 baseline A major version of a system selected for release to customers and/or for the purpose of measuring some attribute, e.g
44、. reliability.2 BSI 1998 BS 5760 : Part 8 : 1998 3.4 bug Synonymous with design fault, usually in software. 3.5 calendar time Time as commonly recorded by clocks and proportional to the rotation of the Earth. NOTE 1. Also known as elapsed time, or real time, or wall-clock time. NOTE 2. This time is
45、public in the sense that all observers can agree on it, except that geographical time zones may need to be taken into account. NOTE 3. Reliability measurement usually requires the use of operating time, which is a measure of the total time during which a defined sample of systems has been in use or
46、on trial. Operating time is generally not the same as real time. NOTE 4. Measurement of software reliability requires a measure of execution time, which is the operating time of a software item. 3.6 direct measurement Measurement which can be made by empirical observation of a single attribute and d
47、oes not depend on the measurement of other attributes. 3.7 entity Any object, event or process in the real world. 3.8 execution profile A measurement of the proportion of total execution time that is spent executing code within each subsystem or module of a software item. 3.9 execution time A measur
48、e of the amount of execution undergone by a software item. NOTE. The measure chosen will depend on the type of system. Generally, it will not be equivalent to real time. Possible measures are processor time consumed, number of instructions executed, etc. 3.10 external attribute An attribute of a sys
49、tem which characterizes its interaction with its environment. 3.11 failure The event of an item ceasing to perform a required function or provide a required service in full or in part. NOTE 1. The term item may refer to a complex system, consisting of hardware, software, or both. NOTE 2. A failure is an event in time. A fault is a state of the system. NOTE 3. A failure may be due to physical failure of a hardware component, activation of a latent design fault or an external failure. NOTE 4. Following a failure, an item may recover and resume its required service after a brea
