软件度量的发展历程

1、软件度量的发展历程翻译：刘秋林、刘红林 2004/10/08前言 如Lemmerich所言， 测量在科学领域有悠久的历史116。相对早在1889年就定义好了度量单位米的长度测量116，温度的度量复杂的多。Fahrenheit和Celsius分别在1714年和1742年提出了基于某固定点间隔递增等级的温度度量方法。Celsius将100度和0度之间分为100个等份。但问题是一直不能唯一确定50摄氏度。而且长度的测量总是一个比例尺度，但是温度可能用间隔( 摄氏/华氏温度表) 或者比例尺度(开氏温度)来衡量。 今天，计算机在我们生活的每个领域几乎都扮演了非常重要的角色。在计算机上运行的软件也越来越重

2、要。因此，可预测、可重复、准确地控制软件开发过程和软件产品已经非常重要。软件度量就是衡量软件品质的一种手段。 软件度量或者说软件工程度量领域是一个在过去30多年研究非常活跃的软件工程领域。软件度量（software measurement）和软件量度（software metrics）一样非常有名（译者注：为了区分，译者将software measurement和software metrics分别译成软件度量和软件量度，其实他们都可以表示软件度量）。但目前学界还没有明确这两个术语的区别。参照测量理论159的相关术语，我们采用软件度量（software measurement）。从文献上看，这

3、两个术语是同义词。量度（metric）在这里不作度量空间理解，它理解为：度量是客观对象到数字对象的同态映射。同态映射包括所有关系和结构映射。用另一句话说，软件品质和软件度量成直对关系。这是度量和软件度量的根本理念。 软件度量研究主要分为两个阵营：一部分认为软件可以度量，一部分认为软件无法通过度量分析。无论如何，研究主流是关心软件的品质和认为软件需要定量化度量。目前有超过上千种软件度量方法被软件研究人员及从业人员提出，并且到今天有超过5000份论文出版发表。出于这个缘由，我们有必要对软件度量的发展历程做一个全面了解。当然，本文只是讨论软件度量发展过程中的一些里程碑。软件度量或者发表论文的全面综述

4、可以参考以下文献39,64,52,50,126,150,58,57,104,127,178,179,93,63,167,67,46,33,80,180,121,181,154,201,206,208。为什么要进行软件度量？ 度量在自然科学领域有悠久的历史。在20世纪末，物理学家Lord Kelvin (1824-1904)明确表示97：当你能度量你所讲的内容，并且能用数据表达，那你是确实明白你所讲的内容。但是如果你不能度量你所讲的内容，也不能用数据表达，那你的认知是微不足道的和不能让人信服的那种，那只是认知的开始，几乎没有到科学的思想境界。测量理论的科学家们支持在科学中应用度量的观点。Fred

5、 S. Roberts 159 在其一本杰出的有关测量理论著作中指出：发展成熟的学科如物理学和欠成熟的学科如心理学或社会学最大的区别是他们对研究对象的度量程度。 在软件工程领域，度量已经被讨论了25年。软件开发和维护的巨大成本扩大了支持设计标准和通过度量进行管理决策的科学基础的需要。Curtis 1980已经指出43：如果我们想将简单的编程转换程工程学科，就必须将严格的科学程序应用于软件系统开发研究，而这些科学程序的核心就是开发度量技术和决定相互影响的关系。下面是进行软件度量的问题所在，其中包括：1、 应用度量是否可能在设计阶段预测软件系统潜在的错误。2、 是否可以在软件的设计模型中抽取些定量

6、特征使我们能预测软件的可维护性。3、 程序模块代码是否存在一些定量的关键属性能让我们可以预测进行模块测试的困难程度和通过某种程度测试后隐含在模块中残余错误数。4、 是否可能从设计说明书中抽取出定量属性来预测开发如设计所描述那样的软件的工作量。5、 是否可以从一个子程序代码中提取定量的属性来帮助我们预测测试这个子所需要的工作量6、 是否有在需求分析阶段可以预测项目规模的特征。7、 确定一个设计的质量,需要什么样的软件度量手段。8、 以ISO 9126标准的软件品质数字属性为基础，什么样的软件度量是合适的。 那些想用软件度量或者正在使用软件度量的人们最大的问题是软件度量对从业人员有什么好处。我们认

