1、The Institute of Electrical and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-5997, USACopyright 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.S. P
2、atent (978) 750-8400. Permission to photocopy portions of any individual standard for educational class-room use can also be obtained through the Copyright Clearance Center.Note: Attention is called to the possibility that implementation of this standard mayrequire use of subject matter covered by p
3、atent rights. By publication of this standard,no position is taken with respect to the existence or validity of any patent rights inconnection therewith. The IEEE shall not be responsible for identifying patents forwhich a license may be required by an IEEE standard or for conducting inquiries intot
4、he legal validity or scope of those patents that are brought to its attention.Copyright 1998 IEEE. All rights reserved.iiiIntroduction(This introduction is not part of IEEE Std 1061-1998, IEEE Standard for a Software Quality Metrics Methodology.)HistoryIn February 1984, a project to develop a standa
5、rd for a software quality metrics methodology was approved,and a working group was formed, because there was no existing IEEE standard covering the eld of softwarequality metrics. In December 1992, the IEEE Standards Board approved IEEE Std 1061-1992. It was pub-lished by IEEE on 12 March, 1993. Thi
6、s was the rst IEEE standard that dealt with quality metrics. It is important that users of this standard understand that this is a process standard, and not a standard thatmandates specic metrics for use. The philosophy of this standard is that an organization can employ which-ever metrics it deems
7、most appropriate for its applications, as long as the methodology is followed and themetrics are validated. Another reason for this approach is that there was no consensus on which metrics tomandate for use (the provisions of a standard are mandatory, not optional). Consistent with this approachwas
8、the Working Group charter, as provided in the IEEE Standards Board approval of the project authoriza-tion request (PAR), which 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 arevision was submi
9、tted and approved in 1998. The revision was reballoted and recirculated, and commentswere resolved in 1998. The standard 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
10、to which software possesses a desired combination of attributes. This desiredcombination of attributes shall be clearly dened; otherwise, assessment of quality is left to intuition. For thepurpose of this standard, dening software quality for a system is equivalent to dening a list of softwarequalit
11、y attributes required for that system. In order to measure the software quality attributes, an appropriateset of software metrics shall be identied. The purpose of software metrics is to make assessments throughout the software life cycle as to whether thesoftware quality requirements are being met.
12、 The use of software metrics reduces subjectivity in the assess-ment and control of software quality by providing a quantitative basis for making decisions about softwarequality. However, the use of software metrics does not eliminate the need for human judgment in softwareevaluations. The use of so
13、ftware metrics within an organization or project is expected to have a benecialeffect by making software quality 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 i
14、ts outset; Establish acceptance criteria and standards; Evaluate the level of quality achieved against the established 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 softwa
15、re is modied; Assess the ease of change to the system during product evolution; Validate a metric set.To accomplish these aims, both process and product metrics should be represented in the system metrics plan.ivCopyright 1998 IEEE. All rights reserved.The following is a list of major changes from t
16、he previous edition:a) This revision elaborates on the context in which validation is to be interpretedvalidating metricswith respect to a quality factor (e.g., demonstrating a statistical relationship between a complexitymetric and defect count for the purpose of predicting defects from complexity)
17、 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 Software Engineering Standards Committee (SESC) to provi
18、de majorinformational items in the form of SESC approved books, as opposed to putting this information instandards, the annex that contained the case studies (Annex C of IEEE Std 1061-1992) has beendeleted. In addition, due to legal and proprietary restrictions on the release of data when IEEE Std10
19、61-1992 was written, the working group was unable to obtain metric data from industry for themission critical example. Therefore, it was necessary to use university metric data. Since the publi-cation of IEEE Std 1061-1992, data have become available from applications, such as the SpaceShuttle, whic
20、h will be used in a future book. The book could be used as a companion document tothis standard.c) The annex that contained an informational item about metrics descriptions and results (Annex B ofIEEE Std 1061-1992) has been deleted because many of the metrics and metrics application resultsare now
21、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 deleted. The relationships amongthese are pictured in Figure 1 a
22、nd discussed in Clause 3 of this standard.e) Obsolete references in the bibliography (Annex D of IEEE Std 1061-1992) have been deleted and alist of references (Clause 2 of this standard) has been added. The purpose of the references is to pointthe user to additional information about key points in t
23、he standard. In accord with SESC policy, ametrics 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 frameworks have been included in an informative annex (Annex A of th
24、isstandard).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 thefollowing membership:Norman Schneidewind,ChairCelia Modell, EditorAlain AbranJulie BarnardDick Chiricos
25、taJ. Philippe JacquetKathy LiburdyTomoo MatsubaraSandra SwearingenLeonard L. TrippStephanie WhiteCopyright 1998 IEEE. All rights reserved.vThe 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 fo
26、llowingmembership:Richard J. Holleman,ChairDonald N. Heirman,Vice ChairJudith Gorman,Secretary*Member EmeritusYvette Ho SangIEEE Standards Project EditorSyed AliH. Ronald BerlackMichael A. BlackledgeJuris BorzovsJames E. CardowEnrico A. CarraraKeith ChanAntonio M. CicuRosemary ColemanW. W. Geoff Coz
27、ensPaul R. CrollGeoffrey DarntonTaz DaughtreyRaymond DayBostjan K. DergancPerry R. DeWeeseHarpal DhamaEvelyn S. DowSherman EaglesLeo G. EganWilliam EventoffRichard E. FairleyJohn W. FendrichJay ForsterKirby FortenberryEva FreundKarol FruehaufRoger U. FujiiBarry L. GarnerMarilyn Ginsberg-FinnerJohn G
28、arth GlynnJulio Gonzalez-SanzEric GrosseL. M. GuntherDavid A. GustafsonJon D. HagarJohn HarauzWilliam HeeyJames H. HeilMark HeinrichDavid HeronDebra HerrmannJohn W. HorchJohn O. JenkinsFrank V. JorgensenVladan V. JovanovicWilliam S. JunkGeorge X. KambicDiana KangChris F. KemererRon S. KenettJudith S
29、. KernerRobert J. KierzykThomas M. KuriharaJohn B. LaneJ. Dennis LawrenceRandal LeavittStanley H. LevinsonWilliam M. LivelyDieter LookJohn LordTom LydonStan MageeTomoo MatsubaraPatrick D. McCrayJames Bret MichaelAlan MillerCelia H. ModellCharles S. MooneyJames W. MoorePavol NavratDonald J. OstromInd
30、radeb P. PalJohn G. PhippenPeter T. PoonKenneth R. PtackAnnette D. ReillyDennis RillingAndrew P. SageHelmut SandmayrStephen R. SchachHans SchaeferNorman SchneidewindDavid J. SchultzRobert W. ShillatoLynn J. SimmsCarl A. SingerAlfred R. SorkowitzLuca SpotornoJulia StesneyFred J. StraussSandra Swearin
31、genToru TakeshitaDouglas H. ThieleBooker ThomasPatricia TrellueLeonard L. TrippGlenn D. VenablesUdo VogesScott A. WhitmirePaul A. WolfgangPaul R. WorkNatalie C. YopconkaJanusz ZalewskiGeraldine ZimmermanSatish K. AggarwalClyde R. CampJames T. CarloGary R. EngmannHarold E. EpsteinJay Forster*Thomas F
32、. GarrityRuben D. GarzonJames H. GurneyJim D. IsaakLowell G. JohnsonRobert KennellyE. G. Al KienerJoseph L. Koepnger*Stephen R. LambertJim LogothetisDonald C. LoughryL. Bruce McClungLouis-Franois PauRonald C. PetersenGerald H. PetersonJohn B. PoseyGary S. RobinsonHans E. WeinrichDonald W. ZipseviCop
33、yright 1998 IEEE. All rights reserved.Contents1. Overview11.1 Scope11.2 Audience 11.3 Conformance22. Denitions23. Software quality metrics framework (informative)34. The software quality metrics methodology .54.1 Establish software quality requirements 54.2 Identify software quality metrics .64.3 Im
34、plement the software quality metrics.84.4 Analyze the software metrics results .94.5 Validate the software quality metrics.10Annex A (informative) Additional frameworks .14Annex B (informative) Sample metrics validation calculations .18Annex C (informative) Bibliography.20Copyright 1998 IEEE. All ri
35、ghts reserved.1IEEE Standard for a Software Quality Metrics Methodology1. OverviewThis standard is divided into four clauses. Clause 1 provides the scope of this standard. Clause 2 provides aset of denitions. Clause 3 provides an overview of framework for software quality metrics. Clause 4 pro-vides
36、 a methodology for software quality metrics. Also in this standard are three annexes that are includedfor illustrative and reference purposes only.1.1 ScopeThis standard provides a methodology for establishing quality requirements and identifying, implementing,analyzing, and validating process and p
37、roduct 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 AudienceThis standard is intended for those associated with the acquisition, development, use, support, maintenance,and audit of so
38、ftware. 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 prioritize the quality requirements for asystem; A system developer to identify specic traits that sho
39、uld be built into the software in order to meetthe quality requirements; A quality assurance/control/audit organization and a system developer to evaluate whether the qual-ity requirements are being met; A system maintainer to assist in implementing modications during product evolution; A user to as
40、sist in specifying the quality requirements for a system.IEEEStd 1061-1998 IEEE STANDARD FOR A2Copyright 1998 IEEE. All rights reserved.1.3 ConformanceAn application of a software quality metrics methodology conforms to this standard if all required provi-sions, identied by the use of the verb shall
41、,are implemented.2. DenitionsFor the purposes of this standard, the following terms and denitions apply. IEEE Std 100-1996 and IEEEStd 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 v
42、alues used to classify software into the categories of acceptable, marginal, orunacceptable.2.3 critical value:Metric value of a validated metric that is used to identify software that has unacceptablequality.2.4 direct metric: A metric that does not depend upon a measure of any other attribute.2.5
43、direct metric value:A numerical 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
44、or process of assigning a number or category to an entity to describe an attributeof that entity. A gure, extent, or amount obtained by measuring.2.8 metric:See:software quality metric.NOTEThe term metricis used in place of the term software quality metricin this standard.2.9 metrics framework:A dec
45、ision aid used for organizing, selecting, communicating, and evaluating therequired 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
46、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 qualityfactor.2.12 metric value: A metric output or an element that is from the range of a metric.2.13 predictive metric:A metric applied during development an
47、d used to predict the values of a softwarequality factor.2.14 predictive metric value:A numerical target related to a quality factor to be met during system devel-opment. This is an intermediate requirement that is an early indicator of nal system performance. Forexample, design or code errors may b
48、e early predictors of nal system reliability.2.15 process metric:A metric used to measure characteristics of the methods, techniques, and toolsemployed in developing, implementing, and maintaining the software system.IEEESOFTWARE QUALITY METRICS METHODOLOGY Std 1061-1998Copyright 1998 IEEE. All righ
49、ts reserved.32.16 product metric:A metric used to measure the characteristics of any intermediate or nal product of thesoftware development process.2.17 quality attribute:A characteristic of software, or a generic term applying to quality factors, qualitysubfactors, or metric values.2.18 quality factor:A management-oriented attribute of software that contributes to its quality.2.19 quality factor sample:A set of quality factor values that is drawn from the metrics database and usedin metrics validation.2.20 quality factor value:
