Вы находитесь на странице: 1из 31

ANSI/IEEE

Std 983-1986

An American National Standard


IEEE Guide for Software Quality
Assurance Planning

Sponsor
Software Engineering Standards Subcommittee
of the
Technical Committee on Software Engineering
of the
IEEE Computer Society

Approved September 19,1985


IEEE Standards Board

Approved February 20,1986


American National Standards Institute

@ Copyright 1986 by

The Institute of Electrical and Electronics 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 Com-
mittees of the IEEE Societies and the Standards Coordinating Commit-
tees of the IEEE Standards Board. Members of the committees serve
voluntarily and without compensation. They are not necessarily mem-
bers 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 in-
terest 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 pro-
duce, test, measure, purchase, market, or provide other goods and ser-
vices related to the scope of the IEEE Standard. Furthermore, the view-
point 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 Stan-
dard is subjected to review at least once every five years for revision
or reaffirmation. When a document is more than five years old, and has
not been reaffirmed, it is reasonable to conclude that its contents,
although still of some value, d o not wholly reflect the present state of
the art. Users are cautioned to check t o 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. Sug-
gestions for changes in documents should be in the form of a proposed
change of text, together with appropriate supporting comments.
Interpretations: Occasionally questions may arise regarding the mean-
ing of portions o'f standards as they relate to specific applications. When
the need for interpretations is brought to the attention of IEEE, the
Institute will initiate action to prepare appropriate responses. Since
IEEE Standards represent a consensus of all concerned interests, it is
important to ensure that any interpretation has also received the con-
currence of a balance of interests. For this reason IEEE and the mem-
bers of its technical committees are not able to provide an instant re-
sponse to interpretation requests except in those cases where the mat,ter
has previously received formal consideration.
Comments on standards and requests for interpretations should be ad-
dressed to:
Secretary, IEEE Standards Board
345 East 47th Street
New York, NY 10017
USA
Foreword

(This Foreword is not a part of IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.)

The purpose of this guide is to recommend approaches to good Software Quality Assurance practices
in support of ANSI / IEEE Std 730-1984, IEEE Standard for Software Quality Assurance Plans. This
guide is meant to supplement ANSI / IEEE Std 730-1984 by presenting the current consensus of those
in the software development community who have expertise or experience in generating, imple-
menting, evaluating, and modifying Software Quality Assurance plans. this guide is not offered as
a detailed procedures manual for establishing and operating Software Quality Assurance programs.
This guide does not constitute further requirements than those stated in ANSI / IEEE Std 730-1984.
An organization can claim compliance with ANSI / IEEE Std 730-1984 without following completely,
or in part, this guide. Detailed information regarding specific software quality assurance activities
may be found in other IEEE Standards. These are referenced where appropriate. While this guide
quotes major portions of ANSI / IEEE Std 730-1984,the standard is not quoted in its entirety. ANSI /
IEEE Std 730-1984 users are advised to consult that standard directly.
In accordance with ANSI / IEEE Std 730-1984, the practices herein are directed toward the devel-
opment and maintenance of critical software, that is, where failure could impair safety or cause
large financial losses. Determination of this criticality lies in the “eyes of the beholder.” The specific
application and situation of each user must be carefully considered. Should there be doubt, it is
suggested that the software be considered critical. For software that is definitely noncritical, or
software already developed, a subset of the requirements stated in ANSI/IEEE Std 730-1984 is
appropriate.
This guide serves the three groups discussed in the Foreword to ANSI/IEEE Std 730-1984: the
user, the developer, and the public.
(1) The user, whether external or internal to the developing organization, has a need for the
software product that meets its identified requirements. Thus, the user cannot afford to rely solely
on the developer’s tests at the conclusion of the software development effort. Should the software
product fail to meet requirements at that point, the user’s need still exists and a major portion of
the development time has been lost. The user, therefore, needs to have a reasonabladegree of
confidence that the product is in the process of acquiring required attributes during software devel-
opment.
(2) The developer needs a software quality assurance standard which establishes responsibility
and accountability. It is unreasonable to expect a complete reorientation from project to project. Not
only is it not cost-effective, but unless there exists a stable framework on which to base changes,
improvements cannot be made.
(3) The public, which may be affected by the use of the software, has a vested interest in software
development. This public includes, for example, depositors at a bank and passengers using a reser-
vation system. The public has a right to expect that software developers have acted in a reasonable
and prudent professional manner to provide the required software attributes. At some later date,
the user, the developer, or both may be required to show that they did, in fact, act in such a reasonable
and prudent professional manner.
This guide is addressed to readers who have professional experience in quality assurance, or in
software development, but not necessarily in both. For example, this guide should be useful to the
following individuals:
(1) A quality assurance person with the responsibility for developing or implementing a Software
Quality Assurance Plan for a project
(2) A software development project manager desiring to initiate Software Quality Assurance pro-
cedures on a project
(3) A purchaser or user of a software product who wants to evaluate a seller’s Software Quality
Assurance Plan or to specify a Software Quality Assurance Plan
(4) An independent evaluator, such as an EDP auditor
(5) The person with accountability for the implementation of a Software Quality Assurance Plan
In the body of this guide, the use of “shall” is to be understood as referring to an item or activity
that is mandated by ANSI/IEEE Std 730-1984. The use of “should” is to be understood as referring
to a recommended item or activity. The use of “may” is to be understood as referring to an item or
activity that can be advised under some circumstances, but for which there is not a professional
consensus. The use of “could” is to be understood as suggesting the existence of several possibilities,
the selection among which will be specific to the project and not driven by specific quality assurance
considerations.
This guide was prepared and balloted by the Software Engineering Standards Subcommittee of
the Software Engineering Technical Committee of the IEEE Computer Society. At the time it approved
this standard, the subcommittee had the following membership:

George D. Tice, Jr., Chairperson


Joel Hebert, Treasurer Laurel V. Kaleda, Secretary
A. Frank Ackerman, Vice Chairperson Robert M. Poston, Vice Chairperson
John W.Horch, Vice Chairperson Leonard Tripp, Vice Chairperson
Thomas M. Kurihara, Vice Chairperson

William L. Anderson Carolyn M. Harrison Jock A. Rader


Roy W. Bass Clark M. Hay Jean-Claude Rault
Nestore G. Biasi Madeleine C. Heidkamp Lawrence K. Reed
Michael A. Blackledge Leslie R. Heselton, I11 Donald J. Reifer
John F. Boucher Charles R. Hollocker Steven M. Rowan
William L. Bryan Samual Horvitz Frank Salvia
Fletcher J. Buckley Lawrence M. Johmann Hans Schaefer
Une H. Butenhoff Harry Kalmbach Robert W. Schillato
C. L. Carpenter Michael R. Kirchner Max J. Schindler
Jung K. Chung George A. Klammer Norman F. Schneidewind
Won L. Chung Joseph J. Klock Robert G. Schueppert
Corey Clinger Dwayne L. Knirk David J. Schultz
David Collard Albert M. Lerner Leonard W. Seagren
Christopher M. Cooke Richard C. Lewis Anthony E. Severino
Gilmore G. Cooke F. C. Lim Ronald L. Skelton
John D.Cooper Gary S. Lindsay Marian P. Smith
A. J. Cote, Jr. Ben Livson Wayne Smith
Richard Cotter Alan Cheuk-Wai Ma Thomas Q. Stevenson
Steward G. Crawford Henry A. Malec William G. Sutcliffe
Robert C. Crombe William A. Mandeville Michael H. Taint
George D. Darling Ben Manny Barbara J. Tante
Noah Seth Davis Paulo Cesar Marcondes E. Frank Testa
James A. Dobbins Philip C. Marriott Richard H. Thayer
Irving Doshay Roger J. Martin J. Rush Thompson
David C. Doty Werner R. MaHersdorff Paul U. Thompson
Gene E. Dufoe Leroy M. May Terrence L. Tillmanns
Patricia W. Duggett Belden Menkus George W. Trever
Robert E. Dwyer Walter Merenda Henry J. Trochesset
John D.Earls Dennis F. Meronek C. L. Troyanowski
Leo G. Egan, Jr. Gene T. Morun William S. Turner, I11
Caroline L. Evans David G. Mullens David Usechak
John W. Fendrich Said Najafi R. L. Van-Tilbury
Glenn S. Fields Jainendra K. Navlakha Udo Voges
Heinz H. Frey Dennis E. Nickle Ralph Wachter
Edward L. Gibbs Olebernt Olavesen Andrew H. Weigel
Michael J. Gooding David E. Perr Paul A. Willis
Robert M. Gross Poul Grao Petersen David L. Winningham
Russell T. Gustin Donald J. Pfeiffer Charles Wortz
Vir1 E. Haas Patricia B. Powell Robert H. Yacobellis
Special representatives to the Software Engineering Standards Subcommittee were as follows:
H. R. Berlack Electronic Industry Association S. R. Jarocki: EDP Auditors Association
N. C. Farr: Nuclear Power Engineering Committee, J. Milandin: ANSI Z1
IEEE Power Engineering Society W. E. Perry: Data Processing Manufacturers Association
A. Ferlan: American Society for Quality Control T. L. Regulinski: IEEE Reliability Society

The working group that developed this standard had the following membership:

George D. Tice, Jr., Chairperson A. Frank Ackerman, Co-Chairperson

Alphonso J. Barr Eugene Gouldman Dennis E. Nickle


William Belke Joseph Guidos George O'Connell
Nestore G. Biasi Russel Gusten Robert M. Poston
Margaret Bornett Carolyn M. Harrison Patricia B. Powell
Vincent Boyer Joel Hebert Peter Ron Prinzivalli
Eric J. Braude George Heblinger Jane Radatz
Fletcher J. Buckley John Hoelzel Hans Reiche
Robert A. Burch Charles R. Hollocker Lenard B. Robertson
William Burns Robert Hood James Ronback
John Center John W. Horch Miney Roseberry
Richard Chilausky Philip Jacobs Hans Schaefer
Peter Clemens Laurel V. Kaleda Roger Scholten
Joan Colbert Myron S. Karasik David J. Schultz
James V. Dinkey Robert Kessler Robert W. Shillato
Paul Doyle Joseph J . Klock J. Michael Smith
Walter DuBlanica John S. Kopec Andi Stout
Robert L. Erickson Richard W. Kubica Barbara J. Taute
Charles Feather Robert Lane Nina C. Thomas
Arthur Ferlan Albert M. Lerner Don Thorne
David Gelperin Venetta Mallory William S. Turner, I11
Jean A. Gilmore Philip C. Marriott Donald Willett
Shirley Gloss-Soler Charles F. Martiny James Zoog
Edward Gonzales Gerald Neidhart