7、为，Grady用明确的方式阐明了软件度量的需要和好处。1992年Grady64,65 ,66中肯地阐述了软件度量的合适性。软件度量用于度量软件产品或软件开发过程的特定属性。我们使用软件度量的目的如下：1. 估计的基础,2. 跟踪项目进展,3. 决定 (相关) 复杂性,4. 帮助我们理解我们什么时候有文档化的质量状态5. 分析缺陷,6. 实验验证的最好实践.简而言之:它帮助我们做出更好的决策。当然，还有许多其他需要软件度量的论述，但是全部论及会超出了本文的范围，本文就不作陈述。 软件度量的基础工作 在六十年代，主要是七十年代，人们就建立了软件量度和度量的基础性工作，根据这些早期工作，八十，九十年

8、代出现了更进一步的工作成果。提出软件度量的原因是基于大家都认为结构和模块化对开发可靠软件非常重要。许多软件专家认为软件系统模块化越高且模块结构越简单，软件可靠性越能得到保证168 。其实，模块很早就被研究讨论。为了使得模块和其他模块没有结构关系， Parnas 建议模块应该结构化148 。Myers描述了模块强度（module strength）的观念,Yourdon在1975论述了模块性。如Porter在文献153中指出的那样，这些因素影响软件的成本和质量。 最早的软件度量单位是LOC，直到现在人们还在讨论和应用它。1974年Wolverton第一次正式用LOC度量程序员的生产率197。他提

9、出了客观的指标：“人月”，作为生产率的度量单位，并且他认为他研究的内容可以作为典型的代码率。 文献178指出，LOC能作为度量单位的基础是程序的长度能预测程序的特性如可靠性和易维护性等。尽管如此，或许是由于这种度量太简单吧，它受到学术界严厉的批判。如Walston和Felix在文献192那样，估计的代码行和实际的代码行在软件合同协商和执行期间用作生产率的评估不太一致。在六十年代，源代码行SLOC (Source Lines of Code)是以80列为一行计算。在1983年Basili和Hutchens15建议应该把LOC作为其他度量单位可以比较的基本度量单位。我们认为有效代码行比源代码行作为

10、度量单位好些，因为作为一个最小的度量单位，完全凭经验就可以知道，LOC有时是没有任何东西。超过上万篇论文提到过LOC度量单位。 Rubey等人在1968年发表的论文165可能是最早的关于软件复杂性论文。在这篇论文的文献列表中没有更早公开发表的参考文献。1979年，Belady提到一篇1971年关于软件复杂性的论文18。Belady写道：在1974年，很少有关于复杂性的著名研究，程序复杂性的工作就更少。那时，我和Beilner教授在英国大学帝国学院共一个办公室，那是我们由兴而发地讨论过“复杂”程序和大规模程序的问题。有时候我们会问，什么是复杂性？是否可能提出合理的定义？直觉的复杂性概念是否可以定

11、量计算。由于我们不能回答这些问题，我们就转而面向查文献。立即，在众多关于复杂性哲学论述中，我们找到了一篇由Van Emden写的博士论文：“复杂性分析”54。Van Emden的工作是基于有关信息理论形式主义的传统可能性理念，似乎适合连接系统的复杂性模块化，如将程序建为模块。早在六十年代，出现了成本估计模型Deplhi76和Nelsons SDC。 1975年，Kolence创造性提出了软件物理的概念108，1977年，Halstead引入了软件科学的这个术语。在这个术语的潜在意义是用科学的方法来分析软件的特性和结构。Kolence的理论综合了那些惯用的性能量度，如往返时间，系统可用性和响应时

12、间以及惯用的管理量度如生产率，每单元服务成本，以及预算等。软件物理是专业处理计算规模和工作量的最早理论之一130。 1978年，伴随McClure提出的一个软件复杂性度量的提议123，其他两个复杂度度量方法Interval-Derived-Sequence-Length (IDSL)和Loop-Connectedness (LOC)被提出来74,201 。他们是基于流程图的间隔还原。但是，这两种方法不是很有名。Rubey，Van Emden的研究工作和Hecht度量已经大部分被遗忘，其中，1992年，Khoshgoftaar等人使用了Van Emden度量作文复杂性度量的基础101.。1977

13、年，Gilb62出版了一本标题为Tom Gilb：软件度量的书，这是软件度量领域的第一本书籍。1979年，Belady 18提出了the Measure BAND，该方法对嵌套是敏感的。 JONE90在1978年发表了一篇讨论程序品质和生产率的论文，有趣的是，其中，在这篇论文中是他对度量单元的考虑。 为了度量应用软件的开发生产率，Albrecht 2 在1979年提出了功能点（the Function-Point method）方法。 1980年，Oviedo146开发了一个程序品质模型。这个模型将控制流和数据流复杂性一起处理。Oviedo 通过一个方法计算控制和数据流复杂性来定义程序的复杂度

