IEEE 1633-2016 en Recommended Practice on Software Reliability.pdf

《IEEE 1633-2016 en Recommended Practice on Software Reliability.pdf》由会员分享，可在线阅读，更多相关《IEEE 1633-2016 en Recommended Practice on Software Reliability.pdf（261页珍藏版）》请在麦多课文档分享上搜索。

1、 IEEE Recommended Practice on Software Reliability Sponsored by the Standards Committee IEEE 3 Park Avenue New York, NY 10016-5997 USA IEEE Reliability Society IEEE Std 1633-2016 (Revision of IEEE Std 1633-2008) IEEE Std 1633-2016 (Revision of IEEE Std 1633-2008) IEEE Recommended Practice on Softwar

2、e Reliability Sponsor Standards Committee of the IEEE Reliability Society Approved 22 September 2016 IEEE-SA Standards Board Abstract: The methods for assessing and predicting the reliability of software, based on a life-cycle approach to software reliability engineering (SRE), are prescribed in thi

3、s recommended practice. It provides information necessary for the application of software reliability (SR) measurement to a project, lays a foundation for building consistent methods, and establishes the basic principle for collecting the data needed to assess and predict the reliability of software

4、. The recommended practice prescribes how any user can participate in SR assessments and predictions. Keywords: IEEE 1633, software failure modes, software reliability The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright 2017 by The Instit

5、ute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 18 January 2017. Printed in the United States of America. IEEE is a registered trademark in the U.S. Patent fitness for a particular purpose; non-infringement; and quality, accuracy, effectiveness, currency, or complete

6、ness of material. In addition, IEEE disclaims any and all conditions relating to: results; and workmanlike effort. IEEE standards documents are supplied “AS IS” and “WITH ALL FAULTS.” Use of an IEEE standard is wholly voluntary. The existence of an IEEE standard does not imply that there are no othe

7、r ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and co

8、mments received from users of the standard. In publishing and making its standards available, IEEE is not suggesting or rendering professional or other services for, or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any other person or entity to another. Any p

9、erson utilizing any IEEE Standards document, should rely upon his or her own independent judgment in the exercise of reasonable care in any given circumstances or, as appropriate, seek the advice of a competent professional in determining the appropriateness of a given IEEE standard. IN NO EVENT SHA

10、LL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO: PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRAC

11、T, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE PUBLICATION, USE OF, OR RELIANCE UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE AND REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE. Copyright 2017 IEEE. All rights reserved. 3 Tran

12、slations The IEEE consensus development process involves the review of documents in English only. In the event that an IEEE standard is translated, only the English version published by IEEE should be considered the approved IEEE standard. Official statements A statement, written or oral, that is no

13、t processed in accordance with the IEEE-SA Standards Board Operations Manual shall not be considered or inferred to be the official position of IEEE or any of its committees and shall not be considered to be, or be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or educat

14、ional courses, an individual presenting information on IEEE standards shall make it clear that his or her views should be considered the personal views of that individual rather than the formal position of IEEE. Comments on standards Comments for revision of IEEE Standards documents are welcome from

15、 any interested party, regardless of membership affiliation with IEEE. However, IEEE does not provide consulting information or advice pertaining to IEEE Standards documents. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting

16、 comments. Since IEEE standards represent a consensus of concerned interests, it is important that any responses to comments and questions also receive the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able

17、 to provide an instant response to comments or questions except in those cases where the matter has previously been addressed. For the same reason, IEEE does not respond to interpretation requests. Any person who would like to participate in revisions to an IEEE standard is welcome to join the relev

18、ant IEEE working group. Comments on standards should be submitted to the following address: Secretary, IEEE-SA Standards Board 445 Hoes Lane Piscataway, NJ 08854 USA Laws and regulations Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the provisi

19、ons of any IEEE Standards document does not imply compliance to any applicable regulatory requirements. Implementers of the standard are responsible for observing or referring to the applicable regulatory requirements. IEEE does not, by the publication of its standards, intend to urge action that is

20、 not in compliance with applicable laws, and these documents may not be construed as doing so Copyrights IEEE draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws. They are made available by IEEE and are adopted for a wide variety of both public and privat

21、e 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 making these documents available for use and adoption by public authorities and private users, IEEE does not waive an

22、y rights in copyright to the documents. Copyright 2017 IEEE. All rights reserved. 4 Photocopies Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to photocopy portions of any individual standard for company or organizational internal use or individual,

23、 non-commercial use only. To arrange for payment of licensing fees, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained

24、through the Copyright Clearance Center. Updating of IEEE Standards documents Users of IEEE Standards documents should be aware that these documents may be superseded at any time by the issuance of new editions or may be amended from time to time through the issuance of amendments, corrigenda, or err

25、ata. 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. Every IEEE standard is subjected to review at least every ten years. When a document is more than ten years old and has not undergon

26、e a revision process, it is reasonable to conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE standard. In order to determine whether a given document is

27、the current edition and whether it has been amended through the issuance of amendments, corrigenda, or errata, visit the IEEE Xplore at http:/ieeexplore.ieee.org/ or contact IEEE at the address listed previously. For more information about the IEEE-SA or IEEEs standards development process, visit th

28、e IEEE-SA Website at http:/standards.ieee.org. Errata Errata, if any, for all IEEE standards can be accessed on the IEEE-SA Website at the following URL: http:/standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata periodically. Patents Attention is called t

29、o the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken by the IEEE with respect to the existence or validity of any patent rights in connection therewith. If a patent holder or patent ap