When the IEEE Standards Board approved this standard on September 19,1985, it had the following
membership:

John E. May, Chairman John P. Riganati, Vice Chairman


Sava I. Sherr, Secretary
James H. Beall Daniel L. Goldberg Lawrence V. McCall
Fletcher J. Buckley Kenneth D. Hendrix Donald T. Michael *
Rene Castenschiold Irvin N. Howell Frank L. Rose
Edward Chelotti Jack Kinn Clifford 0. Swanson
Edward J. Cohen Joseph L. Koepfinger. J. Richard Weger
Paul G. Cummings Irving Kolodny W. B. Wilkens
Donald C. Fleckenstein R. F. Lawrence Charles J. Wylie
Jay Forster

'Member emeritus
Contents
SECTION PAGE

1. Scope and References ................................................................................. 9


1.1 Scope ............................................................................................ 9
1.2 References ...................................................................................... 9
2. Definitions and Acronyms ............................................................................ 9
2.1 Definitions ...................................................................................... 9
2.2 Acronyms ....................................................................................... 10
3. Contents of a Software Quality Assurance Plan................................................... 10
3.1 Purpose ......................................................................................... 10
3.2 Reference Documents ......................................................................... 11
3.3 Management.................................................................................... 11
3.4 Documentation ................................................................................. 12
3.5 Standards, Practices, and Conventions ...................................................... 15
3.6 Reviews and Audits............................................................................ 16
3.7 Software Configuration Management ....................................................... 21
3.8 Problem Reporting and Corrective Action .................................................. 21
3.9 Tools, Techniques, and Methodologies ....................................................... 21
3.10 Code Control.................................................................................... 22
3.11 Media Control .................................................................................. 22
3.12 Supplier Control ............................................................................... 23
3.13 Records Collection, Maintenance, and Retention .......................................... 23
4. Implementation of a Software Quality Assurance Plan .......................................... 23
4.1 Acceptance by Management .................................................................. 24
4.2 Acceptance by Development Personnel ..................................................... 24
4.3 Planning for Implementation of the SQAP................................................. 24
4.4 Training......................................................................................... 24
4.5 Distribution of the SQAP ..................................................................... 25
4.6 Execution of the SQAP........................................................................ 25
5. Evaluation of a Software Quality Assurance Plan ................................................ 25
5.1 Purpose ......................................................................................... 25
5.2 Methodology .................................................................................... 25
6. Modification of the Software Quality Assurance Plan ............................................ 27
6.1 Purpose ......................................................................................... 27
6.2 Scope ............................................................................................ 27
6.3 Methodology .................................................................................... 27

FIGURES

Fig 1 Example of Relationships and Timing of Required Reviews and Audits..................... 17


Fig 2 Cause-Effect Graph of SQAP Evaluation and Modification ................................... 26

APPENDIX / APPENDIX TABLE

Table A1 Summary of SQAP Contents.................................................................. 29


IEEE Guide for Software Quality
Assurance Planning

1. Scope and References Secretary, IEEE Standards Board, for further


detailed guidance in this area.
1.1 Scope. The purpose of this guide is to ex-
1.2 References.
plain and clarify the contents of each section of
a Software Quality Assurance Plan (SQAP) that [l] ANSI / IEEE Std 729-1983, IEEE Standard
satisfies the requirements of ANSI / IEEE Std Glossary of Software Engineering Terminology.
730-1984 [2].l The guide does not constitute fur- [2] ANSI / IEEE Std 730-1984, IEEE Standard
ther requirements than those stated in ANSI/ for Software Quality Assurance Plans.'
IEEE Std 730-1984 [2]. An organization can
[3] ANSIIIEEE Std 828-1983, IEEE Standard
claim compliance with ANSI/IEEE Std 730-
for Software Configuration Management Plans.
1984 [2]without following completely, or in part,
this guide. [4] ANSI / IEEE Std 829-1983, IEEE Standard
This guide presents the current consensus of for Software Test Documentation.
those in the software development community [5] ANSIIIEEE Std 830-1984, IEEE Guide to
with expertise or experience in generating, im- Software Requirements Specifications.
plementing, evaluating, and modifying a SQAP.
Section 3 of this guide describes the content of
each section in a SQAP that satisfies ANSI/ 2. Definitions and Acronyms
IEEE Std 730-1984 [2]. Each subsection of Sec-
tion 3 quotes the applicable wording from the 2.1 Definitions. The definitions listed below es-
standard. Section 4 provides guidance for im- tablish meaning in the context of this guide.
plementing a SQAP on a software project, or Other definitions can be found in ANSIIIEEE
within a software development organization. Std 729-1983 [l] and ANSI/IEEE Std 730-1984
Section 5 provides guidance for evaluating the PI.
contents and the implementation of a SQAP. conventions. Requirements employed to pre-
Section 6 provides guidance for the procedures scribe a disciplined, uniform approach to pro-
used to modify an existing SQAP. The Appendix viding consistency in a softwareproduct, that is,
presents a summary of the contents of a SQAP. uniform patterns or forms for arranging data.
This guide is applicable to the development and
maintenance of all software, recognizing that practices. Requirements employed to prescribe
the application of these recommendations a disciplined, uniform approach to the software
should be tailored to the specific software prod- development process.
uct item. The user of this guide should be aware standards. Mandatory requirements employed
that efforts are underway to provide standards and enforced to prescribe a disciplined, uniform
and guides that cover many areas. Prior to im-
plementation, a check should be made with the
* ANSI / IEEE publications are available from the Sales
Department, American National Standards Institute, 1430
Broadway, New York, NY 10018, and the Institute of Elec-
The numbers in brackets correspond to those of the ref- trical and Electronics Engineers, Service Center, 445 Hoes
erences listed in Section 1.2. Lane, Piscataway, NJ 08854.

9
IEEE
Std 983-1986 IEEE GUIDE FOR SOFTWARE

approach to software development, that is, man- (4) Documentation