14、。1980年，Curtis 43 发表一篇关于软件度非常重要的论文。在这篇文章中，Curtis 论述了：科学和度量，一些度量的基本观念。他指出：欠成熟的科学，理论和实际的关系组成不是建立在正式的数学基础上，而是逻辑假设。并且，其中，他写到：我们的度量技术越严格，理论模型越能够彻底地测试和校准。因此，发展软件工程的科学基础依赖于改善基础构造元素度量方法。文章中，Curtis提到了JONE的论文90。Jones 的文章89, 90, 91也是软件度量领域先驱之一。 1981年，Ruston166提出了一种用多项式方法描述程序流程图的度量方法。这种度量方法流程图的元素和结构两个方面都计算了。Rust

15、on似乎适合网络测量，但不如McCabe度量方法那么广泛应用。1981年，Harrison等人72提出了一种将流程图分解为行列为基础软件复杂性度量方法。按照Harrison等人的观点，可确定在结构化，特别是非结构化的流程图中的节点嵌套层次。这种方法是对Dunsmore，Belady等人度量方法201一个非常重要的扩展。Dunsmore，Belady等人只是针对D-Structures流程图进行了定义。（译者注：D-Structures指是Dijkstra结构，Dijkstra被西方学术界称为“结构程序设计之父”）。1982年，Piwowarski等人152建议修改Harrison等人的度量方法

16、，因为这些度量方法有些缺点，如非结构流程图可能比结构流程图的复杂度低些。 Troy等人提出了24种度量方法的集合来分析软件系统的模块性，规模，复杂性，内聚度和耦合度。特别是内聚度和耦合度是软件系统易懂性的基本标准。软件（复杂性）度量基本分成模块间和模块内两部分，耦合度和内聚度概念明确的度量是以Constantine的研究工作为基础。内聚度是Emerson在1984年提出的55,56。1982年，Weiser提出了切片的概念193,194。以切片概念为基础，1986年，Longworth 等人119和1991年Ott等人讨论了内聚度度量。此外，还有其他一些论文在度量内容上使用到内聚度，如Dham

17、a 的文章49, Lakhotia的文章113, Patel等人的文章209, Rising等人的文章158, Selby等人的文章171和Thuss的文章189. Ott 等人的文章是内聚度软件度量的基础。 1981年 一个由工程界和大学的人员组成的研究小组（Victor Basili, Les Belady, Jim Browne, Bill Curtis, Rich DeMillo, Ivor Francis, Richard Lipton, Bill Lynch,Merv Mler, Alan Perlis, Jean Summet, Fred Sayward, and Mary Sh

18、aw）讨论和研究了艺术状况和软件度量领域的研究情形。在这个小组中，DeMillo 等人48讨论了软件度量和其他科学对比问题。他们讨论得很深刻。但他们没有给出序位尺度和比例尺度的软件度量使用条件。 八十年代，美国空军罗姆妍制中心（Rome Air Development Center RADC）做了几次软件度量方面的调查研究156。这个调查研究了软件度量和软件品质属性（如可用性，易测性和可维护性等）。这些调查研究的目的是开发出量化面向用户和面向管理技术的软件品质框架来量化软件产品质量。 美国国家航空和宇宙航行局（NASA）的软件工程实验室 ( SEI Software Engineering l

19、aboratory) 也是从事软件度量比较早的单位136。它是少数使用软件度量超过15年多的组织143。最近和NASA 有关联的是Basili 的研究工作11,12。 （译者注：80年代末到90年代初，软件工程实验室(SEL)在Vic Basili，Scott Green，Rose Pajerski，Jon Valett等人的领导下进行了一系列净室试验）软件设计度量 1977年，Gilb提出了简单的软件设计度量62，叫做模块数，然而，在1978年Yin 和Chapin 等34提出了更加成熟的设计度量方法。这些度量也许是第一个可以在软件生命周期的软件设计阶段应用的度量方法。其他提出可用于设计阶段

20、的软件度量方法有Bowles 31, Troy 等 169, McCabe等134.Card等33, Sheppard等157, Ligier 105, 106,和 Zuse 182。 在Stevens, Myers 和 Constantine 161工作基础上，开始了许多为衡量大型软件系统相互关联性的软件（复杂性）度量工作。软件系统组件之间包含多种相互关系，如数据，控制和组件间的先后顺序。1981年，Henry和Kafura提出了相互关联性度量方法（Interconnectivity Metric） 77。这种方法基于扇入扇出模型的倍增。在八十年代末，这种度量方法的修正版本被提出来，它综合了

