IEEE Std 730-1989 IEEE Standard for Software Quality Assurance Plans.pdf

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 Electrid 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 Technical 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 broad 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 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 comments 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 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. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with IEEE. Suggestions for changes in documents 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 the 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 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 Standards 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 liability 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 Assurance 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 ANSYIEEE 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 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 developing 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 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 development. (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 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 the 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 Computer 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-Partain, 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- 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. 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 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 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 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. 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 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. Razy 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 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,Vice 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. Kitzantides 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 Definitions 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 Purpose . 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 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 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 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 (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 Standards, 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 considering 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 supersede, 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 existence 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 applicability 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 with 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.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 Configuration 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 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. 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