datory conventions and practices are in fact (5) Standards, Practices, and Conventions
standards. (6) Reviews and Audits
techniques. Technical and managerial proce- (7) Software Configuration Management
dures that aid in the evaluation and improve- (8) Problem Reporting and Corrective Action
ment of the software development process. (9) Tools, Techniques, and Methodologies
(10) Code Control
2.2 Acronyms. The following alphabetical con- (11) Media Control
tractions appear within the text of this guide: (12) Supplier Control
(13) Records Collection, Maintenance, and Re-
tention
CCB Change control board (in this doc-
ument refers to change control “Additional sections may be added at the end,
board for a SQAP) as required. Some of the material may appear
CDR Critical design review in other documents. If so, then reference to those
CI Configuration item documents should be made in the body of the
PDR Preliminary design review plan.” [21
SCM Software configuration manage- For example, portions of the required infor-
ment mation may be contained in a separate Software
SCMP Software configuration manage- Configuration Management Plan (SCMP) or in
ment plan a Software Development Plan (SDP). These sec-
SDD Software design description tions should reference those particular plans.
SDP Software development plan Those plans should be reviewed to ensure that
SPM Standards and procedures manual they provide all the required information.
SQA Soft,ware quality assurance
SQAP Software quality assurance plan 3.1 Purpose. “This section shall delineate the
SRR Software requirements review specific purpose and scope of the particular Soft-
SRS Software requirements specifica- ware Quality Assurance Plan (SQAP). It shall
tion list the name(s) of the software product items
SVVP Software verification and valida- covered by the SQAP and the intended use of
tion plan the software.’’ [2]
SVVPR Software verification and valida- The following questions should be addressed
tion plan review in this section:
SVVR Software verification and valida- (1) Which software products are covered by
tion report this SQAP? Specific names and abbreviations
UDR User documentation review should be supplied for these products.
(2) What is the intended use of the software
covered by this SQAP? How is the software to be
3. Contents of a Software Quality utilized? How critical is this software? Is it part
Assurance Plan of a larger system; if so, how is it related to the
system?
“The organization responsible for Software (3) Why is this SQAP being written? Is this
Quality Assurance shall prepare a Software Plan being written in response to a n internal or
Quality Assurance Plan (also referred to as the external requirement? Why is this SQAP
Plan) that includes the sections listed below. The needed?
sections should be ordered in the described se- (4) What documents form the basis of this
quence. If there is no information pertinent to SQAP? Describe the extent to which this SQAP
a section, the following statement shall appear is based on ANSI/IEEE Std 730-1984 [2]. Iden-
below the section heading. This section is not tify any other documents on which this SQAP
applicable to this plan, together with the appro- is based, eg, military or corporate quality as-
priate reasons for the exclusion. surance standards and guidelines.
(1) Purpose
(2) Reference Documents The quoted material appearing in this standard has been
(3) Management extracted from ANSIIIEEE Std 730-1984 [2].

10
IEEE
QUALITY ASSURANCE PLANNING Std 983-1986

(5) What is the rationale behind departures elements, the plan should explain its structure
from documents mentioned in 3.1(4)? Which and interrelationships.
product or development attributes warrant ad- A pictorial organizational structure should be
ditional or stricter practices or procedures? included with a written explanation amplifying
Which attributes warrant more lenient prac- the nature and degree of relationships with all
tices or procedures? organizational elements responsible for software
product quality and development. The written
explanation should include:
3.2 Reference Documents. “This section shall
provide a complete list of documents referenced (1) A description of each element which in-
elsewhere in the text of the plan.” [2] teracts with the SQA element
Clearly identify the sources from which the (2) Delegated responsibilities of interacting
documents can be obtained. elements
(3) Reporting relationships among the inter-
acting elements
3.3 Management. “This section shall describe
(4) Identification of the organizational ele-
the organization, tasks, and responsibilities.” [2]
ment with product release authority
Section 3.3.1 shall describe each major ele-
(5) Identification of the organizational ele-
ment of the organization which influences the
ment which approves the SQAP
quality of the software. Section 3.3.2 shall list
(6) The method by which conflicts are to be
the tasks covered by this plan. Section 3.3.3shall
resolved among the elements
identify specific organizational responsibilities
for each task. This description should also iden- The written explanation may also include:
tify the management position which retains
(7) The size of the SQA element
overall authority and responsibility for software
(8) An explanation of any deviations from or-
quality.
ganizational SQA policies, procedures, or stan-
3.3.1 Organization. “This paragraph shall
dards
depict the organizational structure that in-
fluences the quality of the software. This shall The description of the organizational struc-
include a description of each major element of ture should be complete so that all the tasks
the organization together with the delegated addressed in the SQAP can be directly related
responsibilities. Organizational dependence or to the structure.
independence of the elements responsible for 3.3.2 Tasks. “This paragraph shall describe
SQA from those responsible for software devel- the tasks associated with that portion of the soft-
opment and use shall be clearly described or ware life cycle covered by this plan with special
depicted.” [2] emphasis on software quality assurance activi-
The organizational element(s) responsible for ties. The sequence of the tasks shall be indi-
the software quality assurance functions cov- cated.” [2]
ered by the SQAP may be developers knowl- The basic tasks are described in 3.4 through
edgeable in quality assurance techniques and 3.13. All of the tasks in these sections may not
tools; a dedicated quality assurance element be applicable to a specific project, in which event
serving a number of projects; or a series of sep- they may be omitted. Any omissions or devia-
arate organizational elements, each of which im- tions from ANSI/IEEE Std 730-1984 [2] should
plements one or more SQA functional activities. be explained. Any additional tasks, along with
The SQAP should state the organizational and additional sections to the Plan, should be in-
functional boundaries of the SQA element. This cluded. Any deviations from corporate software
should not be construed to indicate that a spe- quality assurance policies should be explained.
cific SQA organization must be established nor This section of the SQAP should also designate
that a SQA organizational element must per- the personnel responsible for publication, dis-
form specific tasks. tribution, maintenance, and implementation of
If the SQA element is not attached to the soft- the SQAP.
ware development element, the plan should Each task should be defined with entrance and
state this clearly and explain any interrelation- exit criteria, that is, what is needed to initiate
ships that exist between these and other ele- the task, and what is the output of the task. The
ments. If the SQA element is attached to other output of each task should be defined in such a

11
IEEE
Std 983-1986 IEEE GUIDE FOR SOFTWARE

way that its achievement or completion can be used. If this information is provided in another
objectively determined in a prescribed manner. document, only a reference should be given. Or-
Additionally, this section could include a table ganizational policies, procedures, and standards
indicating the staffing levels for the listed tasks. may determine additional information require-
While it is strongly recommended that a Soft- ments.
ware Development Plan (SDP) (see 3.4.3.1) be 3.4.2 Minimum Documentation Require-
prepared, if an SDP is not available, this section ments. “To ensure that the implementation of
should provide schedule information outlining the software satisfies the requirements, the fol-
the development cycle. lowing documentation is required as a mini-
3.3.3 Responsibilities. “This paragraph mum ...” [2]
shall identify the specific organizational ele- ANSI/IEEE Std 730-1984 [2] requires the fol-
ments responsible for each task.” [2] lowing documents:
If two or more elements share responsibility
for a task, their respective responsibilities (1) Software Requirements Specification
should be identified. The management position (SRS)
accountable for overall software quality should (2) Software Design Description (SDD)
be identified. This section of the SQAP should (3) Software Verification and Validation Plan
also designate the personnel responsible for pub- (SWP)
lication, distribution, and maintenance of the (4) Software Verification and Validation Re-
SQAP. It should indicate the review and ap- port (SWR)
proval cycle, indicating signature authority as (5) User Documentation
required. It should show the number of con-
trolled copies and describe the method of control, These documents will provide the basis for a
if applicable. It should designate the personnel logical and systematic approach to the devel-
responsible for distributing the SQAP and de- opment and operation of the software. A brief
scribe the methods and responsibilities for the description of each document follows.
promulgation, approval, distribution, and incor- 3.4.2.1 Software Requirements Specifi-
poration of changes. cation (SRS). “The SRS shall clearly and pre-
cisely describe each of the essential re-
quirements (functions, performances, design
3.4 Documentation. “This section shall: constraints, and attributes) of the software and
the external interfaces. Each requirement shall
(1) Identify the documentation governing the
development, verification, and validation, use, be defined such that its achievement is capable
and maintenance of the software. of being verified and validated objectively by a
prescribed method, for example, inspection,
(2) State how the documents are to be checked
demonstration, analysis, or test.’’ [2]
for adequacy. The statement shall include iden-
tification of the review or audit by which the The SRS is usually developed from one or
more completed documents such as a user re-
adequacy of each document shall be confirmed,
quirements statement, operational require-
with reference to Section 6 of the Plan.” [2]
ments, statement of work, or contract. It
Section 6 of the Plan is discussed in 3.6 of this specifies in detail the requirements as agreed
guide. upon by the developer and the requester or user.
3.4.1 Purpose. The SQAP should identify the The SQAP should identify what standards or
documentation that will be prepared during the guides apply to the content and format Q f the
development, verification and validation, use, SRS. ANSI / IEEE Std 830-1984 [5] describes the
and maintenance of the software. The SQAP necessary content and qualities of an SRS.
should identify the organizational elements The SRS is subject to the Software Require-
responsible for the origination, verification, ments Review (SRR) described in 3.6.
maintenance, and control of the required doc- 3.4.2.2 Software Design Description
umentation. The SQAP should also identify the (SDD). “The SDD shall describe the major
specific reviews, audits, and associated criteria components of the software design including
required for each document, including refer- data bases and internal interfaces. An expan-
ences as appropriate to 3.6, Reviews and Audits. sion of this description shall be included to de-
The following subsections should describe the scribe each subcomponent of the major com-
format and content of each of the documents ponents.” [2]

12
IEEE
QUALITY ASSURANCE PLANNING SM 983-1986

The SDD is a technical description of how the The SQAP should identify which standards and
software will meet the requirements set forth in conventions apply to the content and format of
the SRS. Its most important function is to de- the SVVP. A section of the SVVP should include
scribe a decomposition of the system as a whole, a verification matrix where requirements are
into components (subsystems, segments, etc) listed with their corresponding SVVP section.
that are complete and well-bounded. The contents of the SVVP will be evaluated at
The SDD describes major system features such the Software Verification and Validation Plan
as data bases, diagnostics, external and internal Review (SVVPR) described in 3.6.
interfaces, and overall structure. It involves de- 3.4.2.4 Software Verification and Vali-
scriptions of the operating environment, moni- dation Report (SWR). “The SVVR shall de-
tors, timing, system throughput, tables, sizing, scribe the results of the execution of the SVVP.
modeling, etc. The SQAP should identify the This shall include the results of all reviews, au-
standards and conventions that apply to the con- dits, and tests required by the SQA plan.” [2]
tent and format of the SDD, as well as the pro- The SVVR summarizes the observed status of
cedures to be used in developing the SDD. the software as a result of the execution of the
The SDD is subject to the Preliminary Design SVVP. It outlines any major deficiencies found;
Review (PDR) and the Critical Design Review provides the results of reviews, audits, and tests;
(CDR) described in 3.6. indicates the status of planned corrective ac-
For each component in the system, the SDD tions; and should recommended whether the
should consist of items such as: software is, or is not, ready for operational use.
3.4.2.5 User Documentation. “The User
(1) A textural description of the component’s: Documentation (eg, manual, guide, etc) shall
(a) Inputs specify and describe the required data and con-
(b) outputs trol inputs, input sequences, options, program
(c) Calling sequence limitations, and other activities/ items neces-
(d) Function or task sary for successful execution of the software. All
(e) Algorithms error messages shall be identified and corrective
(2) A list of other components called actions described. A method of describing user-
(3) A list of all calling components identified errors / problems to the developer /
(4) Allowed and tolerable range of values for owner of the software shall be described.” [2]
all inputs The User Documentation should be composed
(5) Allowed and expected range of values for of the following items:
all outputs
(6) Assumptions, limitations, and side effects (1) User instructions which contain an intro-
duction, a description of the user’s interaction
3.4.2.3 Software Verification and Vali- with the system, and a description of any re-
dation Plan (SVVP). “The SVVP shall describe quired training for using the system (see, also,
the methods (for example, inspection, demon- Training Manual, 3.4.4.4)
stration, analysis, or test) to be used: (2) A system narrative purpose and descrip-
(1) To verify that tion
(a) The requirements in the SRS are imple- (3) Input / output specifications
mented in the design expressed in the SDD. (4) Samples of original source documents and
(b) The design expressed in the SDD is im- examples of all input formats (forms or displays)
plemented in the code. (5) Samples of all outputs (forms, reports, or
(2) To validate that the code, when executed, displays)
complies with the requirements expressed in the (6) Data entry instructions that contain in-
SRS.” [2] structions for data preparation, data keying,
data verification, data proofing, and error cor-
The SVVP describes the overall plan for the rection
verification and validation of the software. The (7) References to all documents or manuals
tasks, methods, and criteria for verification and intended for use by the users
validation are described. The SVVP specifies (8) A description of the system’s limitations
minimum test documentation requirements. (9) A description of all error situations which
ANSIIIEEE Std 829-1983 [4] may be consulted. can occur and how to react
IEEE
Std 983-1986 IEEE GUIDE FOR SOFTWARE

A User Documentation Review (UDR) is de- (7)Training Manual


scribed in 3.6.3.1 (8) Training Plan
3.4.3 Other Documentation. “Other docu-
3.4.4.1 User Requirements Statement.
mentation may include the following:
The User Requirements Statement should in-
(1)Software Development Plan clude, but is not limited to:
(2) Software Configuration Management Plan
(3) Standards and Procedures Manual.” [2] (1)A service request which contains the iden-
3.4.3.1 Software Development Plan tity of the requester, the software product name
(SDP). The SDP should identify all technical and title, the date the software product was re-
and managerial activities associated with com- quested and is required, a description of what
puter program development. The SDP should the software product should do, an abstract of
specify the following items: the need for the software product, privacy or
security considerations, and a list of potential
(1)Activity description users of the software product.
(2) Activity deliverables and associated com- (2) A list of the objectives that are to be sat-
pletion criteria isfied by the software product, as well as any
(3) Prerequisite deliverables from prior activ- other needs (administrative, timing, SQA, etc)
ities, if any and restraints the user perceives as necessary.
(4)Schedule and interrelationships among ac- (3) Any studies done to define resource re-
tivities quirements (ie, hardware, software, personnel,
(5) Assignment of responsibility for each ac- plant and facilities, or environmental), feasibil-
tivity ity, or cost-benefits analyses.
3.4.3.2 Software Configuration Manage-
ment Plan (SCMP).The SCMP should describe 3.4.4.2 External Interface Specification.
the methods to be used for: The External Interface Specification should con-
tain information about files and other intercon-
(1)Identifying the software configuration nections to all other software products outside
items the system to be developed. Consideration
(2) Controlling and implementing changes should be given to human interfaces, hardware
(3) Recording and reporting change imple- interfaces, environmental constraints, and files
mentation status or transactions coming from or going to other
(4)Conducting configuration audits systems.
The SCMP may be a separate document or a 3.4.4.3 Internal Interface Specification.
section of the SQAP. The ANSI/IEEE Std 828- The Internal Interface Specification should con-
1983 [3] provides minimum acceptable require- tain information about files and other intercon-
ments for the content of an SCMP. nections among all the components within the
3.4.3.3 Standards and Procedures Man- system. Consideration should be given to such
ual (SPM).The SPM should provide details on subjects as transfer of control between modules,
standards and procedures to be followed for spe- passing of data between modules, physical in-
cific activities. As a minimum, the ihformation terfaces, and common data bases.
described in 3.5 should be included. 3.4.4.4 Operations Manual. The Opera-
3.4.4 Additional Suggested Documenta- tions Manual should be composed of at least the
tion. The attributes, context, and environment following items:
of the product could dictate inclusion of addi- (1) Operating instructions that contain:
tional documents, such as but not limited to the (a) An introduction
following: (b) Run schedules
(c) Setup requirements
User Requirements Statement (d) Job control procedures
External Interface Specification (e) Error procedures
Internal Interface Specification (0 Security procedures
Operations Manual (g) Distribution procedures
Installation Manual (h) Backup and recovery procedures
Maintenance Manual (i) Restart procedures

14
IEEE
QUALITY ASSURANCE PLANNING Std 983-1986

(2) Specifications for the system, including en- 3.5.1 Purpose. This section of the SQAP
vironmental requirements should identify the standards, practices, and con-
(3) Input / output specifications ventions to be employed and specify the phases
(4) Auditing controls of the life cycle to which they apply. It should
also indicate which individual or organizational
3.4.4.5 Installation Manual. An Installa- element will be responsible for the enforcement,
tion Manual should contain instructions for the evaluation, and maintenance of the standards,
installation of the software product, file conver- practices, and conventions, and specify how com-
sion instructions, use of user-controlled instal- pliance will be monitored and assured.
lation options, and instructions for performing 3.5.2 Content of Sections. “The subjects cov-
an installation test. ered shall include the basic technical, design,
3.4.4.6 Maintenance Manual. A Mainte- and programming activities involved, such as
nance Manual should contain instructions for documentation naming and coding, program-
software product support and maintenance, such ming languages, and unit testing. As a mini-
as procedures for correcting defects and instal- mum, the following information shall be
lation of enhancements. This document should provided:
refer to the Problem Reporting System (see 3.8)
(1) Documentation standards
and the SCMP (see 3.4.3.2).
(2) Logic structure standards
3.4.4.7 Training Manual. The Training
(3) Coding standards
Manual should contain information necessary (4) Commentary standards.” [2]
for training users and operators of the system.
It should contain, but is not limited to: The SQAP should reference or include a list-
(1) An introduction ing of the standards, practices, and conventions
(2) How to use the system to be used on the project. As a minimum, the
(3) Preparing input standards, practices, and conventions should ad-
(4)Data input descriptions dress requirements, design, implementation,
(5) Data control descriptions test, and documentation.
(6) How to run the system 3.5.2.1 Requirements. Specify the stan-
(7) Output distributions dards, practices, and conventions to be used
(8) Description of output data and interpre- during requirements analysis. Use formal
tations requirements statement languages, either tex-
tual or graphic, whenever possible. Provision
should be made for a scheme that uniquely iden-
3.4.4.8 Training Plan. The development of
tifies each requirement. This facilitates tracea-
software products that require complex or un-
bility during the subsequent phases.
familiar interactions with users and operators
3.5.2.2 Design. Specify the standards, prac-
should include a comprehensive plan for train-
tices, and conventions to be used during the pre-
ing. The Training Plan should include:
liminary design phase where the overall
(1) A description of the population to be structure of the software system is defined. Give
trained and the learning objectives for each pop- serious consideration to the use of graphic tech-
ulation niques and top-down design.
(2) An estimate of the amount of resoirces For detailed design, state what standards,
necessary for training development, deli very, practices, and conventions will be used for spec-
and time expenditures ifying the internal structure of each program
(3) Procedures for evaluating the effective- module, and the interfaces among them. Address
ness of the training and for making modifica- such matters as naming conventions and argu-
tions to the training plan ment list standards. Give serious consideration
to requiring the use of a program design lan-
3.5 Standards, Practices, and Conventions.
“This section shall: guage.
3.5.2.3 Implementation. Specify the stan-
(1) Identify the standards, practices, and con- dards, practices, and conventions to be used dur-
ventions to be applied. ing the implementation phase. Address such
(2) State how compliance with these items is topics as the end-use computer, programming
to be monitored and assured.’’ [2] language($, module size, declaration statement

15
IEEE
Std 983-1986 IEEE GUIDE FOR SOFTWARE

conventions, naming and labeling conventions, necessary changes have been identified and im-
component layout standards, and the use of plemented.
structured coding techniques (or structuring This section should identify the specific tech-
precompilers). Consider data conversion tech- nical and managerial reviews and audits to be
niques for new systems that are replacing old conducted with respect to the software devel-
ones. Standards for the inclusion of comment opment plans, schedules, and environment. It
statements should also be covered here. Use should describe the procedures to be used in the
standard support software and software tools conduct of reviews and audits, and it should
whenever possible or state reasons for the use identify the participants and their specific re-
of nonstandard support software and tools. sponsibilities. These review and audit proce-
3.5.2.4 Test. Specify the standards, practices, dures should identify specific responsibility for
and conventions to be used during the testing the preparation of a report upon the completion
phase. This includes unit, integration, system of each review. This section should identify by
and acceptance testing, as well as regression position or job title who is to prepare these re-
testing. ANSI / IEEE Std 829-1983 [4] describes ports, the report format, who is to receive the
an integrated set of test documents. reports, and associated management responsi-
Address criteria for test repeatability and test bilities. The review and audit procedures should
coverage such as testing every requirement, user also describe the follow-up actions to assure that
procedure, and program statement. Specify tech- the recommendations made during the reviews
niques for tracing the test coverage to the test and audits are properly implemented. This sec-
set. Indicate whether any support software will tion should indicate the interval of time between
be required, and state how and from where this performance of the review or audit and perform-
software will be obtained. ance of the follow-up. It should also identify
3.5.2.5 Documentation. Specify the stan- those responsible for performing follow-up ac-
dards, practices, and conventions to be used in tions.
preparing software documentation. Cite any ex- 3.6.2 Minimum Requirements. “As a mini-
ternal (eg, military, user, etc) standards with mum, the following reviews shall be conducted”:
which the documents must comply. Include any PI
standards, practices, and conventions which ap-
ply to the deliverable program source listings or (1) Software Requirements Review (SRR)
executable code. Include any standards, prac- (2) Preliminary Design Review (PDR)
tices, and conventions which apply to documen- (3) Critical Design Review (CDR)
tation for deliverable tools. (4) Software Verification and Validation Plan
Review (SVVPR)
3.6 Reviews and Audits. “This section shall: (5) Functional Audit
(6) Physical Audit
(1) Define the technical and managerial re-
(7) In-Process Audits
views and audits to be conducted.
(8)Managerial Reviews
(2) State how the reviews and audits are to be
accomplished.” [2] Tailoring or inclusion of additional reviews
and audits should be made as local, contractual,
3.6.1 Purpose. The software items pro- or project-specific conditions dictate.
duced by the software development effort should An example of the relationships and timing
be reviewed and audited on a planned basis to of these reviews and audits to the software ,de-
determine the extent of progress and to evaluate velopment process is presented in Fig l.
the technical adequacy of the work and its con- 3.6.2.1 Software Requirements Review
formance to system requirements. Technical re- (SRR).“The SRR is held to ensure the adequacy
views and audits should be conducted to evaluate of the requirements stated in the Software Re-
the status and quality of the software develop- quirements Specification.” [2]
ment effort and to assure the use of required The SRR is an evaluation of the Software Re-
documentation. Completion of audits provides quirements Specification (SRS). The SRR is con-
the basis for making decisions during the course ducted to assure the adequacy, technical
of software development. Completion of reviews feasibility, and completeness of the require-
provides assurance that design integrity is main- ments stated in the SRS. The SRR should eval-
tained, technical deficiencies are identified, and uate the SRS for the attributes required by
IEEE
QUALITY ASSURANCE PLANNING SM 983-1986

Typical Software
Development Phases Required SQA Audits
(per ANSI / IEEE Required Software Development and Reviews'2'
Std 729-1983 [11) Products (Documentation per 3.4.2) Der 3.6.2
Requirements SQAP") SRR
SRS In-Process Audit@]
svvP'4' SVVPR'4'
Managerial Review'31
Design Preliminary SDD PDR(5'
In-Process Audit
SDD CDR'5'
User Documentation"' UDR'51
Implementation Software items with documentation In-Process Audit
Test Test Documentation") Functional Audit
Installation Deliverable items
and SVVR Physical Audit
Che~kout'~'
Operation Products depend on scope of maintenance. Review depends
and Major modifications will have some or all of 3n scope of
Maintenance'" the above products. required products.

Fig 1
Example of Relationships and Timing of Required Reviews and Audits
NOTES:
This includes any referenced documents.
Results of these activities are reports that identify what was reviewed, the deficiencies found,
and conclusions. A report generated by a review meeting also includes recommendations as to
what needs to be done to resolve the deficiencies. (The items subject to review are the software
development products.)
(w In-process audits and managerial reviews are scheduled as required throughout the software
life cycle. For additional assistance see Section 5.
(4) The SVVP completion and SVVPR should be accomplished prior to the PDR.
A UDR may be held independently of other reviews or in conjunction with the PDR and
the CDR (a UDR is not an ANSI/IEEE Std 730-1984[2] requirement).
(6) Refer to ANSI! IEEE Std 829-1983[4].
(') In the event this phase is not utilized in the SQAP, move the required products and audit
to the test phase.
(*) This phase is in addition to typical software development phases to show that the SQA effort

can be an iterative process.

ANSI / IEEE Std 830-1984 [5] (unambiguous, pate. These may include software design, soft-
complete, verifiable, consistent, modifiable, ware test, software quality assurance, system
traceable, and usable during the operation and engineering, customers, users, marketing, man-
maintenance phase). The review assures that ufacturing, etc.
sufficient detail is available to complete the soft- The SQAP should indicate, but not be limited
ware design. to, the following items as review requirements
The SQAP should indicate the organizational for the SRR:
element responsible for conducting the SRR. All
organizational elements that contribute or are (1) Traceability and completeness of the re-
impacted by the requirements should partici- quirement from the next higher level specifi-

17
~

IEEE
Std 983-1986 IEEE GUIDE FOR SOFTWARE

cation (such as a system specification or user software as depicted in a preliminary version of


requirements specification) the Software Design Description.” [2]
(2) Adequacy of-rationale for any derived re- The PDR is held to evaluate the technical ad-
quirements equacy of the preliminary design before the be-
(3) Adequacy and completeness of algorithms ginning of detailed design. The review assesses
and equations the progress, consistency, and technical ade-
(4)Correctness and suitability of logic descrip- quacy of the selected design approach; checks
tions that may be warranted the design’s compatibility with the functional
(5) Compatibility of external (hardware and and performance requirements of the SRS; and
software) interfaces verifies the existence and compatibility of the
(6) Adequacy of the description of and ap- interfaces between the software, hardware, and
proach to the human-machine interface end users. The PDR is also conducted to deter-
(7) Consistency in the use of symbols and in mine that the preliminary SDD defines a suit-
the specification of all interfaces able software design that fulfills the re-
(8) Availability of constants and tables for cal- quirements contained in the SRS.
culations The SQAP should indicate the organizational
(9) Testability of the software requirements element responsible for conducting the PDR. All
(10) Adequacy and completeness of the veri- organizational elements that impose require-
fication and acceptance requirements ments or are impacted by the design should par-
(11) Completeness and compatibility of inter- ticipate in the review. These groups could
face specification and control documentation include system engineering, software develop-
(12) Freedom from unwarranted design detail ment, software test, software quality assurance,
the customers, users, etc.
Additional items to be considered as review The following items could be specified in the
requirements for the SRR could include: SQAP as review requirements for the PDR:
(1) All detailed functional interfaces with
(1)Trade-off and design studies that have ap- other software, system equipment, communica-
plicability for decisions on: tion systems, etc, for adequate identification of
(a) Data base design interface design and design solution adequacy
(b) Programming language usage (2) The software design as a whole, empha-
(c) Space allocation sizing allocation of software components to func-
(d) Operations system or executive design, tions, functional flows, storage requirements
or both and allocations, software operating sequences,
(2) The general description of the size and op- and the design of the data base
erating characteristics of all support software (3) An analysis of the design for compatibility
(eg, operational program, maintenance and di- with critical system timing requirements, esti-
agnostic programs, compilers, etc) mated running times, and other performance
(3) A description of requirements for the op- requirements
eration of the software and identification of (4)The human factor requirements and the
functional requirements such as functional sim- human-machine interfaces for adequacy and
ulation, environmental recording and analysis, consistency of design
exercise configuration, etc. (5) Testability of the design, such as the ex-
istence of data store and processes that support
The results of the review should be docu- behavior and state determination
mented in an SRR Report that identifies all de- (6) Test concepts, requirements, documenta-
ficiencies identified in the review and provides tion, and tools, for adequacy
a plan and schedule for corrective action. After (7) Technical accuracy and currency of all
the SRS is updated to correct any deficiencies, available test documentation and its compati-
it should be placed under configuration control bility with the test requirements of the SRS
to establish the baseline to be used for the soft-
ware design effort. The results should be documented in a PDR
3.6.2.2 Preliminary Design Review Report which identifies all deficiencies discov-
(PDR). “The PDR is held to evaluate the tech- ered during the review and a plan and schedule
nical adequacy of the preliminary design of the for corrective action. The updated preliminary

18
IEEE
QUALITY ASSURANCE PLANNING Std 983-1986

SDD document should be placed under config- deficiencies discovered during the review and a
uration control to establish the baseline for the plan and schedule for corrective actions. The
detailed software design effort. updated SDD document, when placed under con-
3.6.2.3 Critical Design Review (CDR). figuration control, establishes the baseline for
“The CDR is held to determine the acceptability coding.
of the detailed software designs as depicted in 3.6.2.4 Software Verification and Vali-
the Software Design Description in satisfying dation [Plan] Review (SVVPR). “The Soft-
the requirements of the Software Requirements ware Verification and Validation [Plan] Review
Specification.” [2] is held to evaluate the adequacy and complete-
The CDR is an evaluation of the completed ness of the verification and validation methods
Software Design Description (SDD). The CDR defined in the SVVP.” [2]
evaluates the technical adequacy, completeness, The SVVPR is an evaluation of the completed
and correctness of the detailed design of the soft- Software Verification and Validation Plan
ware before the start of coding. The purpose of (SVVP). Since the SVVP may be developed in-
the CDR is to evaluate the acceptability of the crementally, multiple reviews may be required.
detailed design, to establish that the detailed These reviews are held to assure that the veri-
design satisfies the requirements of the SRS, to fication and validation methods described in the
review compatibility with the other software SVVP are adequate and will provide complete
and hardware with which the product is re- evaluation data.
quired to interact, and to assess the technical, The SQAP should indicate the organizational
cost, and schedule risks of the product design. element responsible for conducting the Software
The SQAP should indicate the organizational Verification and Validation Plan Review. All
element responsible for conducting the CDR. All organizational elements that impose require-
other organizational elements that impose re- ments or are impacted by the SVVP should par-
quirements or are impacted by the design should ticipate. These groups could include system
participate. These groups could include system engineering, software development, software de-
engineering, software development, software sign, software test, software quality assurance,
test, software quality assurance, customers, customers, users, etc.
users, etc. The following items should be specified in the
The following items could be specified in the SQAP as the SVVPR requirement criteria:
SQAP as review requirements for the CDR:
(1) All verification and validation methods,
(1)The compatibility of the detailed design along with completion criteria to assure trace-
with the SRS ability to, and compatibility with, the functional
(2) Available data in the form of logic dia- and performance requirements expressed in the
grams, algorithms, storage allocation charts, SRS
and detailed design representations (eg, flow (2) Reports to adequately document results of
chart, program design language) to establish de- all reviews, audits, and tests based on the re-
sign integrity quirements listed in the SVVP
(3) Compatibility and completeness of inter- (3) Adequate descriptions of the software con-
face requirements figuration to be tested, including test support
(4) All external and internal interfaces, in- software and hardware
cluding interactions with the data base (4) Test plans and test designs to assure that
(5) Technical accuracy and currency of all all requirements are tested
available test documentation and its compati- (5)Test procedures and test cases to assure
bility with the test requirements of the SRS that test inputs and success criteria are ade-
(6) The requirements for the support and test quately defined and that test instructions are
software and hardware to be used in the devel- clear and concise
opment of the product (6) A test schedule identifying which tests are
(7) The final design, including function flow, to be done, when, and by whom
timing, sizing, storage requirements, memory The results of the review should be docu-
maps, data base, and other performance factors mented in an SVVPR Report which identifies
The results of the review should be docu- all deficiencies discovered during the review,
mented in a CDR Report which identifies all and which provides a plan and schedule for cor-

19
IEEE
Std 983-1986 IEEE GUIDE FOR SOFTWARE

rective action. The updated SVVP, when placed (2) Interface specifications (hardware and
under configuration control, establishes the software)
baseline for the software verification and vali- (3) Design implementations versus functional
dation effort. requirements
3.6.2.5 Functional Audit. “This audit is (4) Functional requirements versus test de-
held prior to the software delivery to verify that scriptions.” [2]
all requirements specified in the Software Re-
quirements Specification have been met.” [2] In-process audits of samples of the product
The Functional Audit compares the code with development items are held as required by the
the documented software requirements as stated SQAP. The SQAP should indicate the organi-
in the current SRS. Its purpose is to assure that zational element responsible for conducting the
the code addresses all, and only, the documented in-process audits. Software inspections may be
requirements stated in the SRS. included as part of the in-process audit activity.
The SQAP should indicate the organizational The objective is to verify the consistency of the
element responsible for the Functional Audit. product as it evolves through the development
The results are to be documented in the Func- process by determining that:
tional Audit Minutes, which identify all dis- (1) Hardware and software interfaces are con-
crepancies found and the plans for their sistent with design requirements in the SRS
resolution. (2) The functional requirements of the SRS
Input to the Functional Audit should consist are fully tested by the SVVP
Of:
(3) The design of the product, as the SDD is
(1) Software Requirements Specification evolving, satisfies the functional requirements
of the SRS
(SRS)
(2) Software Verification and Validation Re- (4) The code is consistent with the SDD
port (SVVR) The results of all in-process audits are mea-
(3) Software Verification and Validation Plan sures of how well the process is working. They
Review (SVVPR) Minutes should be documented in in-process audit re-
ports, which identify all discrepancies found and
3.6.2.6 Physical Audit. “This audit is held
the plans for their resolution.
to verify that the software and its documenta-
3.6.2.8 Managerial Reviews. “These re-
tion are internally consistent and are ready for
views are held periodically to assess the execu-
delivery.” [2]
tion of this [SQA] plan. These reviews shall be
The Physical Audit compares the code with
held by an organizational element independent
its supporting documentation. Its purpose is to
of the unit being audited, or by a qualified third
assure that the documentation to be delivered
party.” [2]
correctly describes the code.
The planned frequency and structure of the
The SQAP should indicate the organizational
managerial reviews should be stated in the
element responsible for conducting the Physical
SQAP. They should be conducted at the direction
Audit. The results of the Physical Audit are to
of an appropriate level of management indepen-
be documented in the Physical Audit Minutes
dent of the SQA effort.
which identify all discrepancies and the plans
A managerial review results in a statement
for tlieir resolution. Once the discrepancies have
as to the adequacy of the SQAP and its execu-
been resolved, the software can be delivered.
tion. Each review should be documented by a
Input to the Physical Audit should consist of:
report summarizing the review findings, includ-
(1) Software Design Description (SDD) ing any exceptions to the process stated in the
(2) Software products SQAP, and any recommended changes or im-
(3) Associated documentation provements.
Section 5 provides guidance for evaluating the
3.6.2.7 In-Process Audits. “In-process au- contents and the implementation of a SQAP.
dits of a sample of the design are held to verify 3.6.3 Other. Other reviews may also be con-
consistency of the design, including: ducted.
3.6.3.1 User Documentation Review
(1) Code versus design documentation (UDR). The UDR is held to determine the tech-

20
IEEE
QUALITY ASSURANCE PLANNING SM 983-1986

nical adequacy of the documentation approach be followed for reporting, tracking, and resolv-
and design as described in draft versions of the ing software problems.
User Documentation. (2) State the specific organizational respon-
The SQAP should indicate the organizational sibilities concerned with their implementation.”
element responsible for conducting the UDR. All PI
organizational elements that are affected or im-
pacted by the User Documentation should par- Problems encountered during software devel-
ticipate in the review. These groups may include opment or operation may result in defects in the
system engineering, software, development, soft- software, hardware, or operations. Because of
ware test, software quality assurance, cus- their diversity, the determination of the sources
tomers, users, etc. of a problem and its appropriate corrective ac-
The following items could be specified in the tion requires a centrally controlled system for
SQAP as the UDR requirement criteria: monitoring problems and determining systemic
causes.
(1) The methods used to validate that the soft- The purposes of a software problem reporting
ware product matches the user documentation and corrective action system are to:
(2) Test plans, test procedures, and test cases
to assure that all user documentation is tested (1) Assure that problems are documented, cor-
in conjunction with the software rected, and not forgotten
(2) Assure that problem reports are assessed
The UDR can be held independently of other for their validity
reviews or in conjunction with the Preliminary (3) Provide feedback to the developer and the
Design Review (PDR) and the Critical Design user on problem status
Review (CDR). (4) Provide data for measuring and predicting
The results of the review should be docu- software quality and reliability
mented in a UDR Report, which identifies all
deficiencies discovered during the review and These goals should be satisfied by the problem
which provides a plan and schedule for connec- reporting and corrective action system described
tive action. The updated user documentation in the SQAP.
should be placed under configuration manage- The SQAP should include methods to be used
ment prior to the physical audit described in to assure that reported software problems are
3.6.2.6. being properly controlled. The SQAP should de-
scribe the organizational element(s), provisions,
3.7 Software Configuration Management. and procedures for documenting, validating,
“This section shall document the methods to be tracking, and reporting the status of software
used for identifying the software product items, problems and the appropriate corrective action.
controlling and implementing changes, and re- Validating, tracking, and resolving software
cording and reporting change implementation problems require the coordination of various
status. This documentation shall either be pro- groups within the organization. The SQAP
vided explicitly in this section or by reference should specify the groups responsible for au-
to an existing software configuration manage- thorizing and implementing problem reporting
ment plan.” [2] and corrective actions. It should also identify the
The SQAP should describe the tasks and meth- point in the development process where gener-
odology required to assure that adequate Soft- ation of problem reports is to begin.
ware Configuration Management (SCM) pro-
cedures and controls are documented and are 3.9 Tools, Techniques, and Methodologies.
being implemented correctly. It is not necessary “This section shall identify the special software
that the SQA function prepare the Software Con- tools, techniques, and methodologies employed
figuration Management Plan (SCMP). on the specific project that support Quality As-
The material to be supplied in this section is surance, state their purposes, and describe their
specified in ANSI/IEEE Std 828-1983 [3]. use.” [2]
The SQAP shall identify the tools, techniques,
3.8 Problem Reporting and Corrective Ac- and methodologies to be used to support software
tion. “This section shall: quality assurance. It should list or reference
those tools, techniques, and methodologies
(1) Describe the practices and procedures to which are available, and those that need to be
IEEE
Std 983-1986 IEEE GUIDE FOR SOFTWARE

acquired or developed. The responsible organi- (7) Describes procedures for implementing a
zation(s) should also be identified. new version
3.9.1 Tools. SQA software tools aid in the 3.11 Media Control. “This section shall state
evaluation or improvement of software quality.
the methods and facilities to be used to protect
Typical tools include, but are not limited to, op- computer program physical media from unau-
erating system utilities, debugging aids, docu- thorized access or inadvertent damage or deg-
mentation aids, structuring preprocessors, file
radation.” [2]
comparators, structure analyzers, standards
Computer program media can be defined as
auditors, simulators, execution analyzers, per-
those media on which computer data are stored.
formance monitors, statistical analysis pack- Typically, the storage media are disks or tapes,
ages, test drivers, test case generators, and static but could include cards, diskettes, listings, or
or dynamic test tools.
other forms in which the data reside.
3.9.2 Techniques. SQA techniques are tech-
The media control methods and facilities
nical and managerial procedures that aid in the
should ensure that:
evaluation and improvement of software qual-
ity. Such techniques include standards, software (1) The software is stored and retrieval is
inspections, requirements tracing, requirements guaranteed
and design verification, reliability measure- (2) Offsite storage and retrieval are provided
ments and assessments, and rigorous or formal for critical software and copies of baselined code
logic analysis. (3) The software is accessible only to those
3.9.3 Methodologies. SQA methodologies are with the need of access
integrated sets of the above techniques. (4) The environment is controlled so that the
physical media on which the software is stored
3.10 Code Control. “This section shall define do not degrade
the methods and facilities used to maintain and
store controlled versions of identified software. The SQAP should reference or specify proce-
This may be implemented in conjunction with dures and practices that pertain to the above
a Computer Program Library.” [2] items. For example, a backup procedure for soft-
Code control can be interpreted as the ways ware could indicate the schedule for backup,
and means necessary to protect or ensure the the type of media on which it will be placed, the
validity of a completed code. Once a n appropri- location of the storage, the environment of
ate baseline has been established, the code the storage area, and the method to retrieve the
should be placed under configuration manage- backed-up software. A security system may be
ment in a computer program library. The SQAP in place that allows access to software only
should specify controls and security measures through an authorization process. The SQAP
for software change and for protection from in- should delineate the organizational elements re-
advertent alteration after the code has been sponsible for administering and reviewing me-
baselined. It should define or reference the pro- dia control methods and facilities. The method
cedures and organizational responsibility for for identifying, labeling, and data logging may
controlling the developed code. be the same in both code and media control.
The SQAP should specify a code control pro- 3.11.1 Unauthorized Access. Several meth-
cedure that: ods are available which will provide adequate
protection from unauthorized access of com-
(1) Defines the specific software to be con- puter program media. The primary method is
trolled to provide a permanent labeling or identification
(2) Describes a standard method for identi- scheme within the storage media. When the disk
fying, labeling, and cataloging the software or tape is used on a computer, this technique
(3) Lists the physical location of the software can provide adequate password control or access
under control protection. Other methods include a limited ac-
(4)Describes the location, maintenance, and cess program library, encryption, external
use of all backup copies markings, and proprietary statements identify-
(5) Describes procedures for distributing a ing a controlled program. The physical security
COPY of all media must also be considered.
(6) Identifies the documentation which is af- SQA activities to verify appropriateness and
fected by changes implementation of access procedures should be

22
IEEE
QUALITY ASSURANCE PLANNING Std 983-1986

documented in the SQAP. Areas of concern in- formed in conformance with established profes-
clude: identifying the programs requiring lim- sional practice and the customer’s requirements.
ited access, adherence to label and file re- The documents collected for legal or contractual
strictions, ensuring use of adequate external la- purposes should provide evidence that:
beling restrictions, and providing a controlled (a) The SQAP is being followed and con-
environment such as a program library. forms to the requirements of applicable stan-
3.11.2 Inadvertent Damage or Degrada- dards
tion, Damage or degradation of the media can (b) The software meets design intent and
be minimized by providing adequate configura- satisfies contractual requirements
tion management techniques, safe storage lo- (c) Corrective action is effective
cations such as fireproof vaults, and packaging (d) Testing has been performed in accord-
practices that are antistatic in design. Periodic ance with test plans.
reviews to ensure use of controlled environmen- (2) To provide historical or reference data that
tal and cataloging practices will minimize deg- could be used to discover long-term trends in the
radation of external or physical identification of organization’s development techniques. The doc-
the media. uments collected for historical or reference pur-
SQA activities to verify appropriateness and poses should be capable of providing data for
implementation of procedures to minimize me- productivity, quality, and methodology studies.
dia damage or degradation should be docu- The documents should provide sufficient design,
mented in the SQAP. implementation, and testing data so as to be
useful for future development.
3.12 Supplier Control. “This section shall state
the provisions for assuring that vendor-provided In addition to SQA documents, records should
and subcontractor-developed software meets es- include program media containing the exact ver-
tablished technical requirements. As a mini- sion of programs and materials used in perform-
mum, the supplier shall be required to prepare ing tests to assure test repeatability at any time
and implement a Software Quality Assurance in the future.
Plan in accordance with this standard.” [2] 3.13.2 Records Maintenance. The SQAP
This section of the purchaser’s SQAP should should specify the manner in which records will
specify: be kept, that is, hard copy, microfiche, etc. Also,
it should state how records will be stored to pro-
(1) The purchaser’s involvement with the sup- tect them from fire, theft, or environmental de-
plier’s SQA program terioration. The SQAP should provide for
(2) The purchaser’s procedures for auditing historical archiving if applicable.
the supplier’s conformance to ANSI/IEEE Std 3.13.3 Records Retention. The SQAP should
730-1984 [2] and the supplier’s SQAP (an option specify the length of retention for each type of
could be to provide for an independent auditor) record maintained. It is important to state in
(3) The actions available to the purchaser the SQAP when records should be retained and
should the supplier not be in conformance with when they should be destroyed.
ANSI/IEEE Std 730-1984 [2] and the supplier’s 3.13.4 Organizational Responsibilitieai The
SQAP SQAP should specify the organizational element
responsible for originating, collecting, maintain-
3.13 Records Collection, Maintenance, and ing, storing, and protecting records. The plan
Retention. “This section shall identify the SQA should also identify the authority for access to
documentation to be retained, shall state the records, and the responsibilities for changing,
methods and facilities to be used to assemble, purging, or destroying records. Information in
safeguard and maintain this documentation and this section shall be compatible and consistent
shall designate the retention period.” [2] with information shown in 3.3.2 and 3.3.3.
3.13.1 Records Collection. The type of rec-
ords to be collected are determined by the overall
objectives for record keeping. These objectives 4. Implementation of a Software
should be documented in the SQAP. Possible
Quality Assurance Plan
objectives are:
(1) To provide legal or contractual evidence The purpose of this section is to describe the
that the software development process was per- steps necessary for successfully implementing

23
IEEE
SM 983-1986 IEEE GUIDE FOR SOFTWARE

the SQAP that has been prepared for a specific 4.3 Planning for Implementation of the
project. The following items are discussed in this SQAP. Planning for SQAP implementation
section: comprises three aspects:
(1) Acceptance of the SQAP by management
(2) Acceptance of the SQAP by the software
(1) Identification of required resources
(2) Scheduling implementation resources
developers and others whose task responsibili-
(3) Assessing the risks involved
ties are defined in the SQAP
(3) Planning and scheduling of resources and
tasks for implementation of the SQAP 4.3.1 Resources. The four types of resources
(4) Training of personnel to implement the required to implement a SQAP are: personnel,
SQAP equipment, facilities, and tools. The quantity
(5) Distribution of the SQAP to implementors and quality of these resources should be made
and interfacing personnel known to the appropriate level of management.
(6) Execution of the SQAP The responsible element should identify the
job classifications and skill levels of the person-
nel required to implement and maintain the
4.1 Acceptance by Management. Manage- SQAP throughout the life of the project. It
ment acceptance and commitment to the SQAP should identify the hardware needed to imple-
should be obtained. This will provide the support ment the SQAP and to support it throughout
required for implementing the tasks defined. the project, as well as estimates of computer
This acceptance should include commitments for time and support required. It should also iden-
the budget and resources required to implement tify the facilities needed for storage of media
the SQA activities. and records. When resources are identified by
The SQAP should be coordinated with and an element other than the SQA element, the
agreed to by each unit of the organization having SQA element should verify compliance with this
responsibilities defined within the SQAP. Ac- task. The tools required for implementation
ceptance of the SQAP should be indicated on the should already have been identified in the SQAP
cover page by an approval signature of the per- itself.
son in charge of each unit. Implementation of 4.3.2 Scheduling. Once the resources in-
the SQAP can be effective only if all the actions volved in implementing a SQAP have been iden-
called for in the SQAP are performed with the tified, the next step is to establish a schedule
full support of management. for the implementation. For each task identified
in the SQAP, this schedule should identify the
4.2 Acceptance by Development Personnel. starting and completion dates for each required
It is essential to foster a spirit of cooperation resource. In a similar manner, a schedule should
between the personnel responsible for software be established for the development or acquisi-
development and the SQA activities. An effec- tion of any necessary support tools.
tive method of achieving this is to have the de- 4.3.3 Risk Assessment. The last element of
velopment personnel participate in the planning is risk assessment. It is essential to
preparation of the SQAP. This will tend to in- identify the level of risk (high, medium, or low)
crease their support of SQA in general, and of associated with the possible failure of each re-
the SQAP in particular. Preliminary drafts of quired task or the unavailability of each re-
the SQAP should therefore be circulated within source. This risk assessment should identify the
the development organization for review and resulting impact on other schedules and outline
comments. It may also be useful to hold walk- alternative actions available to mitigate the
throughs of the SQAP with all concerned per- risks.
sonnel. During this time they will be able to ask
questions directly of the authors of the SQAP, 4.4 Training. The need for training of person-
and to make their concerns and objections nel designated to perform the activities defined
known before the SQAP is officially published. in the SQAP should be assessed. Considerations
In this manner, the groundwork will be laid for for training should include the skills of assigned
cooperation and mutual support between all or- personnel; special tools, techniques, and meth-
ganizations responsible for activities required by odology that must be used; computer resources
the SQAP. that will be used; etc.

24
IEEE
QUALITY ASSURANCE PLANNING Std 983-1986

Existing training programs should be adapted These questions provide an overview of the state
or new training programs developed to meet the of the SQAP.
needs of the plan. Training sessions should be The evaluation of the use and management of
scheduled for personnel who will be assigned to the SQAP is an assessment of the specific proj-
carry out the tasks. This training should be com- ect’s implementation of the SQAP. Section 5.2.2
patible with the task schedules discussed in contains some suggestions for this ongoing ac-
4.3.2. tivity.
4.5 Distribution of the SQAP. A distribution 5.2 Methodology
list of all personnel who are to receive the final 5.2.1 SQAP Evaluation. The following ques-
approved copy of the SQAP should be prepared. tions should be asked in evaluating the overall
A copy of the published SQAP should then be approach of the SQAP:
distributed to each individual listed, with an at- (1)Are all the mandatory requirements per
tached sign-off sheet that is to be initialed by ANSI/IEEE Std 730-1984[2] addressed in the
the person receiving the SQAP and returned to SQAP?
the organization responsible for the SQAP’s pub- (2) Are all contractual and company SQAP
lication and distribution. standards addressed in the SQAP?
4.6 Execution of the SQAP. Once the SQAP (3)Does the SQAP specify compliance with
is distributed, the Software Quality Assurance any standards in addition to ANSI/IEEE Std
element shall assure that the tasks (eg, reviews 730-1984[Z]? If so, does the SQAP meet the re-
and audits) documented within the SQAP are quirements of those standards?
performed at the appropriate points in the life (4)Are all exceptions to mandatory require-
cycle. The SQAP will specify the activity to be ments noted and adequately justified?
performed, the person(s) performing the activity, (5) Is the content of the SQAP adequate to
and the results to be achieved. It will reference achieve its stated objectives?
other documents as necessary. Associated work Additional questions which can be used in sup-
papers of the reviews and audits must provide port of the evaluation of specific SQAP sections
sufficient evidence that the steps in the SQAP are:
have been performed and reviewed by the man- (1)Purpose
agement accountable for the SQAP. This will (a) Are the specific purpose and scope of the
permit an objective determination of how well SQAP described?
the SQA objectives have been met. (b) Are the software product items covered
by the SQAP completely described?
(c) Is the intended use of the software items
5. Evaluation of a Software Quality described?
Assurance Plan (2) Referenced Documents
(a) Are all documents referenced by the
5.1 Purpose. The SQA element should make SQAP listed in this section?
provision for periodic or on-going evaluation of (3)Management
the SQAP. Evaluating the SQAP involves ex- (a) Are the structures of all the organiza-
amining it from two different viewpoints: tions that influence the quality of the software
depicted?
(1) Evaluating the plan’s content (initially (b) Are the management activities com-
and after all revisions) pletely described?
(2) Evaluating the use and management of the (c) Are the tasks and responsibilities of the
SQAP organizations that influence the quality of the
software listed?
The evaluation of the SQAP’s content is an (4)Documentation
assessment of how the SQAP complies with (a) Does the section describe all necessary
ANSI/ IEEE Std 730-1984 [2], internal devel- software documentation?
opment and quality assurance standards, and (b) Does this section describe the method-
contractual documents. Evaluation of the com- ologies to be used for checking documentation
pleteness and applicability of the SQAP is fa- adequacy with reference to 3.6?
cilitated by the questions presented in 5.2.1. (c) Are the methodologies adequate?
IEEE
Std 983-1986 IEEE GUIDE FOR SOFTWARE

(5) Standards, Practices, and Conventions (11) Media Control


(a) Does this section identify all standards, (a) Does this section contain a description
practices, and conventions to be applied to the of all methods and facilities to be used for media
software? control?
(b) Are compliance and monitoring proce- (b) Are they adequate?
dures identified? (12) Supplier Control
(c) Are (a) and (b) adequate? (a) Are all procedures for interfacing be-
(6) Reviews and Audits tween each supplier's SQAP and this SQAP fully
(a) Does this section define all necessary re- described?
views and audits for the documentation de- (b) Are they adequate?
scribed in 3.4? (13) Records Collection, Maintenance, and Re-
(b) Are the methodologies for all reviews tention
and audits described? (a) Are all records collection, maintenance,
(c) Are (a) and (b) adequate? and retention procedures fully described?
(7) Software Configuration Management (b) Are they adequate?
(SCM)
(a) Does the SCM information in this sec- 5.2.2 Implementation Evaluation. At sev-
tion, or contained in a separate SCMP, conform eral points in the product life cycle, usually ma-
to ANSI/IEEE Std 828-1983 [3]? jor project milestones, the SQAP and its
(b) If the SCM / SCMP is not in conformance implementation should be evaluated by means
with ANSI / IEEE Std 828-1983[3], is it adequate of a managerial review. This will help assure
for this particular SQAP? that the project and its SQAP evolve together.
(8) Problem Reporting and Corrective Action As the project proceeds through the software life
(a) Does this section describe problem re- cycle, there are likely to be changes in the prod-
porting and corrective action procedures to be uct scope. As the development plan changes, the
used for this project? SQAP and its implementation should also be
(b) Does this section state specific organi- reviewed to determine if any changes are re-
zational responsibilities? quired.
(c) Are the procedures adequate? The'use of the SQAP should be evaluated in
(9) Tools, Techniques, and Methodologies terms of the tasks and responsibilities detailed
(a) Are all tools, techniques, and methodol- in the SQAP (3.3.2 and 3.3.3). This evaluation
ogies to be used for SQA purposes fully de- should review the status of each task and the
scribed? adequacy of the actions taken in terms of both
(b) Are they adequate? product quality results and the schedules ac-
(10) Code Control tually achieved for the tasks.
(a) Does this section contain a description
of all methods and facilities to be used for code 5.2.3 Evaluation Process Relationship. The
control? evaluation process will have a cause-effect
(b) Are they adequate? relationship as shown in Fig 2. A SQAP evalu-

Fig 2
Cause-Effect Graph of SQAP Evaluation and Modification

Evaluation Modification

I Implementation
Modification I
26
IEEE
QUALITY ASSURANCE PLANNING Std 983-1986

ation, whether formal or informal, may have the Steps (1)and (2) will be followed in all cases.
effect of causing SQAP modification or causing If a project SCM organization exists, then steps
an implementation evaluation. A SQAP modi- (3), (41, and (5) will be accomplished according
fication may necessitate a corresponding imple- to that organization’s procedures. If there is no
mentation modification. An implementation project SCM, then steps (31, (4), and (5) will be
evaluation may cause an implementation followed as described below.
change to bring the use and management into
compliance with the SQAP. 6.3.1 Identify Alternative Options. Changes
to a SQAP may be proposed from any of several
sources, such as project management, software
6. Modification of the Software development, system validation, configuration
Quality Assurance Plan management, quality assurance, or customer.
They could suggest different solutions to the
The previous section addressed the evaluation same problem. It is important to provide for the
of a SQAP and the determination of any nec- results of the SQAP evaluation process (see Sec-
essary changes to it. This section will describe tion 5) to be routed through all of these sources
a mechanism for implementing such changes. in order that each of their proposed solutions
6.1 Purpose. The purpose of this section is to may be presented and reviewed.
provide a method for modifying an existing 6.3.2 Recommend Proposed Change. A
SQAP. Only if there is a provision for systematic Change Control Board (CCB)should be organized
modification of a SQAP can its users have con- to review all alternative solutions and to deter-
fidence in its continued usability. mine a single recommended change (or set of
There are several reasons why a SQAP, once changes) which they believe best addresses the
approved and implemented, may subsequently acknowledged requirement. Depending upon the
need to be modified. First, the SQAP may con- frequency with which SQAP changes are pro-
tain deficiencies. Second, it may be necessary to posed, this CCB may be either a standing or an
adjust to changes in the environment of the ad hoc organization. It may be useful to set up
SQAP. For example, a new set of system re- such a group as a standing organization at the
quirements may require stricter or more de- time the SQAP is first published, if numerous
tailed testing to assure that they are satisfied. change requests are expected. When such re-
Third, changes in the management structure of quests become fewer and farther between, the
the project may make portions of the SQAP (eg, CCB may be converted to an ad hoc status.
reporting lines or sign-off authorities) obsolete. 6.3.3 Review Proposed Change. Once the
Finally, the advent of new technology may make CCB has agreed upon a proposed change, it
modification desirable, as for example, when should be sent to all interested or potentially
new SQAP tools or techniques must be incor- affected parties for their review and comments.
porated. This step is necessary to provide agreement be-
fore the change is published and distributed. The
6.2 Scope. This section addresses methods for CCB should have responsibility for evaluation
proposing, reviewing, and instituting modifica- and incorporation of comments received from
tions to a SQAP. It does not cover modifications the reviewers, and for approval or rejection of
to the manner in which the SQAP is used, man- the proposed change.
aged, or controlled; provisions for these are made 6.3.4 Incorporate Approved Change. If,
either within the SQAP itself or in project man- after studying the reviewers’ comments, the
agement directives. CCB approves the proposed change, it is incor-
6.3 Methodology. As with any document, there porated into the SQAP. Standard document con-
are five steps in the modification of a SQAP trol procedures should be employed here,
including editorial review, printing of change
pages, use of vertical bars to highlight added or
(1) Identify alternative options modified text, and control procedures to pre-
(2) Recommend proposed change serve previous versions of the document.
(3) Review proposed change 6.3.5 Release and Promulgate Change. A
(4) Incorporate approved change management official should be designated who
(5) Release and promulgate change will have sign-off authority on SQAP changes.

27
IEEE
Std 983-1986 IEEE GUIDE FOR SOFTWARE

Once this official has approved the change change. This responsibility should be assigned
page(s) for release, standard document distri- to the appropriate management official. At this
bution methods may be employed. Then, all that point, the evaluation process begins again (see
remains is to monitor the implementation of the Section 5).

28
Appendix
(This Appendix is not a part of IEEE Std 983-1986,IEEE Guide for Software Quality Assurance Planning.)

Table A1
Summary of SQAP Contents
- ---
ANSI /
IEEE
Std IEEE
'30-1984 Std
Item Shall Should May
-- PI 383-1986 Other Stds
Description of specific scope X 3.1
and purpose of SQAP
products covered by the X 3.1 3.10)
NAP
intended use X 3.1 3.1(2)
reason for SQAP X - 3.1(3)
base documents X - 3.1(4)
rationale for departures X - 3.1(5)
from base documents
Reference documents list X 3.2 3.2
Description of project and
plan management
Organization X 3.3.1 3.3.1
Tasks X 3.3.2 3.3.2
Responsibilities X 3.3.3 3.3.3
Identification of documents X 3.4 3.4
to be used for development,
verification, use, and
maintenance of the producb
covered by SQAP and how
they are to be evaluated
SRS X 3.4.2.1 3.4.2.1 ANSI /IEEE[830-1984
5 ]
SDD X 3.4.2.2 3.4.2.2
SWP X 3.4.2.3 3.4.2.3
SWR X 3.4.2.4 3.4.2.4
User Documentation X 3.4.2.5 3.4.2.5
SDP X 3.4.3(1) 3.4.3.1
SCMP X 3.4.3(2) 3.4.3.2 ANSI /IEEE[828-1983
3 ]
SPM X 3.4.3(3) 3.4.3.3
User Requirements X - 3.4.4.1
Statement
External Interface X - 3.4.4.2
Specification
Internal Interface X - 3.4.4.3
Specification
Operations Manual X - 3.4.4.4
Installation Manual X - 3.4.4.5
Maintenance Manual X - 3.4.4.6
Training Manual X - 3.4.4.7
Training Plan X - 3.4.4.8
Identification of Standards, X 3.5 3.5
Practices, and Conventions,
and statement of
compliance check methods
Documentation Standards X 3.5.2 3.5.2
Logic Structure Standards X 3.5.2 3.5.2
Coding Standards X 3.5.2 3.5.2
Commentary Standards X 3.5.2 3.5.2
Requirements Standards X - 3.5.2.1
Design Standards X - 3.5.2.2
Implementation X - 3.5.2.3
Standards

29
Table A1 (Continued)
ANSI f
IEEE
Std IEEE
730-1984 Std
Item Shal Should PI )83-1986 Other SMs
Test Standards X - 3.5.2.4 ANSI/ IEEE 829-1983 [4]
Documentation Standards X - 3.5.2.5
Definition of technical X 3.6.1 3.6
reviews and audits and
means of accomplishment
Conduct the following X 3.6.2 3.6.2
reviews:
SRR X 3.6.2.1 3.6.2.1 ANSI f IEEE 830-1984 [5]
PDR X 3.6.2.2 3.6.2.2
CDR X 3.6.2.3 3.6.2.3
SWPR X 3.6.2.4 3.6.2.4
Functional Audit X 3.6.2.5 3.6.2.5
Physical Audit X 3.6.2.6 3.6.2.6
In-Process Audits X 3.6.2.7 3.6.2.7
Managerial Reviews X 3.6.2.8 3.6.2.8
UDR 3.6.3.1
Definition of software X 3.7 3.7 ANSI f IEEE 828-1983 [3]
product item control
procedures
0 Document methods for X 3.7 3.7 ANSI / IEEE 828-1983 [3]
identification of software
product items, change
control, and change
reporting
Discussion of problem X 3.8 3.8
reporting and corrective
action
Describe tools, techniques X 3.9 3.9
and methodologies to be
used
Definition of code control X 3.10 3.10
methods and facilities
Definition of media control X 3.11 3.11
methods and facilities
Unauthorized access X 3.11 3.11.1
Damage and degradation X 3.11 3.11.2
Provision for supplier X 3.12 3.12
quality assurance methods
Identification of software X 3.13 3.13
SQA records collection,
maintenance, and retention
Document record types X - 3.13.1
and objectives
Maintenance X 3.13 3.13.2
Retention period X 3.13 3.13.3
Organizational X - 3.13.4
responsibility
Implementing a SQAP X 4.0
e Evaluating a SQAP X 5.0
Modifying a SQAP X 6.0
-
- -
-

30
Acknowledgments
The following organizations provided support for the development of this standard:

AT&T Bell Laboratories NCR Corp


AT&T Information Systems Northern Telecom Limited
AT&T Technologies Northeast Utilities
Bell Canada Northrop Corp
B. L. Rosenberg and Co OASAS Limited
Boeing Aerospace Co Paradyne Corp
CAP Gemini f DASD Perkin Elmer
Central Institute for Industrial Research Planning Research Corp
Computer Sciences Corp Programming Environments, Inc
Cox Cable Communications Inc PRP Systems, Inc
Data General Corp Raytheon Data Systems
Defense Mapping Aerospace Center RCA
E-Systems, Inc SA1 Comsystems
EG&G Idaho, Inc Science Applications, Inc
Federal Aviation Agency Software Quality Engineering
General Electric CO Sperry
IBM Corp Tektronix, Inc
Itek Applied Technology Teledyne Brown Engineering
Lockheed Electronics Teledyne Geotech
Logicon, Inc Texas Instruments
Lord Electric Systems Time, Inc
Martin Marietta Engineering Systems Union Carbide Nuclear Division
McLaughlin Research, Inc US Air Force Communications Computer Programming Center
Medtronic, Inc US Army Computer Systems Command
National Bureau of Standards US Nuclear Regulatory Commission
Naval Air Development Center Veatch, Rich & Nadler
Naval Surface Weapons Center
Cl’his support does not constitute or imply approval or endorsement of this standard.)

31