21、多种模型组成，如Halstead度和McCabe度（ the Measures of Halstead and McCabe）和相互关联性度量的综合。 其他方法，比如Selby等人151和Hutchens等人 81，基于Myers和Stevens等人161的早期工作，提出了基于数据绑定的软件度量。其他软件设计度量研究工作可以参加文献29,13973。 在1983至1984年期间，为分析大型系统，Hall提出了软件复杂性度量68, 69。虽然这样，但是他的方法非常直觉，已经几乎没人提起了。 80年代末和90年代初，开始了一些研究软件度量标准化工作。二个IEEE报告 82 , 83 提些规范化的软

22、件度量措施。不幸地是，在这些报告论述到的软件度量方法是开发过程度量和软件生命周期的维护阶段的度量，没有发现任何软件复杂性度量。成本估计度量 成本估计模型是第一个使用度量的概念。下表给出了一些费用估计模型概要。模型名称提出单位时间DelphiRand Corp.（美国兰德公司）1966Nelsons SDCSDC（美国科学资料中心）1966WolvertonTRW（美国伍尔德里奇公司）1974RCA Price-S SystemRCA（美国无线电公司）1976 Halstead1977 Walston and FelixIBM1977Function-point Method1979Parr M

23、odel1980 COCOMO-ModelTRW1981SOFTCOSTJPL（美国喷气推进实验所）1981 Bailey and BasiliNASA1981 Bang Metrics1982MARK II Function Points1988Pfleeger Model1989 1979 年Albrecht提出了功能点方法 2 , 3 。功能点（Function points）来源于需求说明书。这种方法可以用于软件生命周期的需求分析阶段，今天在美国和欧洲广泛应用。1988年，Jones 92 一个Albrecht功能点方法的坚强支持者，为使得功能点方法适用于实时和嵌入式应用软件，提出了一

24、种扩展的功能点方法。Jones把他扩展的功能点方法叫做特征点（feature points）。他引入了一个新参数，叫运算法则，并降低了原来功能点分配给数据文件参数的权重。 在1988年和1991年Symons修改了这个模型162, 163 。他提出了一种扩展的叫Mark II function points的功能点方法。该方法解决了Albrecht方法的以下弱点：1、 系统构件划分过分简单化2、 系统构件的权重分配太主观3、 内部复杂性考虑相当不充分4、 14个因素重叠并且权重的范围总是合法的。（译者注：功能点方法是通过计量包括对外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件的数目，

25、由14个因素决定加权因子进行加权计算而得，而14个因素的界限划分又重叠部分，如划分系统复杂度级别和数据通讯复杂度的级别就很难说没有任何关系，而Albrecht方法就直接认为分配给这两类因素的权重是有效的，没有考虑因素间的重叠性） 1981年，在LOC量度的基础上，Boehm提出了COCOMO (Constructive Cost Model)模型23, 24 Kitchenham对成本估计模型和度量做了一个好的综合评述58。通常有四类成本估计方法：专家评估，类推，分解和估计方程式。非常有趣的方法是分解法。分解法包括从对产品的分解到组成它的最小组件的分解，或者将一个项目分解成非常小的具体任务。先

26、估计生产各个最小组件生产或完成最小任务的工作量成本。项目的成本是各个组件的总和。这类预测只有采用大众结构如LOC和McCabe 202,205那样才是合适的。 COCOMO模型一种可能合适的预测模型，它采用了大众结构。它定义开发一段程序的工作量这个外部变量和LOC度量的关系如： EFFORT(P)=a LOC b 其中，P表示一段程序，并且a,b0。如LOC外其他软件度量方法，只要采取了大众结构就可以使用。其他成本估计模型还有Putnam提出的Raleigh曲线模型155和DeMarco提出的Bang度量47。目标驱动度量范例，用户视域和观察点 1984年Basili等提出了目标驱动度量GQM

27、(Goal-Question-Metric)范例210,17,163。GQM使用定义的度量目标。GQM基本理念是从度量的目标和问题驱动软件度量。GQM方法以一套怎么表示出一个可理解的目标，提什么类别的问题和怎么样将他们重新定义为问题的向导来统一各种度量。 Fenton 59和Zuse等200, 201也支持这种基于人类思维观察点的进行软件度量的理念。Fenton在论著中称为用户视域（user-view），Zuse等叫其为复杂性观察点（a viewpoint of complexity）测量理论和软件度量 以Bollmann和Cherniavsky的论文25，Bollmann的论文26（在该文中

