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》由会员分享,可在线阅读,更多相关《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
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- IEEE Std 1061-1998 Standard for Software Quality Metrics Methodology 1061 1998
链接地址:https://www.31doc.com/p-3659565.html