《IEEE-1044-1993-R2002.pdf》由会员分享，可在线阅读，更多相关《IEEE-1044-1993-R2002.pdf（32页珍藏版）》请在三一文库上搜索。
1、 The Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street, New York, NY 10017-2394, USA Copyright 1994 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 1994. Printed in the United States of America. ISBN 1-55937-383-0 No part of th
2、is publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. IEEE Std 1044-1993 IEEE Standard Classication for Software Anomalies Sponsor Software Engineering Standards Committee of the IEEE Computer Society Appr
3、oved December 2, 1993 IEEE Standards Board Abstract: A uniform approach to the classification of anomalies found in software and its documen- tation is provided. The processing of anomalies discovered during any software life cycle phase are described, and comprehensive lists of software anomaly cla
4、ssications and related data items that are helpful to identify and track anomalies are provided. This standard is not intended to dene pro- cedural or format requirements for using the classication scheme. It does identify some classica- tion measures and does not attempt to dene all the data suppor
5、ting the analysis of an anomaly. Keywords: anomaly, category, classification, classification process, supporting data item Copyright The Institute of Electrical and Electronics Engineers, Inc. Provided by IHS under license with IEEELicensee=IHS Employees/1111111001, User=OConnor, Maurice Not for Res
6、ale, 04/28/2007 20:25:32 MDTNo reproduction or networking permitted without license from IHS -,-,- Print: ISBN 1-55937-708-9, SH94399 PDF: ISBN 0-7381-0406-X, SS94399 IEEE Std 1044-1993(R2002) Reaffirmed September 11, 2002 IEEE Standards documents are developed within the Technical Committees of the
7、 IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Board. Members of the committees serve voluntarily and without compensation. They are not necessarily members of the Institute. The standards developed within IEEE represent a consensus of the broad expertise on the subj
8、ect within the Institute as well as those activities outside of IEEE that have expressed an interest in partici- pating in the development of the standard. Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, mea
9、sure, purchase, mar- ket, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users
10、 of the standard. Every IEEE Standard is subjected to review at least every ve years for revision or reafrmation. When a document is more than ve years old and has not been reafrmed, it is reasonable to conclude that its contents, although still of some value, do not wholly reect the present state o
11、f the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership afliation with IEEE. Suggestions for changes in docu- ments should be in the form of a
12、proposed change of text, together with appropriate supporting comments. Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specic applications. When the need for interpretations is brought to the attention of IEEE, the Institute will in
13、itiate action to prepare appro- priate responses. Since IEEE Standards represent a consensus of all concerned inter- ests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason IEEE and the members of its technical com- mittees
14、 are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE Standards Board 445 Hoes Lane P.O. Box 1331 Pisc
15、ataway, NJ 08855-1331 USA IEEE standards documents may involve the use of patented technology. Their approval by the Institute of Electrical and Electronics Engineers does not mean that using such technology for the purpose of conforming to such standards is authorized by the patent owner. It is the
16、 obligation of the user of such technology to obtain all necessary permissions. Copyright The Institute of Electrical and Electronics Engineers, Inc. Provided by IHS under license with IEEELicensee=IHS Employees/1111111001, User=OConnor, Maurice Not for Resale, 04/28/2007 20:25:32 MDTNo reproduction
17、 or networking permitted without license from IHS -,-,- iii Introduction (This introduction is not a part of IEEE Std 1044-1993, IEEE Standard Classication for Software Anomalies.) This standard provides a uniform approach to the classication of anomalies found in software and its documentation. It
18、describes the processing of anomalies discovered during any software life cycle phase, and it provides comprehensive lists of software anomaly classications and related data items that are helpful to identify and track anomalies. The minimum set of classications deemed necessary for a complete data
19、set are indicated as mandatory. More detailed classications are provided for those projects that require more rigor. These lower levels of detail are shown as optional. Application of less than the mandatory set of classications is not recommended as this may result in insufcient detail for meaningf
20、ul data collection and analysis. Some guidelines on how to apply the standard are provided in 4.1. In addition, annex A provides an example anomaly reporting mechanism that describes how to apply the classication scheme. The classication scheme in this standard considers the environment and activity
21、 in which the anomaly occurred, the symp- toms of the anomaly, the software or system cause of the anomaly, whether the anomaly is a problem or an enhancement request, where the anomaly originated (by phase and document), the resolution and disposition of the anomaly, the impact of several aspects o
22、f the anomaly, and the appropriate corrective action. Collecting the data described in this standard provides valuable information that has many useful applica- tions. Software is usually the most expensive item in computer systems. It is also well documented that the earlier within the software lif
23、e cycle a problem is discovered, the cheaper it is to x. This encourages the use of tools, techniques, and methodologies to nd problems sooner. Standard anomaly data is necessary to eval- uate how well these tools, techniques, and methodologies work. This data can also identify when in a projects li
24、fe cycle most problems are introduced. Distinctions between enhancements and problems in the software help make the decisions as to which anomalies are addressed rst, category of funding, etc. Anom- aly data can also assist in the evaluation of reliability and productivity measures. At the time this
25、 standard was completed, the Classication Standards Working Group had the following membership: Richard Evans, Chair Cynthia Brehmer, Co-chair Jaya Carl, Secretary John B. BowenMyron LipowDavid Simkins Lynn K. BrodersonMary MikhailVijaya Srivastava Linda ClemensPatricia PrattTheodore Sullivan Richar
26、d J. GaleDavid SchuckerGreg Ward Copyright The Institute of Electrical and Electronics Engineers, Inc. Provided by IHS under license with IEEELicensee=IHS Employees/1111111001, User=OConnor, Maurice Not for Resale, 04/28/2007 20:25:32 MDTNo reproduction or networking permitted without license from I
27、HS -,-,- iv The following persons were on the balloting committee: A. Frank AckermanAnne GeraciGeraldine Neidhart Eleanor AntreassianJean A. GilmoreDennis Nickle Bruce M. BakkenShirley A. Gloss-SolerMichael T. Perkins Jack N. BarnardPaul GrizenkoWilliam E. Perry Boris BeizerL. M. GuntherRon Pfaff H.
28、 R. BerlackVirl HaasDonald J. Pfeiffer Barry BoehmPeter J. HarveyJohn N. Postak Kathleen L. BriggsJohn HorchRobert M. Poston Christian BrunelleLaurel V. KaledaJock Rader Fletcher J. BuckleyAdi KasadArthur S. Robinson Elliot J. ChikofskyR. A. KesslerFrances A. Ruhlman Jung K. ChungTom KuriharaMargare
29、t Rumley Francois CoallierLak-Ming LamNorman Schneidewind Stewart CrawfordJohn B. LaneLeonard W. Seagren Patricia W. DaggettRobert A. LaneHarlan K. Seyfer James DobbinsF. C. LimAnthony F. J. Sgarlatti David DotyBen LivsonRobert W. Shillato William P. DuprasDonald LundryJacob Slonim Robert E. DwyerAu
30、stin J. MaherWayne Smith Kenneth DymondKartik C. MajumdarTerrence L. Tillmanns Caroline L. EvansDavid M. MarksDavid B. Turner James R. EvansPhilip C. MarriottWilliam Stephen Turner John W. FendrichDarrell MarshRalph Wachter Glenn S. FieldsGlen A. MeldrumDolores R. Wallace Violet FoldesEdward F. Mill
31、erJohn P. Walter Kenneth A. FosterCelia H. ModellAndrew H. Weigel Richard FriesGary D. MoorheadBill Wong David GelperinGene T. MorunDennis L. Wood Robert C. Natale When the IEEE Standards Board approved this standard on December 2, 1993, it had the following membership: Wallace S. Read, Chair Donald
32、 C. Loughry, Vice Chair Andrew G. Salem, Secretary Gilles A. BarilJim IsaakDon T. Michael* Jos A. Berrios de la PazBen C. JohnsonMarco W. Migliaro Clyde R. CampWalter J. KarplusL. John Rankine Donald C. FleckensteinLorraine C. KevraArthur K. Reilly Jay Forster*E. G. Al KienerRonald H. Reimer David F
33、. FranklinIvor N. KnightGary S. Robinson Ramiro GarciaJoseph L. Koepnger*Leonard L. Tripp Donald N. HeirmanD. N. Jim LogothetisDonald W. Zipse *Member Emeritus Also included are the following nonvoting IEEE Standards Board liaisons: Satish K. Aggarwal James Beall Richard B. Engelman David E. Soffrin
34、 Stanley I. Warshaw Rachel A. Meisel IEEE Standards Project Editor Copyright The Institute of Electrical and Electronics Engineers, Inc. Provided by IHS under license with IEEELicensee=IHS Employees/1111111001, User=OConnor, Maurice Not for Resale, 04/28/2007 20:25:32 MDTNo reproduction or networkin
35、g permitted without license from IHS -,-,- v Contents CLAUSEPAGE 1.Overview 1 1.1 Background 1 1.2 Scope2 2.References2 3.Definitions3 4.Classification standard.4 4.1 Classification process.4 4.2 Standard classification scheme 6 Annex AExample anomaly report 24 Copyright The Institute of Electrical
36、and Electronics Engineers, Inc. Provided by IHS under license with IEEELicensee=IHS Employees/1111111001, User=OConnor, Maurice Not for Resale, 04/28/2007 20:25:32 MDTNo reproduction or networking permitted without license from IHS -,-,- IEEE Std 1044-1993IEEE STANDARD CLASSIFICATION vi Copyright Th
37、e Institute of Electrical and Electronics Engineers, Inc. Provided by IHS under license with IEEELicensee=IHS Employees/1111111001, User=OConnor, Maurice Not for Resale, 04/28/2007 20:25:32 MDTNo reproduction or networking permitted without license from IHS -,-,- 1 IEEE Standard Classication for Sof
38、tware Anomalies 1. Overview 1.1 Background This standard is based on several denitions, concepts, and processes that need to be understood prior to its use. These are discussed in the following paragraphs. Formal denitions can be found in clause 3. A key term in this standard is anomaly. An anomaly
39、is any condition that departs from the expected. This expectation can come from documentation (requirements specications, design documents, user documents, standards, etc.) or from someones perceptions or experiences. An anomaly is not necessarily a problem in the software product; it may be manifes
40、ting correct behavior in which case changing the software would be an enhancement. An anomaly may also be caused by something other than the software. For reasons of semantics, use of the word anomaly is preferred over the words error, fault, failure, incident, aw, problem, gripe, glitch, defect, or
41、 bug throughout this standard because it conveys a more neutral connotation. The methodology of this standard is based on a process (sequence of steps) that pursues a logical progres- sion from the initial recognition of an anomaly to its nal disposition. Each step interrelates with and sup- ports t
42、he other steps. This process is graphically displayed in gure 1, and a complete discussion of the classication process is in 4.1. This standard does not attempt to enforce any particular anomaly processing procedure other than to identify the basic processes an anomaly goes through. It is expected t
43、hat users will modify the process based on their organizations procedures. Subclause 4.2 describes the classication scheme and supporting data items useful for identifying, tracking, and resolving anomalies. Copyright The Institute of Electrical and Electronics Engineers, Inc. Provided by IHS under
44、license with IEEELicensee=IHS Employees/1111111001, User=OConnor, Maurice Not for Resale, 04/28/2007 20:25:32 MDTNo reproduction or networking permitted without license from IHS -,-,- IEEE Std 1044-1993IEEE STANDARD CLASSIFICATION 2 1.2 Scope This standard is applicable to any software, including cr
45、itical computer software, commercial applications, system software, support software, testware, and rmware during any phase of a systems life cycle. This standard denes the minimum requirements for classifying anomalies, as well as providing additional classi- cations for projects requiring greater
46、detail. The mandatory classications are the minimum requirements necessary to establish a standard terminology for anomalies within or between projects and organizations. To accomplish the classication task, this standard documents the following subjects: a)Denitions of terms not provided in IEEE St
47、d 610.12-1990 1 b)A basic process (sequence of steps) for classifying and establishing categories of anomalies relating to software products and providing related data and information c)A standard set of categories and classications, either mandatory or optional d)A list of supporting data items Thi
48、s standard identies those essential (mandatory) categories needed to establish a common denition. The categories provide a common terminology and concepts to communicate among projects, software develop- ment environments, and personnel. It is assumed that all applicable classications within a mandatory cate- gory shall be used for compliance to this standard. This standard also provides categories for additional detail that are not necessarily essential to all projects. These additional categories are identied as optional. This standard is n