IEEE 1044-2009 en Classification for Software Anomalies (IEEE Computer Society)《软件不规则分类》.pdf

《IEEE 1044-2009 en Classification for Software Anomalies (IEEE Computer Society)《软件不规则分类》.pdf》由会员分享，可在线阅读，更多相关《IEEE 1044-2009 en Classification for Software Anomalies (IEEE Computer Society)《软件不规则分类》.pdf（25页珍藏版）》请在麦多课文档分享上搜索。

1、g44g40g40g40;#23#23#23g54g87g71;#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23

2、g140;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23

3、#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23g53g72g89g76g86g76g82g81;#23#23#23g82g73g44g40g40g40;#23#23#23g54g87g71;#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#2

4、3#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23

5、#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23g44g40g40g40g3g54g87g68g81g71g68g85g71g3g38g79g68g86g86g76g192g70g68g87g76g82g81g3g73g82g85g54g82g73g87g90g68g85g72g3g36g81g

6、82g80g68g79g76g72g86g44g40g40g40g3g38g82g80g83g88g87g72g85g3g54g82g70g76g72g87g92g54g83g82g81g86g82g85g72g71;#23#23#23g69g92;#23#23#23g87g75g72g54g82g73g87g90g68g85g72;#23#23#23;#23#23#23#23#23#23#23#23#23;#23#23#23g54g92g86g87g72g80g86;#23#23#23g40g81g74g76g81g72g72g85g76g81g74;#23#23#23g54g87g68g8

7、1g71g68g85g71g86;#23#23#23g38g82g80g80g76g87g87g72g72g44g40g40g40;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23g51g68g85g78;#23#23#23g36g89g72g81g88g72;#23#23#23g49g72g90;#23#23#23g60g82g85g78;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23g49g60;#23#23#23;#23#

8、23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23

9、#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#2

10、3;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23g56g54g36;#23#23#23;#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23g45g68g81g88g68g85g92;#23#23#23;#23#23#23#23#2

11、3#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23

12、#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23;#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23#23g55g48Authorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on January 29, 2010 at 05:12 from IEEE

13、Xplore. Restrictions apply. Authorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on January 29, 2010 at 05:12 from IEEE Xplore. Restrictions apply. IEEE Std 1044-2009 (Revision of IEEE Std 1044-1993) IEEE Standard Classification for Software Anomalies Sponsor Software +1 978 750 840

14、0. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center. Authorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on January 29, 2010 at 05:12 from IEEE Xplore. Restrictions apply. iv Copyri

15、ght 2010 IEEE. All rights reserved. Introduction This introduction is not part of IEEE Std 1044-2009, IEEE Standard Classification for Software Anomalies. This standard provides a uniform approach to the classification of software anomalies, regardless of when they originate or when they are encount

16、ered within the project, product, or system life cycle. Classification data can be used for a variety of purposes, including defect causal analysis, project management, and software process improvement (e.g., to reduce the likelihood of defect insertion and/or to increase the likelihood of early def

17、ect detection). Collecting the data described in this standard provides valuable information that has many useful applications. It is also well documented that the earlier within the software life cycle a problem is discovered, the cheaper, and often easier, it is to fix. This encourages the use of

18、tools, techniques, and methodologies to find problems sooner. Standard anomaly data are necessary to evaluate how well these tools, techniques, and methodologies work. These data can also identify when in a projects life cycle most problems are introduced. Distinctions between enhancements and probl

19、ems in the software help make the decisions as to which anomalies are addressed first, categories of funding, and so on. Anomaly data can also assist in the evaluation of quality attributes such as reliability and productivity. Having a standard way of classifying software anomalies is important. Fi

20、rst, it enables insight into the types of anomalies that organizations produce during development of their products. This information is a rich source of data that can be used during the execution of a project and for process improvement. Analytical techniques such as Orthogonal Defect Classificatio

21、n and causal analysis depend on classification of anomalies to identify root causes and to help determine means to prevent their recurrence. Process improvement frameworks such as Capability Maturity Model Integrated (CMMI)apromote the need for detailed understanding of process performance and produ

22、ct quality. The classification of anomalies allows the development of profiles of anomalies produced by various development processes as one indicator of process performance. Second, having a standard way to classify anomalies enables better communication and exchange of information regarding anomal

23、ies among developers and organizations. Unfortunately, people frequently associate different meanings with the same words and/or use different words to mean the same thing. Similarly, if software systems are to communicate (i.e., exchange data) effectively regarding anomalies, they must share a comm

24、on logical (if not physical) data model. Data exchange may still be possible via some mapping or translation method if the same data elements are named differently in one system as compared with another, but each system must at least recognize and implement the same conceptual objects/entities, rela

25、tionships, and attributes. This standard is based on several concepts and definitions that must be clearly understood prior to its use. These are discussed briefly in the following paragraphs. Formal definitions can be found in Clause 2, and it is advisable to read them before proceeding. The word “

26、anomaly” may be used to refer to any abnormality, irregularity, inconsistency, or variance from expectations. It may be used to refer to a condition or an event, to an appearance or a behavior, to a form or a function. The 1993 version of IEEE Std 1044TMcharacterized the term “anomaly” as a synonym

27、for error, fault, failure, incident, flaw, problem, gripe, glitch, defect, or bug, essentially deemphasizing any distinction among those words. Such usage may be common practice in everyday conversation where the inherent ambiguity is mitigated by the richness of direct person-to-person communicatio

