《IEEE Std 730-1989 IEEE Standard for Software Quality Assurance Plans.pdf》由会员分享，可在线阅读，更多相关《IEEE Std 730-1989 IEEE Standard for Software Quality Assurance Plans.pdf（12页珍藏版）》请在三一文库上搜索。
1、Recognized as an American National Standard (ANSI) IEEE Standard for Software Quality Assurance Plans Sponsor TechnidCommitteeonSoffwareEngineering of the IEEEComputerSociety Approved August 17,1989 Approved January 22,1990 American National Standards Institute 0 Copyright 1989 by The Institute of E
2、lectrid and Electrods Engineers, Inc 345 East 47th Street, New York, NY 10017, USA No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. IEEE Standards documents are developed within the Techn
3、ical Committees of the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Board. Members of the committees serve voluntarily and without compensation. They are not necessar- ily members of the Institute. The standards developed within IEEE represent a consensus of the bro
4、ad expertise on the subject within the Institute as well as those activities outside of IEEE which have expressed an interest in participating in the development of the standard. Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other way
5、s 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 comment
6、s received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revision or reaffir- mation. When a document is more than five years old, and has not been reaffirmed, it is reasonable to conclude that its contents, al- though still of some value, do no
7、t 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. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with IEEE. Suggestions for changes in d
8、ocuments should be in the form of a pro- posed change of text, together with appropriate supporting comments. Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific applica- tions. When the need for interpretations is brought to th
9、e attention of IEEE, the Institute will initiate action to prepare appropriate re- sponses. Since IEEE Standards represent a consensus of all con- cerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason IEEE and
10、 the members of its technical committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE Standard
11、s Board 445 Hoes Lane P.O. Box 1331 Piscataway, NJ 08855-1331 USA IEEE Standards documents are adopted by the Institute of Electrical and Electronics Engineers without regard to whether their adoption may involve patents on articles, materials, or processes. Such adop- tion does not assume any liabi
12、lity to any patent owner, nor does it assume any obligation whatever to parties adopting the standards documents. Fomrd (This Foreword is not a part of IEEE Std 730.1-1989, IEEE Standard for SoRware Quality Assurance Plans.) This standard assists in the preparation and content of Software Quality As
13、surance Plans and provides a standard against which such plans can be prepared and assessed. It is directed toward the development and maintenance of critical software-that is, where failure could impact safety or cause large financial or social losses. The readers of this document are referred to A
14、NSYIEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning, for recommended approaches to good software quality assurance practices in support of this standard. While ANSI/IEEE Std 983-1986 specifically refers to ANSYIEEE Std 730-1984, almost all of its content applies directly to this
15、 revision. In this standard, firmware is considered to be software and is to be treated as such. Footnotes are not part of the standard. There are three groups to whom this standard applies: the user, the developer, and the public. (1) The user, who may be another element of the same organization de
16、veloping the software, has a need for the product. Further, the user needs the product to meet the requirements identified in the specification. The user thus cannot afford a “hands-off attitude toward the developer and rely solely on a test to be executed at the end of the software development time
17、 period. If the product should fail, not only does the same need still exist, but also a portion of the development time has been lost. Therefore, the user needs to obtain a reasonable degree of confidence that the product is in the process of acquiring required attributes during software developmen
18、t. (2) The developer needs an established standard against which to plan and to be measured. It is unreasonable to expect a complete reorientation from project to project. Not only is it not cost effec- tive, but, unless there exists a stable framework on which to base changes, improvement cannot be
19、 made. (3) The public may be affected by the users use of the product. These users include, for example, depositors at a bank or passengers using a reservation system. Users have requirements, such as legal rights, which preclude haphazard development of software. At some later date, the user and th
20、e developer may be required to show that they acted in a reasonable and prudent professional manner to ensure that required software attributes were acquired. This standard was prepared by the Software Engineering Standards Subcommittee of the Software Engineering Technical Committee of the IEEE Com
21、puter Society. It was initially approved by the IEEE Standards Board for “trial use” in December of 1979, with a subsequent “full use” approval in September of 1981, and a revision approved on June 14,1984. The Working Group consisted of the following members: F. Buckley, Chairperson C. White-Partai
22、n, Vice-Chairperson S . Ah W. Barret R. Braun W. Eventoff J. Agrawal M. Ben-Menachem J. Case J. Chihorek M. Dewalt D. Doty R. Euler R. Evans J. Ewin M. Fitch M. Ghiassi J. Gilmore B. Gundaker J. Horch R. Ivy Executive Committee: R. Fordham M. Hein R Kosinsld E. Maginnius L. Marquis Members: S . Jon-
23、 H. Kaplan M. Karasik R. Kenneavy T. Kurihara B. Livson A. Miller R. Martin P. Pfister R Poston F. Rienstra J. Rcberts F. Rose W. Schultzer W. Schunk C. Seddin C. Modell S. Norman S. Trauth A. Tegtmeier A. Serna, Jr. R. Shillato T. Smith R. Stanton R. Stenglein A. Sullivan 0. Tanir E. Testa L. To G.
24、 Tucker H. van Doornum C. Von Schantz D. Wallace P. Willis P. Wolfgang Special Representatives to the Software Engineering Standards Subcommittee for this action were as follows: Nuclear Power Engineering CommitteelPower Engineering Society: N. Farr Quality Assurance Management Committee of the IEEE
25、 Communications Society: R. Mosher Canadian Standards Association: B. Dyczkowsky Data Processing Manufacturers Association: W. Perry At the time that the IEEE Standards Board approved this revision, the Software Engineering Standards Subcommittee, which was the balloting committee that approved this
26、 document for submission to the IEEE Standards Board, had the following membership: John Horch, Chairman W. Arfvidson C. Arnold R. Aurbach E. Baker B. Banerjee B. Beizer M. Ben-Menachem R. Berlack B. Bina M. Blackledge R. Blasewitz R. Both K. Briggs A. Brown W. Bryan F. Buckley C. Carpenter J. Case
27、T. Chow W. Chung F. Coallier G. Copeland P. Daggett M. Daniels T. Daughtrey K. DeJong D. Deluna C. Dencker P. Denny B. Derganc A. Dolinsky R. Dwyer L. Egan M. Egeland S. Eisen R. Erickson R. Euler C. Evans J. Fendrich A. Foley R. Fordham J. Forman J. Franklin I. Fuentes A. Geraci Y. Gershkovitch D.
28、Geyer E. Gibbs J. Gilmore S. Gloss-Soler J. Glynn J. Gonzalez-Sanz V. Guarnera D. Gustafson J. Guttman B. Harbort C. Hay J. Hillawi J. Horch P. Hung D. Johnson 1 1 1 J. Kalasky L. Kaleda M. Karasik R. Karcich 0. Kat0 P. Klopfenstein S. Koenig R. Kosinski T. Kurihara L. Lam J. Lane R. Lane G. Larsen
29、F. Lim K. Linberg B. Lindberg B. Livson H. Mains H. Malec J. Malsbury L. Marquis P. Marriott R. Martin T. Matsubara I. Mazza J. Mersky C. Model1 H. Nagano S. Najafi G. Neidhart D. Nickle J. ODay M. Olson W. Osbourne T. Parrish M. Perkins P. Peterson J. Phippen J. Pope R. Poston I. Pyle G. Ray M. Raz
30、y J. Reddan S. Redwine J. Roberts R. Roman R. Roth F. Ruhlman S. Schach H. Schaefer N. Schneidewind W. Schnoege H. Schock D. Schultz G. Schumacher L. Seagren L. Shafer R. Shillato D. Siefert I. Sjors A. Sorkowitz T. Stalhane N. Stewart W. Strigel R. Thayer P. Thompson G. Tice T. Tillmanns E. Tomlin
31、S. Trauth L. Tripp M. Uchida D. Ulery H. Verne C. Von Schantz D. Wallace J. Walter R. Weger P. Wiilis P. Wolfgang T. Worthington N. Yopconka P. Zoll When the IEEE Standards Board approved this standard on August 17, 1989, it had the following membership: Dennis Bodson, Chairman Marc0 W. Migliaro,Vic
32、e Chairman Andrew G. Salem, Secretary Arthur A. Blaisdell Fletcher J. Buckley Allen L. Clapp James M. Daly Stephen R. Dillon Donald C. Fleckenstein Eugene P. Fogarty Jay Foreter* Thomas L. Hannan Kenneth D. Hendrix Theodore W. Hissey, Jr. John W. Horch David W. Hutchins Frank D. Kirschner Frank C. K
33、itzantides Joseph L. Koepfinger* Edward Lohse John E. May, Jr. Lawrence V. McCall L. Bruce McClung Donald T. Michael* Richard E. Mosher Stig Nilsson L. John Rankine Gary S. Robinson Donald W. Zipse *Member Emeritus SECTION PAGE 1 . Scope and References 7 1.1 Scope . 7 1.2 References 7 2.1 Definition
34、s 8 2.2 Acronyms . 8 Software Quality Assurance Plan . 9 3.1 Purpose (Section 1 of the SQAP) 9 3.2 Reference Documents (Section 2 of the SQAP) 9 3.3 Management (Section 3 of the SQAP) 9 3.3.1 Organization 9 3.3.2 Tasks . 9 3.3.3 Responsibilities . 9 Documentation (Section 4 of the SQAP) 9 3.4.1 Purp
35、ose . 9 3.4.2 Minimum Documentation Requirements 10 3.4.2.1 Software Requirements Specification (SRS) . 10 3.4.2.2 Software Design Description (SDD) . 10 3.4.2.3 Software Verification and Validation Plan (SWP) 10 3.4.2.4 Software Verification and Validation Report (SWR) 10 3.4.2.5 User Documentation
36、 10 3.4.2.6 Software Configuration Management Plan . 10 3.4.3 Other . 1 0 3.5.1 Purpose 10 3.5.2 Content 10 3.6 Reviews and Audits (Section 6 of the SQAP) . 10 3.6.1 Purpose 10 3.6.2 Minimum Requirements . 1 1 3.6.2.1 Software Requirements Review (SRR) . 1 1 3.6.2.2 Preliminary Design Review (PDR) 1
37、 1 3.6.2.3 Critical Design Review (CDR) 11 3.6.2.4 Software Verification and Validation Plan Review (SWPR) 1 1 3.6.2.5 Functional Audit 1 1 3.6.2.6 Physical Audit . 1 1 3.6.2.7 In-Process Audits . 1 1 3.6.2.8 Managerial Reviews . 1 1 3.6.2.9 Software Configuration Management Plan Review (SCMPR) 1 1
38、3.6.2.10 Post Mortem Review . 1 1 3.6.3 Other . 1 1 3.7 Test (Section 7 of the SQAP) 1 1 3.8 Problem Reporting and Corrective Action (Section 8 of the SQAP) 1 1 3.9 Tools, Techniques, and Methodologies (Section 9 of the SQAP) . 1 1 3.10 Code Control (Section 10 of the SQAP) . 1 1 3.11 Media Control
39、(Section 1 1 of the SQAP) .E? 3.12 Supplier Control (Section 12 of the SQAP) 12 3.13 Records Collection. Maintenance. and Retention (Section 13 of the SQAP) E? 3.14 Training (Section 14 of the SQAP) E? 3.15 Risk Management (Section 15 of the SQAP) . 12 2 . Definitions and Acronyms . 8 3 . 3.4 3.5 St
40、andards, Practices, Conventions and Metrics (Section 5 of the SQAP) . 10 IEEE Standard for Software Quality Assurance Plans 1.1 Scope. The purpose of this standard is to provide uniform, minimum acceptable re- quirements for preparation and content of Software Quality Assurance Plans (SQAPs). In con
41、sidering adoption of this standard, regulatory bodies should be aware that specific application of this standard may already be covered by one or more IEEE or ANSI stan- dards documents relating to quality assur- ance, definitions, or other matters. It is not the purpose of this document to supersed
42、e, revise or amend existing standards directed to specific industries or applications. This standard applies to the development and maintenance of critical software. For non-critical software, or for software already developed, a subset of the requirements of this standard may be applied. The existe
43、nce of this standard should not be construed to prohibit additional content in a SQAP. An assessment should be made for the specific software item to assure adequacy of coverage. Where this standard is invoked for an organization or project engaged in produc- ing several software items, the applicab
44、ility of the standard should be specified for each of the software items. 1 . 2 References. The standards listed below should be used for further information. In using these references, the latest revisions should be obtained. Compliance with this standard does not require nor imply compli- ance wit
45、h any of those listed. ll ANSVASME NQA-1-1983, Quality Assur- ance Program Requirements for Nuclear Facilities. 1 ANSUASME publications are available from the Sales Department, American National Standards Institute, 1430 Broadway, New York, NY 10018 or from the ASME Order Department, 22 Law Drive, P
46、.O. Box 2300, Fairfield, NJ 07007-2300. 21 ANSVIEEE Std 603-1980, IEEE Standard Criteria for Safety Systems for Nuclear Power Generating Stations. 31 ANSVIEEE Std 729-1983, IEEE Standard Glossary of Software Engineering Termi- nology.2 41 ANSUIEEE Std 828-1983, IEEE Standard for Software Configurati
47、on Management Plans. 51 ANSUIEEE Std 829-1983, IEEE Standard for Software Test Documentation. SI ANSYIEEE Std 830-1984, IEEE Guide for Software Requirements Specifications. 71 IEEE Std 982.1-1988, IEEE Standard Dictio- nary of Measures to Produce Reliable Soft- ware. E 8 1 IEEE Std 982.2-1988, IEEE
48、Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software. 191 ANSYIEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning. (This is being redesignated to 730.2.) lo1 ANSIAEEE Std 990-1987, IEEE Recom- mended Practice for Ada as a Program De- sign Language.
49、 U11 ANSVIEEE Std 1002-1987, IEEE Standard Taxonomy of Software Engineering Stan- dards. E121 ANSVIEEE Std 1008-1987, IEEE Standard for Software Unit Testing. 2ANSyIEEE publications may be obtained from the IEEE Service Center, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331 or fmm the Sales Department, American National Standards Institute, 1430 Broadway, New York, NY 10018. 7 EEE 131 ANSUIEEE Std 1012-1986, IEEE Standard for Software Verification and Validation Plans. Std 730.1-1989 U41 ANSI/IEEE Std 1016-1987, IEEE Recom- mended Practice for Software D