28、，测量理论用于评价信息检索系统方面的度量）为基础，1985，Bollmann等人 和 Zuse 198, 27将这些论文论及的测量理论应用到软件复杂性度量，如Roberts 159,Krantz 等人 109 和Luce 等人 120描述的那样，他们根据测量理论给出度量的条件。 在文献27,198,199,200,201,202中提出了在某些尺度层次应用复杂性度量，如序位，等距或等比尺度的条件。另外，测量理论通过假设的经验关系以及进行合成和分解操作的条件给出了软件度量的经验诠释，这是一种软件工程的重要策略。据文献201，有超过90种软件独立方法应用了这种理念。1993/1994年，Bollma

29、nn和Zuse将测量理论方法扩展为一种预测模型，并且Zuse在1994提出了确认预测模型软件度量方法的经验条件205,207 。1995年，Zuse等给出了软件度量的经验条件。很明显，面向对象方面的软件度量和命令式语言的软件度量有完全不同的特性。许多软件度量遵循人工智能证据法则结构。1987年后，Grubstake小组随后相类似地应用了测量理论8,9。Grubstake小组由英国大学的科学家Norman Fenton，伦敦南湾大学系统和软件工程中心的Robin Whitty，美国科罗拉多州立大学的Jim Bieman，美国堪萨斯州立大学的Dave Gustafson和Austin Melton

30、以及Albert Baker组成。Grubstake小组应用测量理论描绘了软件度量程序的队列。而且Fenton提出测量理论也适合软件度量58。欧洲项目 1986年英国启动了一个名叫“基于结构的软件度量”的研究项目53，该项目是欧洲艾非计划之一，编号SE/069。项目目的是想在现有研究基础上建立标准模型，分析和度量软件结构。它是由英国伦敦南湾大学系统和软件工程中心提出来的。这个项目的研究结果可以在文献58中查阅，在这个项目，大部分软件度量方法被认为是基于素数分解58,201。从1989年到1992年，欧共体创立了一个名叫METKIT（Metrics Educational Toolkit 238

31、4，度量教育工具包2384）项目124。METKIT作为欧盟执委会架构下的ESPRIT （European Strategic Programme for Research and Development in Information Technology 欧洲资讯科技研究发展策略计划）一部分得到欧盟执委会部分基金支持。METKIT的目的通过开发面向工程和学术界的教材来唤起相关人员的度量意识和提高软件度量在欧洲工程界的应用。METKIT项目成果之一是Fenton出了一本关于软件度量领域杰出的综合评述论著58。其他研究软件工程度量的ESPRIT项目有：1、AMI (Applications of

32、 Metrics in Industry) ，自1990年十一月-1992年2、MUSIC (Metrics for Usability Standards in Computing), 自1990年十一月-1993年3、MUSE (Software Quality and Reliability Metrics for Selected Domains: Safety Management and Clerical Systems), 自1987年-1990年1987-904、PYRAMID (Promotion for Metrics), 自1990年十月-1992年，它的任务是通过使用定

33、量的方法来改善欧洲软件密集型系统的开发和维护的质量和生成力。 METKIT项目的根本目的是在整个欧洲促进度量的应用。这个项目开发了一整套包括从教材到教师管理，软件开发人员和大学学生怎么样用度量去理解，控制和提高软件质量的标准集合。 德国的软件度量研究 德国软件度量研究活动水平非常低。自1993年后在GI (Gesellschaft fur Informatik)的支持下，存在一个软件度量组织。这个组织的领导人是Dumke博士。只有少数几家德国大学发表出版过软件度量论文。柏林工业大学的Bollmann和Zuse发表过一篇软件度量的论文，在马格德堡工业大学，其中Dumke博士开设过软件度量课程。凯

34、沙罗顿的Rombach为了提高软件质量投入了大量研究精力。软件度量教育受到过原来在德国大学现在ORACLE公司工作的Barbara Wix的支持。几家大型公司引进了软件度量如西门子（Siemens），博世（Bosch），阿尔卡特（Alcatel）和 BMW等。可喜的是，德国政府在1994宣布了一项研究课程，其中软件度量是其主要部分。美国软件度量领域的研究 软件度量最早在美国和加拿大开始。自70年代中期以来，美国建立了各种各样的软件度量组织和活动。本文不可能提及所有的组织和活动。许多度量研究活动由美国卡内基梅隆的软件工程研究所（SEI）主办进行，这些活动是促进组织间提高应用软件度量的舞台。许多大

35、型公司和组织广泛地应用了软件度量如美国电话电报公司（AT&T）, 美国国家航空和宇宙航行局（NASA）, 摩托罗拉公司（Motorola）, 惠普Hewlett Packard等。 马路兰的软件工程实验室（SEL-Lab）有悠久的（长达15年）的软件度量历史134 ,135,136,137,139,140,141,142,143。本文的其他章节会叙述到美国的其他研究活动。 日本软件度量领域的研究 日本的软件度量研究不是非常著名。其中一个格外出色的工作是Azuma的ISO 9126标准。伴随着这个标准，有超过100个软件度量方法作为软件品质的定量标准被提出。合适的软件度量参数 综合考虑软件生命周

