The IEEE1was formed in 1963 when the American Institute of Electrical Engineers (AIEE) merged with the Institute of Radio Engineers (IRE). Its corporate headquar- ters is in New York City. Usually, an IEEE standard that is related to SQA is con- ceived and sponsored by the IEEE Computer Society and developed by the IEEE Standards Association (IEEE-SA). For more information about the standards pro- cess at IEEE, see the IEEE-SA Web site [26]. For more information about the Com- puter Society, see its Web site [27].
Second only to ISO standards, IEEE software engineering standards provide the most significant pool of requirements and guidance on software quality assurance. They can be purchased online at http://shop.ieee.org/ieeestore/ and http://webstore. ansi.org/ansidocstore/.
3.2.1 IEEE Std 730-2002
IEEE Std 730-2002 [28] provides “uniform, minimum acceptable requirements for preparation and content of software quality assurance plans.” It is written for use during a period when software is developed or maintained.
In clause 4, IEEE Std 730-2002 describes the minimum content of an SQA plan. Within the descriptions, the standard implicitly identifies core elements of the SQA process, because any activity that must be described in an SQA plan is a core soft- ware quality assurance activity that must at least be considered whenever SQA is implemented. An SQA plan might apply or cite requirements and guidance on soft- ware quality assurance in many other IEEE standards.
Using the standard as a guide, core SQA activities would include management, documentation, measurement, reviews, testing, problem reporting and corrective action, media control, supplier control, records management, training, and risk management. Indirectly, in its descriptions of related parts of the SQA plan, IEEE Std 730-2002 gives useful guidance about each of these activities. And additional, detailed guidance about many of the activities, for example documentation, soft- ware reviews, and SQA methods can be found in the IEEE software and systems engineering standards collection.
3.2 SQA in IEEE Standards 69
1. IEEE was formerly called The Institute of Electrical and Electronics Engineers, Inc., which is still its legal name at the time of this writing.
It is possible to make two different claims of conformance to this standard. A particular SQA plan can be said to be in conformance to the content of IEEE Std 730-2002 if the plan carries out all the requirements in the standard. They are all in clause 4. A requirement is indicated by the verb form “shall.” The plan can be said to be in conformance to the format of the standard if it has the format specified in clause 4 of the standard.
3.2.2 IEEE Std 829-1998
In clauses 4 through 11, IEEE Std 829-1998 [29] describes eight different documents that are associated with software testing. The documents are: test plan, test design specification, test case specification, test procedure specification, test item transmit- tal report, test log, test incident report, and test summary report. Each description explains the purpose of the document, and it outlines the structure of the document and clarifies the content of each section.
The eight document descriptions are written as requirements. The standard allows the content of each section of a document to be tailored “to the particular application and the particular testing phase” [29], by adding content, or reorganiz- ing sections, or adding other documents. But, the language in the standard suggests that tailoring may not delete (ignore) any of the required content.
Annex A of the standard gives useful examples of several testing documents. A reasonable person can interpret the language in the standard to require that every software item2that is tested must be accompanied by documents that jointly contain all of the eight different types of content that clauses 4 through 11 require. Although the standard does not define conformance, interpreting the standard in this way would mean that conformance to IEEE Std 829-1998 would be achieved when the required content is contained in one or more documents like the ones that clauses 4 through 11 describe, or in other documents that they reference.
Conformance to this standard could be a hidden, heavy burden for a project. So, binding agreements should invoke the standard with care. (Also, see Section 3.7.) 3.2.3 IEEE Std 1028-1997
IEEE Std 1028-1997 [30] models five different types of reviews: management reviews, technical reviews, inspections, walk-throughs, and audits. For each type, the standard specifies six different kinds of requirements: related to responsibilities, input, entry criteria, procedures, exit criteria, and output.
Annex B of the standard compares the different types of reviews to one another in very useful ways. And Annex A contains a very helpful table that maps review types in the standard to elements of ISO/IEC 12207:1995 [6].
A claim of conformance to IEEE Std 1028-1997 will be relative, always, only to a specific type of review. Conformance to the standard for a type of review, for example an inspection, is achieved when all the mandatory actions for the review type are carried out as the standard defines (mandatory actions are identified in
2. In this standard, “‘software item” means “source code, object code, job control code, control data, or a col- lection of these items.”
the standard by the use of “shall”). See Chapter 7 for a further elaboration on inspections.
3.2.4 The Special Role of IEEE/EIA 12207
IEEE/EIA 12207 [31–33] is a three-volume series that incorporates and extends ISO/IEC 12207:1995 [6]. This joint series by IEEE and EIA (see more about EIA below) provides the common terminology and framework of life-cycle processes that organize and relate the standards in the IEEE software and systems engineering standards collection. This is one of the ways that IEEE/EIA 12207 is special within IEEE standards.
3.2.4.1 IEEE/EIA 12207.0-1996 [31]
This standard contains the text of ISO/IEC 12207:1995,3but not the later amend- ments to the ISO standard. The major differences between IEEE/EIA 12207.0-1996 and ISO/IEC 12207:1995 include two additional, normative annexes that describe objectives to consider when interpreting what the standard says about software life-cycle processes and life-cycle data, and a different approach to compliance.
The standard contains a comprehensive set of processes that must be tailored for a particular situation and a particular purpose. The tailoring process in IEEE/EIA 12207.0-1996 is the same as the one in ISO/IEC 12207:1995. Its empha- sis on tailoring is a second way that the IEEE/EIA 12207 series is special within IEEE standards.4
Conformity to this standard is not defined. However, Annex F defines compli- ance. In F.1, compliance with IEEE/EIA 12207.0-1996 is “defined similarly” to the definition of compliance in ISO/IEC 12207:1995. Clause F.2 adds compliance con- ditions related to the situation—whether compliance is claimed for an organization, a project, a multisupplier program, or to comply with regulatory decisions. Clause F.3 defines two different levels of compliance, tailored and absolute. Clause F.4 adds two different sets of criteria for performing a life-cycle process in the standard that was selected by the tailoring process: accomplishment “as specified,” and accomplishment by an “alternative method.” A claim of compliance with IEEE/EIA 12207.0-1996 must contain all three elements: the situation (clause F.2), the selected level (clause F.3), and the chosen criteria (clause F.4).
3.2.4.2 IEEE/EIA 12207.1-1997 [32]
This volume is the guide to the information items (the life-cycle data) that IEEE/EIA 12207.0-1996 (the base standard) mentions. Altogether, more than 100 different information items are either required or recommended by the base standard.
3.2 SQA in IEEE Standards 71
3. The IEEE working group for the standard made only 12 minor corrections or changes to the text of the ISO standard. These are reported in Annex J.
4. IEEE/EIA 12207.2-1997 contains guidance about the tailoring process and about Annex F that would severely restrict the use of the tailoring process, for example, to the period after a contract is in place, or merely to interpreting language in the standard that refers to “the contract” (for an example, see task 5.2.5.6 in the standard). However, this guidance is not part of the conditions for compliance with IEEE/EIA 12207.0-1996.
Information items are listed alphabetically in Table 1 (in clause 4), which is the heart of this guide. For each item, Table 1 states where the item is mentioned in the base standard, and which kind, of seven different kinds of items—description, plan, procedure, record, report, request, or specification—it is.
For some items, Table 1 points to additional guidance such as a detailed outline within the guide or to additional sources of information outside the guide, such as to other IEEE standards. This suggests a third way in which the IEEE/EIA 12207 series is special within the collection of IEEE standards. Eventually, data described by the standards in the IEEE software and systems engineering standards collection will be harmonized with the IEEE/EIA 12207 series, in part by the mapping in Table 1 to the other IEEE standards, and, in part, by harmonization language (e.g., annexes) in the other standards.
Conformance to IEEE/EIA 12207.1-1997 is not defined. However, the volume contains a compliance clause that allows it to be used as a standard. When it is used as a standard, rather than merely as a guide, there are two different claims of compli- ance that can be made. First, one or more documents can be claimed to comply with one or more of the information items in Table 1 when they satisfy the characteristics that the related rows of the tables summarize. Second, an organizational process can be claimed to comply with IEEE/EIA 12207.1-1997 when each of the documents that it produces can be claimed to comply with one or more of the information items in Table 1.
3.2.4.3 IEEE/EIA 12207.2-1997 [33]
This volume is the guide to implementing the software life-cycle processes that IEEE/EIA 12207.0-1996 defines. In IEEE/EIA 12207.2, the normative text from the base standard has been updated by incorporating changes that are identified in Annex J (Errata) of IEEE/EIA 12207.0-1996.
Clause 5, clause 6, clause 7, and Annexes A through E repeat normative text in the base standard and add implementation guidance about selected topics. Annex A provides guidance about the tailoring process. Annex B provides guidance about compliance with IEEE/EIA 12207.0-1996. Other annexes provide additional guidance.
Conformance is not defined, and compliance is not defined, with respect to this guide.