1、IEEE Std 1633-2008IEEE Recommended Practice onSoftware ReliabilityIEEE3 Park Avenue New York, NY 10016-5997, USA27 June 2008IEEE Reliability SocietySponsored by theStandards Committee1633TMIEEE Std 1633-2008 IEEE Recommended Practice on Software Reliability Sponsor Standards Committee of the IEEE Re
2、liability Society Approved 27 March 2008 IEEE-SA Standards Board 1999 IEEE. Figure F.6 is reprinted with permission from the IEEE and Samuel Keene (author), from his paper presented at the Tenth International Symposium on Software Reliability Engineering. Abstract: The methods for assessing and pred
3、icting the reliability of software, based on a life-cycle approach to software reliability engineering, are prescribed in this recommended practice. It provides information necessary for the application of software reliability (SR) measurement to a project, lays a foundation for building consistent
4、methods, and establishes the basic principle for collecting the data needed to assess and predict the reliability of software. The recommended practice prescribes how any user can participate in SR assessments and predictions. Keywords: software reliability The Institute of Electrical and Electronic
5、s Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright 2008 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 27 June 2008. Printed in the United States of America. IEEE is a registered trademark in the U.S. Patent +1 978 750 8400. Permiss
6、ion to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center. Introduction This introduction is not part of IEEE Std 1633-2008, IEEE Recommended Practice on Software Reliability. Software reliability engineering (SRE)
7、is an established discipline that can help organizations improve the reliability of their products and processes. The American Institute of Aeronautics and Astronautics (AIAA) defines SRE as “the application of statistical techniques to data collected during system development and operation to speci
8、fy, predict, estimate, and assess the reliability of software-based systems.” This recommended practice is a composite of models and tools and describes the “what and how” of SRE. It is important for an organization to have a disciplined process if it is to produce high reliability software. The pro
9、cess is described and enhanced to include a life-cycle approach to SRE that takes into account the risk to reliability due to requirements changes. A requirements change may induce ambiguity and uncertainty in the development process that cause errors in implementing the changes. Subsequently, these
10、 errors may propagate through later phases of development and maintenance. These errors may result in significant risks associated with implementing the requirements. For example, reliability risk (i.e., risk of faults and failures induced by changes in requirements) may be incurred by deficiencies
11、in the process (e.g., lack of precision in requirements). Figure a shows the overall SRE closed-loop holistic process. The arrows signify the flow of software product, information, and/or failure data. Risk AssessmentCustomerSoftware DesignProgrammingRisk Models(Risk factors ,Discrepancy reports )De
12、sign andProgramming metrics(source lines of code )Reliability growthmodels ;Reliability toolsTesting OperationsFigure aSRE process The scope of this recommended practice is to address software reliability (SR) methodologies and tools. This recommended practice does not address systems reliability, s
13、oftware safety, nor software security. The recommended practice only briefly addresses software quality. This recommended practice provides a common baseline for discussion and prescribes methods for assessing and predicting the reliability of software. The recommended practice is intended to be use
14、d in support of designing, developing, and testing software and to provide a foundation on which practitioners and researchers can build consistent methods for assessing the reliability of software. It is intended to meet the needs of software practitioners and users who are confronted with varying
15、terminology for reliability measurement and a plethora of models and data collection methods. This recommended practice contains information necessary for the application of SR measurement to a project. This includes SR activities throughout the software life cycle (SLC) starting at requirements gen
16、eration by identifying the application, specifying requirements, and analyzing requirements and continuing into the implementation phases. It also serves as a reference for research on the subject of SR. It includes guidance on the following: Common terminology. Assessment of SR risk. iv Copyright 2
17、008 IEEE. All rights reserved. Determining whether previously applied software processes are likely to produce code that satisfies a given SR requirement. Software design process improvement evaluation and software quality. SR assessment procedures (i.e., measure current software reliability). Test
18、selection and model selection. Data collection procedures to support SR estimation and prediction. Determining when to release a software system, or to stop testing the software and implement corrections. SR prediction (i.e., predict future software reliability). This includes the calculation of the
19、 probability of occurrence of the next failure for a software system, and other reliability metrics. Identify elements in a software system that are leading candidates for redesign to improve reliability. Revisions to the document and notes This document is a revision of AIAA R-013-1992, Recommended
20、 Practice on Software Reliability. The following changes and additions are designed to enhance its usability: “Recommended models” has been changed to “initial models” to reflect the fact that this document is a recommended practice. The meaning of “initial models” is that models in this category ar
21、e designated for initial use. If none of these models is satisfactory for the users application, the models described in Annex A can be considered. Life-cycle approach to SRE. SRE process diagram (see Figure a). Inclusion of reliability requirements risk assessment. Additions to 5.1. Identify applic
22、ation. Specify the reliability requirement. Allocate the requirement. Correct designation of informative clauses. Simplified and clarified language. Elimination of mathematics that do not support the objectives of the recommended practice. Correct use of “shall,” “should,” and “may” to indicate conf
23、ormance with the recommended practice. Correction of errors. Upgrade of Schneidewind initial model. Addition of John Musas latest book B55aas a reference. Deletion of Assumption 1 in the Musa/Okumoto model. The Littlewood/Verrall model has been moved from “initial models” to Annex A because many of
24、its terms were not defined. aThe numbers in brackets correspond to those of the bibliography in Annex G. v Copyright 2008 IEEE. All rights reserved. Structure of the recommended practice This recommended practice contains five clauses and seven annexes as follows: Clause 1 is the introduction, inclu
25、ding scope, purpose, audience, and relationships between hardware and SR. Clause 2 contains definitions of terms used in this recommended practice. Clause 3 gives an overview of SRE. Clause 4 provides a list of activities that should be carried out in order to conform with this recommended practice.
26、 Clause 5 provides information on recommended SR prediction models. Annex A provides information on additional SR prediction models. Annex B describes methods for combining hardware and SR predictions into a system reliability prediction. Annex C provides information on using the recommended practic
27、e to help obtain system reliability (including both hardware and SR). Annex D contains Table D.1, which lists the two most popular SR measurement tools. Annex E contains a comparison of constant, linearly decreasing, and exponentially decreasing models. Annex F provides SR prediction tools prior to
28、testing during the early design phases. Annex G contains a bibliography of over 70 papers and books about SRE. Clause 1, Clause 2, and Clause 3 should be read by all users. Clause 3, Annex A, and Annex C provide the basis for establishing the process and the potential uses of the process. Subclause
29、5.6.1 provides the foundation for establishing an SR data collection program, as well as what information needs to be collected to support the recommended models, which is also described in Annex A. Annex D identifies tools that support the reliability database, as well as the recommended models and
30、 the analysis techniques described in Clause 4, Annex A, and Annex C. Finally, to improve the state of the art in SRE continuously, recommended practice users should typically review Clause 1, Clause 2, and Clause 3 and begin applying the techniques described in 5.5, and concluding with Annex D and
31、Annex F on reliability tools. Notice to users Laws and regulations Users of these documents should consult all applicable laws and regulations. Compliance with the provisions of this standard does not imply compliance to any applicable regulatory requirements. Implementers of the standard are respon
32、sible for observing or referring to the applicable regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents may not be construed as doing so. vi Copyright 2008 IEEE. All rights reserved. Cop
33、yrights This document is copyrighted by the IEEE. It is made available for a wide variety of both public and private uses. These include both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering practices and methods. By ma
34、king this document available for use and adoption by public authorities and private users, the IEEE does not waive any rights in copyright to this document. Updating of IEEE documents Users of IEEE standards should be aware that these documents may be superseded at any time by the issuance of new ed
35、itions or may be amended from time to time through the issuance of amendments, corrigenda, or errata. An official IEEE document at any point in time consists of the current edition of the document together with any amendments, corrigenda, or errata then in effect. In order to determine whether a giv
36、en document is the current edition and whether it has been amended through the issuance of amendments, corrigenda, or errata, visit the IEEE Standards Association Web site at http:/ieeexplore.ieee.org/xpl/standards.jsp, or contact the IEEE at the address listed previously. For more information about
37、 the IEEE Standards Association or the IEEE standards development process, visit the IEEE-SA Web site at http:/standards.ieee.org. Errata Errata, if any, for this and all other standards can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/updates/errata/index.html. Users are
38、encouraged to check this URL for errata periodically. Interpretations Current interpretations can be accessed at the following URL: http:/standards.ieee.org/reading/ieee/interp/ index.html. Patents Attention is called to the possibility that implementation of this recommended practice may require us
39、e of subject matter covered by patent rights. By publication of this recommended practice, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE is not responsible for identifying Essential Patent Claims for which a license may be requi
40、red, for conducting inquiries into the legal validity or scope of Patents Claims or determining whether any licensing terms or conditions provided in connection with submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users of this recomm
41、ended practice are expressly advised that determination of the validity of any patent rights, and the risk of infringement of such rights, is entirely their own responsibility. Further information may be obtained from the IEEE Standards Association. vii Copyright 2008 IEEE. All rights reserved. Part
42、icipants At the time this recommended practice was submitted to the IEEE-SA Standards Board for approval, the Software Reliability Working Group had the following membership: Norman F. Schneidewind, Chair Louis J. Gullo, Sponsor Chair and Final Editor Kadir Alpaslan Demir, Editor William Everett Wil
43、liam Farr Herbert Hecht Michael Hinchey Samuel Keene Theodore Keller Michael Lyu John Musa Allen Nikora Martin Shooman George Stark Jeff Voas Mladen Vouk Dolores Wallace Linda Wilbanks The following members of the individual balloting committee voted on this recommended practice. Balloters may have
44、voted for approval, disapproval, or abstention. Ahmed Abdelhalim William J. Ackerman S. Aggarwal Ali Al Awazi Bakul Banerjee Charles Barest Hugh Barrass Thomas Basso Steven Bezner Gregory M. Bowen Juan Carreon Lanna Carruthers Norbert N. Carte Lawrence Catchpole Weijen Chen Keith Chow Raul Colcher T
45、ommy Cooper Paul Croll Geoffrey Darnton Matthew Davis Kadir Alpaslan Demir Bostjan K. Derganc Antonio Doria Neal Dowling Scott P. Duncan Sourav Dutta Kameshwar Eranki Carla Ewart Harriet Feldman John Fendrich Andrew Fieldsend Kenneth Fodero Andre Fournier Avraham Freedman Michael Geipel Gregg Giesle
46、r Allan Gillard Colin M. Glanville H. Glickenstein John Garth Glynn Ron Greenthaler Randall Groves C .Guy Ajit Gwal John Harauz Mark Henley Rutger A. Heunks Werner Hoelzl Robert Holibaugh Chi T. Hon Peter Hung Mark Jaeger James Jones Lars Juhlin Piotr Karocki Samuel Keene Robert B. Kelsey Mark Knigh
47、t Thomas Kurihara George Kyle Marc Lacroix Daniel Lindberg G. Luri L. J. Tajerian Martinez Richard A. McBride Michael McCaffrey Jonathon McLendon Earl Meiers Gary Michel William Milam James Moore Thomas Mullins Jerry Murphy Rajesh Murthy John Musa Michael S. Newman Mark Paulk Miroslav Pavlovic Rober
48、t Peterson Peter Petrov Ulrich Pohl Iulian Profir Annette Reilly Michael Roberts Robert Robinson Terence Rout Michael Rush Randall Safier James Sanders Helmut H. Sandmayr Bartien Sayogo Robert Schaaf Hans Schaefer Norman F. Schneidewind David J. Schultz Stephen Schwarm Lynn Simms Carl Singer James S
49、ivak David Smith Steven Smith Luca Spotorno Manikantan Srinivasan Thomas Starai James St.Clair Walter Struppler Gerald Stueve Mark Sturza Noriaki Takenoue Joseph Tardo John Thywissen Thomas Tullia Vincent J. Tume Mladen Vouk John Walz Robert Wilkens David Willow Don Wright Oren Yuen Janusz Zalewsk viii Copyright 2008 IEEE. All rights reserved. When the IEEE-SA Standards Board approved this recommended practice on 27 March 2008, it had the following membership: Robert M. Grow, Chair Thomas Pr