36、期和软件度量，许多研究者提出了软件度量合适的参数。在Fenton的论文58第218页, Weyuker的论文195, Kearney等的论文212和Lakshmanan等的论文114可以看到这样的合适的参数。这些必须的参数很多是相互矛盾的。其中一些在测量理论广义结构上讲是一致201。在文献201和论著204的第5，6章有关于合适的度量参数的激烈讨论的论述。软件度量的验证和预测模型 软件度量的验证是软件度量领域另一个非常重要的话题，因为实际上软件度量的认同取决于软件度量是否能作为软件品质特征的预报器。Schneidewind就软件度量验证论述到：仅使用有效地量度（比如 或者是品质因素，或者是通过

37、验证和品质因素有关的量度）有助于确保度量是合适的，软件度量和预测模型是建立在以下问题基础上： l 是否可能在设计阶段使用软件度量预测一个系统的错误倾向l 是否可能从软件设计说明书中抽出定量属性使得我们能够预测一个软件系统的可维护程度l 程序模块代码是否存在一些定量的关键属性能让我们可以预测进行模块测试的困难程度和通过某种程度测试后隐含在模块中残余错误数l 是否可能从设计说明书中吸取出定量特征来预测开发如设计所描述那样的软件的工作量l 确定一个设计的质量,需要什么样的软件度量手段l 是否有在需求分析阶段可以预测项目规模的特征l 以ISO 9126标准的软件品质数字属性为基础，什么样的软件度量是合

38、适的。l 软件度量内外标准是什么，预测模型的标准是什么？ 直到八十年中期，大部分用于模块或程序的模块内的软件度量方法都是在软件生命周期的编码阶段使用。从八十年代中期以后，人民把更多的注意力直接放到了软件生命周期的更早的阶段，如设计阶段。软件度量应该应用于软件生命周期的每一个阶段。在软件生命周期的早期阶段使用软件度量的主意是想改善软件开发，在设计阶段通过软件度量控制过程反馈目的是为了在编码阶段更好的实现软件系统和减少系统的复杂性和维护费用。 在八十年代中期，研究者们，如Kafura等人95和NASA136试图证实软件量度和软件开发数据（如过失和编码时间）存在相互关系的假设。为了证实这个假设，他们

39、研究了来自SEL-Lab134的数据。相似的调查研究可以参见文献136,140 。Rombach 162 总结了一些在软件生命周期早期阶段做度量的结果。他采用了斯皮尔曼等级相关系数（Spearman correlation coefficient），他指出：架构设计文档和可维护性（维护性因子）之间有很高的系数（0.7,0.8）。架构设计可以通过“架构度量”（模块间度量）来捕获，就像系统设计和模块性度量一样。在“算法量度”（模块内度量：代码复杂度，如McCabe度）和可维护性之间系数非常低。可维护性和“混合度量”（算法和架构度量）之间的系数也很高（0.75,0.8,斯皮尔曼相关）。其他研究可以参

40、加文献39的第4章。 自1989年，Munson 等人132和Coupal等人41使用因子分析进行分析了现存软件特征和程序复杂度的度量维。 我们必须注意软件度量的外部验证和内部验证的区别22，内部验证考虑同态，也就是说，做用户想要的度量。软件度量的外部验证意思是量度是否和软件品质属性（外部变量）是否有关系。文献177和178应用算法验证考虑过度量的外部验证，而Zuse等人采用的是所谓原子修正进行度量的外部验证，原子修正可以看作对顺利量表的必要条例。软件度量广泛使用的外部验证概念相对于外部特征是相互关系的考虑。Dunsmore等人51，Curtis等人 42做了最早的调查研究，Curtis等人利

41、用软件量度开发过程序员开发能力的预测模型。Basili等人13, 14,15, 210, 16做了软件度量和外部变量如过失的实践调查，Hamer等人213做了Halstead度的调查研究，Kafura等人94 调查研究了LOC度量, tHalstead度和McCabe度，Ince 等人做了信息流度（the information flow metric）的调查研究。其他调查研究可以参见文献176, 87, 100, 79,118, 169, 102,191,170。 这些调查研究的结果是矛盾的。 Kemerer验证了成本估计模型98,99,在1993年和1994年Bollmann等人28和Zu