28、n, but it is not conducive to effective communication by other (especially asynchronous) methods. Because a term with such a broad meaning does not lend itself to precise communication, more specific terms are defined and used herein to refer to several more narrowly defined entities. Each entity ha

29、s associated with it a name, a aCMMI and Capability Maturity Model Integrated are registered trademarks in the U.S. Patent however, a brief description of each is provided below the corresponding diagram. Text descriptions of the relationships are available in Table 1, so a complete understanding of

30、 the diagrams is not essential to understanding this standard. The entities “Failure,” “Defect,” and “Fault” within the area labeled “IEEE 1044 Scope” in Figure 1 and Figure 2 are the subject of this standard, and the other entities in the diagrams are outside the scope of this standard. Faults are

31、considered a subtype of defect and as such are classified using the same attributes as defects (see Table 4). To increase flexibility and allow organizations to adapt the classification to their own life cycles and purposes, the following changes have been made to the previous edition of this standa

32、rd: Defining key terms and the relationships between their underlying concepts more precisely Not specifying a mandatory set of values for anomaly attributes Not specifying a classification process Several concepts and definitions must be clearly understood before using this standard, so it is highl

33、y advisable to review 1.1 and Clause 2 carefully before proceeding to Clause 3. The classification attributes defined in the standard are normative (mandatory), whereas the sample classification attribute values are only informative (optional). Notice to users Laws and regulations Users of these doc

34、uments should consult all applicable laws and regulations. Compliance with the provisions of this standard does not imply compliance to any applicable regulatory requirements. Implementers of the standard are responsible for observing or referring to the applicable regulatory requirements. IEEE does

35、 not, by the publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents may not be construed as doing so. Copyrights This document is copyrighted by the IEEE. It is made available for a wide variety of both public and private uses. These i

36、nclude both use, by reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering practices and methods. By making this document available for use and adoption by public authorities and private users, the IEEE does not waive any rights in c

37、opyright to this document. Updating of IEEE documents Users of IEEE standards should be aware that these documents may be superseded at any time by the issuance of new editions or may be amended from time to time through the issuance of amendments, corrigenda, or errata. An official IEEE document at

38、 any point in time consists of the current edition of the document together with any amendments, corrigenda, or errata then in effect. In order to determine whether a given document is the current edition and whether it has been amended through the issuance of bUML is a registered trademark in the U

39、.S. Patent the absence of the circle indicates at least one is required (i.e., participation is mandatory). The three-legged “crows feet” symbol indicates that many entities are permitted to participate; the absence of the crows feet symbol indicates that no more than one entity may participate. A r

40、ounded rectangle appearing within another rounded rectangle indicates a parentchild relationship, wherein the contained entity is a subtype of the containing entity (supertype). The relationships represented graphically in this diagram are further described in Table 1. NOTE 2 This diagram is not int

41、ended to mandate a particular notational methodology, and it is not intended as a schema for a database. Figure 1 Relationships modeled as an entity relationship diagram Authorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on January 29, 2010 at 05:12 from IEEE Xplore. Restrictions

42、apply. IEEE Std 1044-2009 IEEE Standard Classification for Software Anomalies 3 Copyright 2010 IEEE. All rights reserved. FaultDefectFailureProblem010*0*0*Software Change Request (SCR)Corrective SCRAdaptive SCRPerfective SCR011Software Release1*01IEEE 1044 ScopeNOTE 1 The rectangles represent object

43、 classes (things of interest), and the lines connecting the rectangles represent relationships between classes. The three sections within each rectangle contain (from top to bottom) the name, attributes, and methods/operations of the corresponding class. Because the primary focus of this diagram is

44、the relationships, only the class name is included. The methods are outside the scope of this standard, and the attributes are listed and defined in the clauses that follow. The numbers beside the lines indicate the multiplicity of the relationship, with “1” meaning exactly one, “01” meaning zero or

45、 one, “1*” meaning one or more, and “0*” meaning zero, one, or more. Lines with an open triangle on one end indicate a generalization (parentchild) relationship between a supertype class and the subtype class at the other end. Lines with a diamond at the end indicate that more than one change reques

46、t may be included in one release. The relationships represented graphically in this diagram are further described in Table 1. NOTE 2 This diagram is not intended to mandate a particular notational methodology, and it is not intended as a schema for a database. Figure 2 Relationships modeled as a UML

47、 class diagram Authorized licensed use limited to: IHS Stephanie Dejesus. Downloaded on January 29, 2010 at 05:12 from IEEE Xplore. Restrictions apply. IEEE Std 1044-2009 IEEE Standard Classification for Software Anomalies 4 Copyright 2010 IEEE. All rights reserved. Table 1 Relationships Class/entit

48、y pair Relationships Problem-Failure A problem may be caused by one or more failures. A failure may cause one or more problems. Failure-Fault A failure may be caused by (and thus indicate the presence of) a fault. A fault may cause one or more failures. Fault-Defect A fault is a subtype of the super

49、type defect. Every fault is a defect, but not every defect is a fault. A defect is a fault if it is encountered during software execution (thus causing a failure). A defect is not a fault if it is detected by inspection or static analysis and removed prior to executing the software. Defect-Change Request A defect may be removed via completion of a corrective change request. A corrective change request is intended to remove a defect. (A change request may also be initiated to perform adaptive or perfective maintenance.) The life cycle of a defect is depicted in Figure 3.