《IEEE Std 1061-1998 IEEE Standard for a Software Quality Metrics Methodology.pdf》由会员分享，可在线阅读，更多相关《IEEE Std 1061-1998 IEEE Standard for a Software Quality Metrics Methodology.pdf（26页珍藏版）》请在三一文库上搜索。
1、The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright 2005 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 1995. Printed in the United States of America. IEEE is a registered trademark in the U.
2、S. Patent (978) 750-8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copyright Clearance Center. Note: Attention is called to the possibility that implementation of this standard may require use of subject mat- ter cover
3、ed by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents for which a license may be required by an IEEE standard or for conducting inqui
4、ries into the legal validity or scope of those patents that are brought to its attention. Authorized licensed use limited to: Tsinghua University Library. Downloaded on December 25,2010 at 10:43:03 UTC from IEEE Xplore. Restrictions apply. Copyright 1998 IEEE. All rights reserved. iii Introduction (
5、This introduction is not part of IEEE Std 1061-1998, IEEE Standard for a Software Quality Metrics Methodology.) History In February 1984, a project to develop a standard for a software quality metrics methodology was approved, and a working group was formed, because there was no existing IEEE standa
6、rd covering the eld of software quality metrics. In December 1992, the IEEE Standards Board approved IEEE Std 1061-1992. It was pub- lished by IEEE on 12 March, 1993. This was the rst IEEE standard that dealt with quality metrics. It is important that users of this standard understand that this is a
7、 process standard, and not a standard that mandates specic metrics for use. The philosophy of this standard is that an organization can employ which- ever metrics it deems most appropriate for its applications, as long as the methodology is followed and the metrics are validated. Another reason for
8、this approach is that there was no consensus on which metrics to mandate for use (the provisions of a standard are mandatory, not optional). Consistent with this approach was the Working Group charter, as provided in the IEEE Standards Board approval of the project authoriza- tion request (PAR), whi
9、ch called for a standard methodology to be developed. Due to the IEEE rule that a standard must be revised or reafrmed within ve years of issuance, a PAR for a revision was submitted and approved in 1998. The revision was reballoted and recirculated, and comments were resolved in 1998. The standard
10、obtained the necessary approval rate during balloting and was submit- ted to the IEEE-SA Standards Board, which approved it in December 1998. Purpose Software quality is the degree to which software possesses a desired combination of attributes. This desired combination of attributes shall be clearl
11、y dened; otherwise, assessment of quality is left to intuition. For the purpose of this standard, dening software quality for a system is equivalent to dening a list of software quality attributes required for that system. In order to measure the software quality attributes, an appropriate set of so
12、ftware metrics shall be identied. The purpose of software metrics is to make assessments throughout the software life cycle as to whether the software quality requirements are being met. The use of software metrics reduces subjectivity in the assess- ment and control of software quality by providing
13、 a quantitative basis for making decisions about software quality. However, the use of software metrics does not eliminate the need for human judgment in software evaluations. The use of software metrics within an organization or project is expected to have a benecial effect by making software quali
14、ty more visible. More specically, the use of this standards methodology for measuring quality allows an organization to Achieve quality goals; Establish quality requirements for a system at its outset; Establish acceptance criteria and standards; Evaluate the level of quality achieved against the es
15、tablished requirements; Detect anomalies or point to potential problems in the system; Predict the level of quality that will be achieved in the future; Monitor changes in quality when software is modied; Assess the ease of change to the system during product evolution; Validate a metric set. To acc
16、omplish these aims, both process and product metrics should be represented in the system metrics plan. Authorized licensed use limited to: Tsinghua University Library. Downloaded on December 25,2010 at 10:43:03 UTC from IEEE Xplore. Restrictions apply. iv Copyright 1998 IEEE. All rights reserved. Th
17、e following is a list of major changes from the previous edition: a)This revision elaborates on the context in which validation is to be interpretedvalidating metrics with respect to a quality factor (e.g., demonstrating a statistical relationship between a complexity metric and defect count for the
18、 purpose of predicting defects from complexity) for a given applica- tion as opposed to a universal validation of the metrics for all applications. An informative annex (Annex B of this standard), giving sample metric validation calculations, is also included. b)Due to the policy of the IEEE Softwar
19、e Engineering Standards Committee (SESC) to provide major informational items in the form of SESC approved books, as opposed to putting this information in standards, the annex that contained the case studies (Annex C of IEEE Std 1061-1992) has been deleted. In addition, due to legal and proprietary
20、 restrictions on the release of data when IEEE Std 1061-1992 was written, the working group was unable to obtain metric data from industry for the mission critical example. Therefore, it was necessary to use university metric data. Since the publi- cation of IEEE Std 1061-1992, data have become avai
21、lable from applications, such as the Space Shuttle, which will be used in a future book. The book could be used as a companion document to this standard. c)The annex that contained an informational item about metrics descriptions and results (Annex B of IEEE Std 1061-1992) has been deleted because m
22、any of the metrics and metrics application results are now obsolete. Examples of metrics will be included in the aforementioned book. d)The annex that contained example factors, subfactors, and metrics, and that described the relation- ships among them (Annex A of IEEE Std 1061-1992), has been delet
23、ed. The relationships among these are pictured in Figure 1 and discussed in Clause 3 of this standard. e)Obsolete references in the bibliography (Annex D of IEEE Std 1061-1992) have been deleted and a list of references (Clause 2 of this standard) has been added. The purpose of the references is to
24、point the user to additional information about key points in the standard. In accord with SESC policy, a metrics bibliography will be provided in a future SESC approved book. f)Due to the importance of the goal question metric (GQM) and the practical software measurement (PSM) frameworks, these fram
25、eworks have been included in an informative annex (Annex A of this standard). g)Normative and informative material have been better distinguished. Participants At the time this standard was completed, the Software Quality Metrics Methodology Working Group had the following membership: Norman Schneid
26、ewind, Chair Celia Modell, Editor Alain Abran Julie Barnard Dick Chiricosta J. Philippe Jacquet Kathy Liburdy Tomoo Matsubara Sandra Swearingen Leonard L. Tripp Stephanie White Authorized licensed use limited to: Tsinghua University Library. Downloaded on December 25,2010 at 10:43:03 UTC from IEEE X
27、plore. Restrictions apply. Copyright 1998 IEEE. All rights reserved. v The following members of the balloting committee voted on this standard: When the IEEE-SA Standards Board approved this standard on 8 December 1998, it had the following membership: Richard J. Holleman, Chair Donald N. Heirman, V
28、ice Chair Judith Gorman, Secretary *Member Emeritus Yvette Ho Sang IEEE Standards Project Editor Syed Ali H. Ronald Berlack Michael A. Blackledge Juris Borzovs James E. Cardow Enrico A. Carrara Keith Chan Antonio M. Cicu Rosemary Coleman W. W. Geoff Cozens Paul R. Croll Geoffrey Darnton Taz Daughtre
29、y Raymond Day Bostjan K. Derganc Perry R. DeWeese Harpal Dhama Evelyn S. Dow Sherman Eagles Leo G. Egan William Eventoff Richard E. Fairley John W. Fendrich Jay Forster Kirby Fortenberry Eva Freund Karol Fruehauf Roger U. Fujii Barry L. Garner Marilyn Ginsberg-Finner John Garth Glynn Julio Gonzalez-
30、Sanz Eric Grosse L. M. Gunther David A. Gustafson Jon D. Hagar John Harauz William Heey James H. Heil Mark Heinrich David Heron Debra Herrmann John W. Horch John O. Jenkins Frank V. Jorgensen Vladan V. Jovanovic William S. Junk George X. Kambic Diana Kang Chris F. Kemerer Ron S. Kenett Judith S. Ker
31、ner Robert J. Kierzyk Thomas M. Kurihara John B. Lane J. Dennis Lawrence Randal Leavitt Stanley H. Levinson William M. Lively Dieter Look John Lord Tom Lydon Stan Magee Tomoo Matsubara Patrick D. McCray James Bret Michael Alan Miller Celia H. Modell Charles S. Mooney James W. Moore Pavol Navrat Dona
32、ld J. Ostrom Indradeb P. Pal John G. Phippen Peter T. Poon Kenneth R. Ptack Annette D. Reilly Dennis Rilling Andrew P. Sage Helmut Sandmayr Stephen R. Schach Hans Schaefer Norman Schneidewind David J. Schultz Robert W. Shillato Lynn J. Simms Carl A. Singer Alfred R. Sorkowitz Luca Spotorno Julia Ste
33、sney Fred J. Strauss Sandra Swearingen Toru Takeshita Douglas H. Thiele Booker Thomas Patricia Trellue Leonard L. Tripp Glenn D. Venables Udo Voges Scott A. Whitmire Paul A. Wolfgang Paul R. Work Natalie C. Yopconka Janusz Zalewski Geraldine Zimmerman Satish K. Aggarwal Clyde R. Camp James T. Carlo
34、Gary R. Engmann Harold E. Epstein Jay Forster* Thomas F. Garrity Ruben D. Garzon James H. Gurney Jim D. Isaak Lowell G. Johnson Robert Kennelly E. G. Al Kiener Joseph L. Koepnger* Stephen R. Lambert Jim Logothetis Donald C. Loughry L. Bruce McClung Louis-Franois Pau Ronald C. Petersen Gerald H. Pete
35、rson John B. Posey Gary S. Robinson Hans E. Weinrich Donald W. Zipse Authorized licensed use limited to: Tsinghua University Library. Downloaded on December 25,2010 at 10:43:03 UTC from IEEE Xplore. Restrictions apply. vi Copyright 1998 IEEE. All rights reserved. Contents 1.Overview1 1.1 Scope1 1.2
36、Audience1 1.3 Conformance2 2.Denitions2 3.Software quality metrics framework (informative)3 4.The software quality metrics methodology .5 4.1 Establish software quality requirements5 4.2 Identify software quality metrics.6 4.3 Implement the software quality metrics.8 4.4 Analyze the software metrics
37、 results .9 4.5 Validate the software quality metrics.10 Annex A (informative) Additional frameworks.14 Annex B (informative) Sample metrics validation calculations .18 Annex C (informative) Bibliography.20 Authorized licensed use limited to: Tsinghua University Library. Downloaded on December 25,20
38、10 at 10:43:03 UTC from IEEE Xplore. Restrictions apply. Copyright 1998 IEEE. All rights reserved. 1 IEEE Standard for a Software Quality Metrics Methodology 1. Overview This standard is divided into four clauses. Clause 1 provides the scope of this standard. Clause 2 provides a set of denitions. Cl
39、ause 3 provides an overview of framework for software quality metrics. Clause 4 pro- vides a methodology for software quality metrics. Also in this standard are three annexes that are included for illustrative and reference purposes only. 1.1 Scope This standard provides a methodology for establishi
40、ng quality requirements and identifying, implementing, analyzing, and validating process and product software quality metrics. This methodology applies to all soft- ware at all phases of any software life cycle. This standard does not prescribe specic metrics. 1.2 Audience This standard is intended
41、for those associated with the acquisition, development, use, support, maintenance, and audit of software. The standard is particularly aimed at those measuring or assessing the quality of soft- ware. This standard can be used by the following: An acquisition/project manager to identify, dene, and pr
42、ioritize the quality requirements for a system; A system developer to identify specic traits that should be built into the software in order to meet the quality requirements; A quality assurance/control/audit organization and a system developer to evaluate whether the qual- ity requirements are bein
43、g met; A system maintainer to assist in implementing modications during product evolution; A user to assist in specifying the quality requirements for a system. Authorized licensed use limited to: Tsinghua University Library. Downloaded on December 25,2010 at 10:43:03 UTC from IEEE Xplore. Restricti
44、ons apply. IEEE Std 1061-1998IEEE STANDARD FOR A 2 Copyright 1998 IEEE. All rights reserved. 1.3 Conformance An application of a software quality metrics methodology conforms to this standard if all required provi- sions, identied by the use of the verb shall, are implemented. 2. Denitions For the p
45、urposes of this standard, the following terms and denitions apply. IEEE Std 100-1996 and IEEE Std 610.12-1990 should be referenced for terms not dened in this clause. 2.1 attribute: A measurable physical or abstract property of an entity. 2.2 critical range: Metric values used to classify software i
46、nto the categories of acceptable, marginal, or unacceptable. 2.3 critical value: Metric value of a validated metric that is used to identify software that has unacceptable quality. 2.4 direct metric: A metric that does not depend upon a measure of any other attribute. 2.5 direct metric value: A nume
47、rical target for a quality factor to be met in the nal product. For example, mean time to failure (MTTF) is a direct metric of nal system reliability. 2.6 measure: (A) A way to ascertain or appraise value by comparing it to a norm. (B) To apply a metric. 2.7 measurement: The act or process of assign
48、ing a number or category to an entity to describe an attribute of that entity. A gure, extent, or amount obtained by measuring. 2.8 metric: See: software quality metric. NOTEThe term metric is used in place of the term software quality metric in this standard. 2.9 metrics framework: A decision aid u
49、sed for organizing, selecting, communicating, and evaluating the required quality attributes for a software system. A hierarchical breakdown of quality factors, quality subfac- tors, and metrics for a software system. 2.10 metrics sample: A set of metric values that is drawn from the metrics database and used in metrics val- idation. 2.11 metric validation: The act or process of ensuring that a metric reliably predicts or assesses a quality factor. 2.12 metric value: A metric output or an element that is from the range of a