42、se等人206从一种度量理论视角考虑过软件度量的预测模型和软件度量的验证，表明软件度量的验证依赖于外部变量的尺度类型。作者指出（基本）COCOMO模型是唯一可以适合两种比例尺度的模型（度量值和外部变量都被认为比例尺度）。Zuse等人也提出没有实验意义的全体（全体至少和各个部分一样大）是假的， 全体仅是没改变实验意义的度量的数据修正。 结果对度量的验证和预测模型的内容非常重要。作者讨论了维护时间成本是否也可以由软件系统的组成确定。 1993年，IEEE标准1061发表了84,169，它给出了验证软件度量的规则和意见。Schneidewind 编写了IEEE 1061标准。IEEE 1061标准覆

43、盖了如分别力（discriminate power）,跟踪（tracking）, 确认（validation）,可预测性（predictability）, 一致性（consistency）等术语. 需注意的重点是软件度量验证不只是一次的事，它是一个需要重复验证的连续过程。 面向对象的软件度量 在八十年代末，面向对象环境度量（面向对象度量 OO-measures）被提出来。从文献161中可以发现，Rocacher做一个非常早的调查研究。1989年，Morris 131研究讨论了面向对象应用程序的度量，Bieman21研究讨论了在面向对象条件下软件重用的度量问题，Lake等111讨论了C+应用软件

44、的度量，Chidamber等对不同的Smalltalk应用程序进行了评述，Sharble等173研究讨论了面向对象设计的度量，Li和Henry研究了ADA（行动数据自动化系统，Chen 和 Lu 36评价了与Booch面向对象30设计的有关面向对象度量。 Karner 96 写了一篇面向对象环境下的软件度量硕士论文。 还有其他论文如32,88,115,157,10, 187,188,1,196, 112 ,186都是研究面向对象软件度量的。 Cook在1994年进行了一次非常有趣的面向对象度量调查研究。为了研究出面向对象程序的主要因素，他采用了因子分析法。虽然是最后提到，但是也一样重要，.我们

45、要提到由Lorenz等人编写的第一本面向对象度量的书。（译者注：这里有两篇文献作者没有在文献中列出，一篇是Cook调查研究论文，一篇是Lorenz等人编写的书） 1995年，Zuse 208 和Fetcke 60调查研究了面向对象度量方法的结构和行为。结果表明面向对象度量方法几乎都没有采用广泛的结构。为了表征在顺序量表上的面向对象度量，Zuse 和Fetcke应用Dempster-Shafer证据理论，科莫果夫公理和De Finetti公理。虽然这样，然而，在面向对象系统领域，还不清楚是什么使得面向对象程序难理解，测量或维护。数据相关性度量 许多研究直接针对程序的复杂性，程序员之间接口集中在控

46、制流程复杂性度量分析。Weiser 193发现当调试和只检查影响变量错误的指令时候，程序规划员总好像在幕后工作（进行接口协调）。Weiser的结果证明了数据相关性的重要性并说明了数据相关性度量将是开发可靠性软件的一个重要手段。Bieman在文献20中对数据相关性度量做了一个好的综述。分布式系统的软件度量 Kodres在文献45,107,164,174,175中论述了分布式和实时系统的软件度量。神经网络和软件度量 1994年Khoshgoftaar等 103 提出一种神经网络模型，按若干标准变量将程序模型分为或者高风险或者低风险两类。在软件度量领域的国内国际研讨会多年来，软件度量是有关研讨会的主

47、要话题。我们列举一些：l 国际软件工程大会(ICSE)l 国际软件可靠性工程研讨会(ISSRE)l IEEE软件度量座谈会（第一次在1993年举行）l 国际软件工程标准座谈会(ISESS)l 国际软件重用会议(ICSR)l 程序可读性研讨会l 国际软件维护会议(IC*)，大概200-250人l 国际软件质量会议(ICSQ)l 旧金山软件质量周 大概500-600l 美国NASA（美国国家航空和宇航局）软件工程研讨会，大概800人l 美国俄勒冈州软件度量研讨会(AOW*)，自从1989年开始l 12.1995在加拿大蒙特利尔国际软件工程标准(ISESS)论坛和研讨大会l 13.1993年5月21

48、-22在美国巴尔举行的首次IEEE国际度量座谈会在1994年7月1日，IEEE 计算机协会技术活动会议授权新的软件工程技术委员会(ICSE)作为新规划和服务的一种新组织。其中，包括一个定量方法委员会的建立。软件度量工具 随着软件定量方法（如：软件度量）的重要性不断增加，市场上出现了许多度量工具。然而，度量工具目前还是很混乱。因为没有统一的度量标准规范，每种工具发明商家都是按照他们自己的软件度量规范。文献44对度量工具做了好的综述。Daich等根据分类学把度量工具分成了以下几种：l 通用度量工具；l 小生境度量工具（Niche Metrics Tool）；l 静态分析；l 源代码静态分析；l 规