30、plicant has filed a statement of assurance via an Accepted Letter of Assurance, then the statement is listed on the IEEE-SA Website at http:/standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may indicate whether the Submitter is willing or unwilling to grant licenses under pate

31、nt rights without compensation or under reasonable rates, with reasonable terms and conditions that are demonstrably free of any unfair discrimination to applicants desiring to obtain such licenses. Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is

32、not responsible for identifying Essential Patent Claims for which a license may be required, 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,

33、or in any licensing agreements are reasonable or non-discriminatory. Users of this standard 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 I

34、EEE Standards Association. Copyright 2017 IEEE. All rights reserved. 5 Participants At the time this IEEE recommended practice was completed, the IEEE 1633 Working Group had the following membership: Ann Marie Neufelder, Chair Martha Wetherholt, Vice Chair Debra Haehn, Secretary Lou Gullo, Sponsor C

35、hair Jacob Axman Bakul Banerjee David Bernreuther Nematollah Bidokhti Robert Binder Sonya Davis Mary Ann DeCicco Lance Fiondella Willie Fitzpatrick Kevin Frye Loren Garroway Richard E. Gibbs III Michael Grottke Darwin Heiser Nathan Herbert Claire Jones Burdette Joyner Ahlia T. Kitwana Peter Lakey Mi

36、ng Li Andy Long Debra Greenhalgh Lubas Andrew Mack Franklin Marotta Kevin Mattos Brian McQuillan Rajesh Murthy Allen Nikora Mark Ofori-kyei Robert Raygan Ying Shi Marty Shooman Mark Sims Michael Siok Shane Smith George Stark Kishor Trivedi Thierry Wandji Martin Wayne Yuan Wei Harry White The followi

37、ng members of the individual balloting committee voted on this recommended practice. Balloters may have voted for approval, disapproval, or abstention. Johann Amsenga Bakul Banerjee Pieter Botman Bill Brown Keith Chow Paul Croll Sonya Davis Mary Ann DeCicco Neal Dowling Richard Doyle Lance Fiondella

38、 Debra Greenhalgh Randall Groves Louis Gullo Debra Haehn Jon Hagar Werner Hoelzl Bernard Homes Noriyuki Ikeuchi Cheryl Jones Piotr Karocki Chad Kiger Ahlia Kitwana Edward McCall Jeffrey Moore Rajesh Murthy Andrew Nack Ann Marie Neufelder Michael Newman Mark Ofori-Kyei Howard Penrose Iulian Profir St

39、ephen Schwarm Jeremy Smith Thomas Starai Eugene Stoudenmire Walter Struppler Eric Thibodeau Martha Wetherholt Paul Work Daidi Zhong 6 Copyright 2017 IEEE. All rights reserved. When the IEEE-SA Standards Board approved this recommended practice on 22 September 2016, it had the following membership: J

40、ean-Philippe Faure, Chair Ted Burse, Vice Chair John D. Kulick, Past Chair Konstantinos Karachalios, Secretary Chuck Adams Masayuki Ariyoshi Stephen Dukes Jianbin Fan Ronald W. Hotchkiss J. Travis Griffith Gary Hoffman Michael Janezic Joseph L. Koepfinger* Hung Ling Kevin Lu Gary Robinson Annette D.

41、 Reilly Mehmet Ulema Yingli Wen Howard Wolfman Don Wright Yu Yuan Daidi Zhong *Member Emeritus 7 Copyright 2017 IEEE. All rights reserved. Introduction This introduction is not part of IEEE Std 1633-2016, IEEE Recommended Practice on Software Reliability. Software is, from a materials viewpoint, bot

42、h malleable and ductile. This means there are multiple ways to introduce failures, intentional and un-intentional. Fixing a software defect can introduce a potential defect. In many cases the failures that result from software defects are both predictable and avoidable but they still occur because o

43、f the following: a) Lack of available calendar time/resources to find all of the defects that can result in failures b) Exceedingly complex event driven systems that are difficult to conceptualize and therefore implement and test c) Organizational culture that neglects to support sufficient rigor, s

44、kills, or methods required to find the defects d) Technical decisions that result in incorrect architecture or design decision that cannot support the stakeholders specifications e) Insufficient project or risk management that leads to schedule delays that lead to less time for reliability testing f

45、) OperationsContract issues, interoperability due to bad specifications and stakeholder communications Even a small number of software failures can lead to monetary catastrophes such as a cancelled project. Hardware (HW) failures can be random, due to wear-out or the result of a systematic design fl

46、aw. Reliability maintainability availability (RMA) is used to prevent and deal with hardware failures. Software failures may result from systematic flaws in the requirements, design, code or interfaces. Hence, software failure does not require an RMA but instead a corrective action to an existing in

47、stallation. Software failures can be common cause failures in that the same failure mode can cause multiple failures in more than one part of the software. Software reliability engineering (SRE) is an established discipline that can help organizations improve the reliability of their products and pr

48、ocesses. It is important for an organization to have a process discipline if it is to produce high reliability software. These are specific practices and recommendations, each of which has a context within the software engineering life cycle. A specific practice may be implemented or used in a parti

49、cular stage of the life cycle or used across several stages. Figure 1 shows how the focus of SRE shifts as a project progresses from inception to release. The size of each bubble on this figure corresponds to how much the particular SRE practices are being executed during each particular phase of development or operation. For example in software engineering projects, the failure modes and effects analysis (FMEA) is typically performed earlier in the life cycle. 8 Copyright 2017 IEEE. All rights reserved. Figure 1 SRE focus by stage The scope of this recommended practic