49、模度量软件度量和软件再工程软件度量在软件再工程学科中扮演一个非常重要的角色，具体可以参见文献4，5，6ISO 9000-3和软件度量 ISO 9000是国际标准化组织定义的质量标准。获得了ISO 9000证书并不是保证企业产品质量水平，相反地，它只是表示企业已经定义质量手册和岗位规范。它一样适用于软件企业。证书并不保证软件没有问题，它仅仅表明卖主有岗位规范纠正错误或者避免遗漏功能。 在美国，和ISO 9000对应有ANSI/ASQC Q9000 （或者说Q90.00）标准。这个由美国质量控制协会（the American Society of Quality Control ASQC）和美国国

50、家标准协会（the American National Standards Institute ANSI）联合支持。美国愿意用它代替ISO。 在ISO9000-3的6.4节， 我们可以看到产品和过程度量： 产品度量：度量应该报告和用于管理开发和发布过程，并且应该和具体软件产品有关。当前没有广泛接受软件品质度量。但是，至少，一些能够表现域错误和用户看来的缺点的度量应该使用。 被选择的量度的结果应是可比较的。软件产品供应商应该收集和执行这些软件产品的品质定量度量。这些度量应该用于以下目的： a)在规范的基础上收集数据和报告度量值，b)识别每个度量的当前执行级别，c)当度量级别逐渐变差或超出已制订的

51、目标时采取矫正措施，d)定期建立明确的度量改善目标。在6.4节，我们可见对过程度量的如下描述：供应商应该有对开发和发布过程的定量度量。这些应该反映：a) 在里程碑期间进行开发有多好和在过程进度内质量目标保证有多好b) 开发过程在减少缺陷出现或者没有发现任何缺陷情况方面起到多少效果。 根据所采用的开发过程选择适合的度量方法，可能会对提交的软件产品品质有直接的影响。不同的度量应用于同一个供应商的不同软件产品。展望 毫无疑问，软件度量是提高软件品质的一个重要方法。Dieter Rombach，1991年在Eurometrics工作时在巴黎说到（现在他在美国软件工程实验室（SEL）工作）：我们现在不再

52、是问我们是否应该度量，而是怎么样度量。尽管过去软件度量领域做了许多的研究，但还有许多问题未解决。首先，目前还没有成熟的度量方法；其次，国际上还没有统一的软件度量标准。在文献82中提出的软件度量方法还没有得到普遍公认。外部变量对软件度量验证确认是未来需要研究的课题。相关和归约分析需要考虑讨论度量比例。 将来，理论开发（对现实的假定）变得越来越重要。利用测量理论的公理有助于更好理解软件品质和成本估计后潜在的内容。文献1 Abreu, F.B.: Metrics for Object-Oriented Environment. Proceedings of the ThirdInternationa

53、l Conference on Software Quality, Lake Tahoe, Nevada, October 4-6, 1993, pp.67-75.2 Albrecht, A.J.: Measuring Applications Development Productivity. Proceedings of IBM Applic. Dev. Joint SHARE/GUIDE Symposium, Monterey, CA, 1979, pp.83-92.3 Albrecht A.J.; Gaffney, S.H.: Software Function, Source Lin

54、es of Code and Development Effort Prediction: A Software Science Validation. IEEE Transactions of Software. Engineering Volume 9, No. 6, 1983, pp. 639-648.4 Arnold, Robert, S.: Software Reuse and Reengineering. In: Arnold, Robert, S.: Software Reegineering. IEEE Computer Society, 1992, pp. 476-484.5

55、 Arnold, Robert, S.: Software Reegineering. IEEE Computer Society, 1992.6 Arnold, Robert, S.: A Road Map Guide to Software Reengineering Technology. In:Arnold, Robert, S.: Software Reegineering. IEEE Computer Society, 1992, pp. 3-22.7 Bailey, C.T.; Dingee W.L.: A Software Study Using Halstead Metric

56、s. Bell Laboratories Denver, CO. 80234, 19818 Baker, A.L.; Bieman, J.M.; Gustafson, D.A.; Melton, A.; Whitty, R.A.: Modeling and Measuring the Software Development Process. Proceedings of the Twentieth Annual International Conference on System Sciences, 1987, pp. 23-29.9 Baker, A.L.; Bieman, J.M.; Fenton, N.; Gustafson, D.A.; Melton, A.; Whitty, R.A.: A Philosophy for Software Measurement. The Journal of Systems and Software, Volume 12, No 3, 1990, p