软件度量的发展历程Word格式.docx

软件度量的发展历程Word格式.docx

《软件度量的发展历程Word格式.docx》由会员分享，可在线阅读，更多相关《软件度量的发展历程Word格式.docx（22页珍藏版）》请在冰豆网上搜索。

一部分认为软件可以度量，一部分认为软件无法通过度量分析。

无论如何，研究主流是关心软件的品质和认为软件需要定量化度量。

目前有超过上千种软件度量方法被软件研究人员及从业人员提出，并且到今天有超过5000份论文出版发表。

出于这个缘由，我们有必要对软件度量的发展历程做一个全面了解。

当然，本文只是讨论软件度量发展过程中的一些里程碑。

软件度量或者发表论文的全面综述可以参考以下文献[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世纪末，物理学家LordKelvin（1824-1904）明确表示[97]：

当你能度量你所讲的内容，并且能用数据表达，那你是确实明白你所讲的内容。

但是如果你不能度量你所讲的内容，也不能用数据表达，那你的认知是微不足道的和不能让人信服的那种，那只是认知的开始，几乎没有到科学的思想境界。

测量理论的科学家们支持在科学中应用度量的观点。

FredS.Roberts[159]在其一本杰出的有关测量理论著作中指出：

发展成熟的学科如物理学和欠成熟的学科如心理学或社会学最大的区别是他们对研究对象的度量程度。

在软件工程领域，度量已经被讨论了25年。

软件开发和维护的巨大成本扩大了支持设计标准和通过度量进行管理决策的科学基础的需要。

Curtis1980已经指出[43]：

如果我们想将简单的编程转换程工程学科，就必须将严格的科学程序应用于软件系统开发研究，而这些科学程序的核心就是开发度量技术和决定相互影响的关系。

下面是进行软件度量的问题所在，其中包括：

1、应用度量是否可能在设计阶段预测软件系统潜在的错误。

2、是否可以在软件的设计模型中抽取些定量特征使我们能预测软件的可维护性。

3、程序模块代码是否存在一些定量的关键属性能让我们可以预测进行模块测试的困难程度和通过某种程度测试后隐含在模块中残余错误数。

4、是否可能从设计说明书中抽取出定量属性来预测开发如设计所描述那样的软件的工作量。

5、是否可以从一个子程序代码中提取定量的属性来帮助我们预测测试这个子所需要的工作量

6、是否有在需求分析阶段可以预测项目规模的特征。

7、确定一个设计的质量,需要什么样的软件度量手段。

8、以ISO9126标准的软件品质数字属性为基础，什么样的软件度量是合适的。

那些想用软件度量或者正在使用软件度量的人们最大的问题是软件度量对从业人员有什么好处。

我们认为，Grady用明确的方式阐明了软件度量的需要和好处。

1992年Grady[64,65,66]中肯地阐述了软件度量的合适性。

软件度量用于度量软件产品或软件开发过程的特定属性。

我们使用软件度量的目的如下：

1.估计的基础,

2.跟踪项目进展,

3.决定（相关）复杂性,

4.帮助我们理解我们什么时候有文档化的质量状态

5.分析缺陷,

6.实验验证的最好实践.

简而言之:

它帮助我们做出更好的决策。

当然，还有许多其他需要软件度量的论述，但是全部论及会超出了本文的范围，本文就不作陈述。

软件度量的基础工作

在六十年代，主要是七十年代，人们就建立了软件量度和度量的基础性工作，根据这些早期工作，八十，九十年代出现了更进一步的工作成果。

提出软件度量的原因是基于大家都认为结构和模块化对开发可靠软件非常重要。

许多软件专家认为软件系统模块化越高且模块结构越简单，软件可靠性越能得到保证[168]。

其实，模块很早就被研究讨论。

为了使得模块和其他模块没有结构关系，Parnas建议模块应该结构化[148]。

Myers描述了模块强度（modulestrength）的观念,Yourdon在1975论述了模块性。

如Porter在文献[153]中指出的那样，这些因素影响软件的成本和质量。

最早的软件度量单位是LOC，直到现在人们还在讨论和应用它。

1974年Wolverton第一次正式用LOC度量程序员的生产率[197]。

他提出了客观的指标：

“人月”，作为生产率的度量单位，并且他认为他研究的内容可以作为典型的代码率。

文献[178]指出，LOC能作为度量单位的基础是程序的长度能预测程序的特性如可靠性和易维护性等。

尽管如此，或许是由于这种度量太简单吧，它受到学术界严厉的批判。

如Walston和Felix在文献[192]那样，估计的代码行和实际的代码行在软件合同协商和执行期间用作生产率的评估不太一致。

在六十年代，源代码行SLOC（SourceLinesofCode）是以80列为一行计算。

在1983年Basili和Hutchens[15]建议应该把LOC作为其他度量单位可以比较的基本度量单位。

我们认为有效代码行比源代码行作为度量单位好些，因为作为一个最小的度量单位，完全凭经验就可以知道，LOC有时是没有任何东西。

超过上万篇论文提到过LOC度量单位。

Rubey等人在1968年发表的论文[165]可能是最早的关于软件复杂性论文。

在这篇论文的文献列表中没有更早公开发表的参考文献。

1979年，Belady提到一篇1971年关于软件复杂性的论文[18]。

Belady写道：

在1974年，很少有关于复杂性的著名研究，程序复杂性的工作就更少。

那时，我和Beilner教授在英国大学帝国学院共一个办公室，那是我们由兴而发地讨论过“复杂”程序和大规模程序的问题。

有时候我们会问，什么是复杂性？

是否可能提出合理的定义？

直觉的复杂性概念是否可以定量计算。

由于我们不能回答这些问题，我们就转而面向查文献。

立即，在众多关于复杂性哲学论述中，我们找到了一篇由VanEmden写的博士论文：

“复杂性分析”[54]。

VanEmden的工作是基于有关信息理论形式主义的传统可能性理念，似乎适合连接系统的复杂性模块化，如将程序建为模块。

早在六十年代，出现了成本估计模型Deplhi[76]和Nelson'

sSDC。

1975年，Kolence创造性提出了软件物理的概念[108]，1977年，Halstead引入了软件科学的这个术语。

在这个术语的潜在意义是用科学的方法来分析软件的特性和结构。

Kolence的理论综合了那些惯用的性能量度，如往返时间，系统可用性和响应时间以及惯用的管理量度如生产率，每单元服务成本，以及预算等。

软件物理是专业处理计算规模和工作量的最早理论之一[130]。

McCabe[211]和Halstead[71]在70年代中期提出的度量方法是非常著名的度量方法，直到今天还被激烈讨论。

McCabe根据图论定义了一个术语“圈数”来得到一种软件复杂性度量方法。

McCabe说圈数是流程图中最少路径条数。

他论述到，最少路径数可以确定程序的复杂度（译者注：

这里说的是著名的CyclomaticComplexityMcCabe圈复杂度）：

其全部策略是通过计算线性独立路径条数v（G）来度量程序的复杂性，通过设置圈复杂度v（G）上限（代替仅仅使用物理规模控制）来控制程序的“规模”，并用圈复杂度作为一种测试方法论的基础。

McCabe也提出度量基本复杂度，基本复杂度可能是第一个从根本上分析非结构的量度。

1989年Zuse等人[200,201]指出McCabe复杂度可以通过三种简单的运算来刻画，作者从度量理论得出这个概念。

Halstead度是基于程序源代码。

Halstead指出估计工作量，或者程序员工作时间，可以用运算符，运算元或语法数的函数来表示[70]。

Halstead方法已经被包括IBM的SantaTeresa实验室[38],，通用电气公司，通用汽车公司[70]等许多单位使用，起初是用于软件度量试验。

今天，用的最多的Halstead量度是度量长度，容量，难度和工作量。

Halstead在七十年代末期去世了，很遗憾他不能在今天解释他的度量方法。

1977Laemmel和Shooman[110]验证考察了齐普夫定律（Zipf'

sLaw），齐普夫定律本来是为自然语言提出的，他们扩展这个理论，把这个技术应用到程序语言。

（译者注：

齐普夫定律是美国学者G.K.齐普夫于本世纪40年代提出的词频分布定律。

它可以表述为：

如果把一篇较长文章中每个词出现的频次统计起来，按照高频词在前、低频词在后的递减顺序排列，并用自然数给这些词编上等级序号，即频次最高的词等级为1，频次次之的等级为2，……，频次最小的词等级为Ｄ。

若用f表示频次，r表示等级序号，则有fr＝C（C为常数）。

人们称该式为齐普夫定律。

）齐普夫定律也适合计算机程序的运算符，运算元以及运算符和运算元的联合。

他们的验证结果表明，齐普夫定律对计算机语言也非常适合，而且可以得出和那些Halstead度量相类似的复杂性度量。

1978年，伴随McClure提出的一个软件复杂性度量的提议[123]，其他两个复杂度度量方法Interval-Derived-Sequence-Length（IDSL）和Loop-Connectedness（LOC）被提出来[74,201]。

他们是基于流程图的间隔还原。

但是，这两种方法不是很有名。

Rubey，VanEmden的研究工作和Hecht度量已经大部分被遗忘，其中，1992年，Khoshgoftaar等人使用了VanEmden度量作文复杂性度量的基础[101].。

1977年，Gilb[62]出版了一本标题为TomGilb：

软件度量的书，这是软件度量领域的第一本书籍。

1979年，Belady[18]提出了theMeasureBAND，该方法对嵌套是敏感的。

JONE[90]在1978年发表了一篇讨论程序品质和生产率的论文，有趣的是，其中，在这篇论文中是他对度量单元的考虑。

为了度量应用软件的开发生产率，Albrecht[2]在1979年提出了功能点（theFunction-Pointmethod）方法。

1980年，Oviedo[146]开发了一个程序品质模型。

这个模型将控制流和数据流复杂性一起处理。

Oviedo通过一个方法计算控制和数据流复杂性来定义程序的复杂度。

1980年，Curtis[43]发表一篇关于软件度非常重要的论文。

在这篇文章中，Curtis论述了：

科学和度量，一些度量的基本观念。

他指出：

欠成熟的科学，理论和实际的关系组成不是建立在正式的数学基础上，而是逻辑假设。

并且，其中，他写到：

我们的度量技术越严格，理论模型越能够彻底地测试和校准。

因此，发展软件工程的科学基础依赖于改善基础构造元素度量方法。

文章中，Curtis提到了JONE的论文[90]。

Jones的文章[89],[90],[91]也是软件度量领域先驱之一。

1981年，Ruston[166]提出了一种用多项式方法描述程序流程图的度量方法。

这种度量方法流程图的元素和结构两个方面都计算了。

Ruston似乎适合网络测量，但不如McCabe度量方法那么广泛应用。

1981年，Harrison等人[72]提出了一种将流程图分解为行列为基础软件复杂性度量方法。

按照Harrison等人的观点，可确定在结构化，特别是非结构化的流程图中的节点嵌套层次。

这种方法是对Dunsmore，Belady等人度量方法[201]一个非常重要的扩展。

Dunsmore，Belady等人只是针对D-Structures流程图进行了定义。

D-Structures指是Dijkstra结构，Dijkstra被西方学术界称为“结构程序设计之父”）。

1982年，Piwowarski等人[152]建议修改Harrison等人的度量方法，因为这些度量方法有些缺点，如非结构流程图可能比结构流程图的复杂度低些。

Troy等人提出了24种度量方法的集合来分析软件系统的模块性，规模，复杂性，内聚度和耦合度。

特别是内聚度和耦合度是软件系统易懂性的基本标准。

软件（复杂性）度量基本分成模块间和模块内两部分，耦合度和内聚度概念明确的度量是以Constantine的研究工作为基础。

内聚度是Emerson在1984年提出的[55,56]。

1982年，Weiser提出了切片的概念[193,194]。

以切片概念为基础，1986年，Longworth等人[119]和1991年Ott等人讨论了内聚度度量。

此外，还有其他一些论文在度量内容上使用到内聚度，如Dhama的文章[49],Lakhotia的文章[113],Patel等人的文章[209],Rising等人的文章[158],Selby等人的文章[171]和Thuss的文章[189].Ott等人的文章是内聚度软件度量的基础。

1981年一个由工程界和大学的人员组成的研究小组（VictorBasili,LesBelady,JimBrowne,BillCurtis,RichDeMillo,IvorFrancis,RichardLipton,BillLynch,MervMler,AlanPerlis,JeanSummet,FredSayward,andMaryShaw）讨论和研究了艺术状况和软件度量领域的研究情形。

在这个小组中，DeMillo等人[48]讨论了软件度量和其他科学对比问题。

他们讨论得很深刻。

但他们没有给出序位尺度和比例尺度的软件度量使用条件。

八十年代，美国空军罗姆妍制中心（RomeAirDevelopmentCenterRADC）做了几次软件度量方面的调查研究[156]。

这个调查研究了软件度量和软件品质属性（如可用性，易测性和可维护性等）。

这些调查研究的目的是开发出量化面向用户和面向管理技术的软件品质框架来量化软件产品质量。

美国国家航空和宇宙航行局（NASA）的软件工程实验室（SEISoftwareEngineeringlaboratory）也是从事软件度量比较早的单位[136]。

它是少数使用软件度量超过15年多的组织[143]。

最近和NASA有关联的是Basili的研究工作[11,[12]。

（译者注：

80年代末到90年代初，软件工程实验室（SEL）在VicBasili，ScottGreen，RosePajerski，JonValett等人的领导下进行了一系列净室试验）

软件设计度量

1977年，Gilb提出了简单的软件设计度量[62]，叫做模块数，然而，在1978年Yin和Chapin等[34]

提出了更加成熟的设计度量方法。

这些度量也许是第一个可以在软件生命周期的软件设计阶段应用的度量方法。

其他提出可用于设计阶段的软件度量方法有Bowles[31],Troy等[169],McCabe等[134].

Card等[33],Sheppard等[157],Ligier[105,106],和Zuse[182]。

在Stevens,Myers和Constantine[161]工作基础上，开始了许多为衡量大型软件系统相互关联性的软件（复杂性）度量工作。

软件系统组件之间包含多种相互关系，如数据，控制和组件间的先后顺序。

1981年，Henry和Kafura提出了相互关联性度量方法（"

InterconnectivityMetric"

）[77]。

这种方法基于扇入扇出模型的倍增。

在八十年代末，这种度量方法的修正版本被提出来，它综合了多种模型组成，如Halstead度和McCabe度（theMeasuresofHalsteadandMcCabe）和相互关联性度量的综合。

其他方法，比如Selby等人[151]和Hutchens等人[81]，基于Myers和Stevens等人[161]的早期工作，提出了基于数据绑定的软件度量。

其他软件设计度量研究工作可以参加文献[29,13973]。

在1983至1984年期间，为分析大型系统，Hall提出了软件复杂性度量[68,69]。

虽然这样，但是他的方法非常直觉，已经几乎没人提起了。

80年代末和90年代初，开始了一些研究软件度量标准化工作。

二个IEEE报告[82],[83]提些规范化的软件度量措施。

不幸地是，在这些报告论述到的软件度量方法是开发过程度量和软件生命周期的维护阶段的度量，没有发现任何软件复杂性度量。

成本估计度量

成本估计模型是第一个使用度量的概念。

下表给出了一些费用估计模型概要。

模型名称

提出单位

时间

Delphi

RandCorp.（美国兰德公司）

1966

Nelson'

sSDC

SDC（美国科学资料中心）

Wolverton

TRW（美国伍尔德里奇公司）

1974

RCAPrice-SSystem

RCA（美国无线电公司）

1976

Halstead

1977

WalstonandFelix

IBM

1977

Function-pointMethod

1979

ParrModel

1980

COCOMO-Model

TRW

1981

SOFTCOST

JPL（美国喷气推进实验所）

1981

BaileyandBasili

NASA

BangMetrics

1982

MARKIIFunctionPoints

1988

PfleegerModel

1989

1979年Albrecht提出了功能点方法[2,3]。

功能点（Functionpoints）来源于需求说明书。

这种方法可以用于软件生命周期的需求分析阶段，今天在美国和欧洲广泛应用。

1988年，Jones[92]一个Albrecht功能点方法的坚强支持者，为使得功能点方法适用于实时和嵌入式应用软件，提出了一种扩展的功能点方法。

Jones把他扩展的功能点方法叫做特征点（featurepoints）。

他引入了一个新参数，叫运算法则，并降低了原来功能点分配给数据文件参数的权重。

在1988年和1991年Symons修改了这个模型[162,163]。

他提出了一种扩展的叫MarkIIfunctionpoints的功能点方法。

该方法解决了Albrecht方法的以下弱点：

1、系统构件划分过分简单化

2、系统构件的权重分配太主观

3、内部复杂性考虑相当不充分

4、14个因素重叠并且权重的范围总是合法的。

功能点方法是通过计量包括对外部输入、外部输出、外部查询、内部逻辑文件和外部接口文件的数目，由14个因素决定加权因子进行加权计算而得，而14个因素的界限划分又重叠部分，如划分系统复杂度级别和数据通讯复杂度的级别就很难说没有任何关系，而Albrecht方法就直接认为分配给这两类因素的权重是有效的，没有考虑因素间的重叠性）

1981年，在LOC量度的基础上，Boehm提出了COCOMO（ConstructiveCostModel）模型[23,24]

Kitchenham对成本估计模型和度量做了一个好的综合评述[58]。

通常有四类成本估计方法：

专家评估，类推，分解和估计方程式。

非常有趣的方法是分解法。

分解法包括从对产品的分解到组成它的最小组件的分解，或者将一个项目分解成非常小的具体任务。

先估计生产各个最小组件生产或完成最小任务的工作量成本。

项目的成本是各个组件的总和。

这类预测只有采用大众结构如LOC和McCabe[202,205]那样才是合适的。

COCOMO模型一种可能合适的预测模型，它采用了大众结构。

它定义开发一段程序的工作量这个外部变量和LOC度量的关系如：

EFFORT（P）=aLOCb

其中，P表示一段程序，并且a,b>

0。

如LOC外其他软件度量方法，只要采取了大众结构就可以使用。

其他成本估计模型还有Putnam提出的Raleigh曲线模型[155]和DeMarco提出的Bang度量[47]。

目标驱动度量范例，用户视域和观察点

1984年Basili等提出了目标驱动度量GQM（Goal-Question-Metric）范例[210,17,163]。

GQM使用定义的度量目标。

GQM基本理念是从度量的目标和问题驱动软件度量。

GQM方法以一套怎么表示出一个可理解的目标，提什么类别的问题和怎么样将他们重新定义为问题的向导来统一各种度量。

Fenton[59]和Zuse等[200,201]也支持这种基于人类思维观察点的进行软件度量的理念。

Fenton在论著中称为用户视域（user-view），Zuse等叫其为复杂性观察点（aviewpointofcomplexity）

测量理论和软件度量

以Bollmann和Cherniavsky的论文[25]，Bollmann的论文[26]（在该文中，测量理论用于评价信息检索系统方面的度量）为基础，1985，Bollmann等人和Zuse[198,27]将这些论文论及的测量理论应用到软件复杂性度量，如Roberts[159],Krantz等人[109]和Luce等人[120]描述的那样，他们根据测量理论给出度量的条件。

在文献[27,198,199,200,201,202]中提出了在某些尺度层次应用复杂性度量，如序位，等距或等比尺度的条件。

另外，测量理论通过假设的经验关系以及进行合成和分解操作的条件给出了软件度量的经验诠释，这是一种软件工程的重要策略。

据文献[201]，有超过90种软件独立方法应用了这种理念。

1993/1994年，Bollmann和Zuse将测量理论方法扩展为一种预测模型，并且Zuse在1994提出了确认预测模型软件度量方法的经验条件[205,207]。

1995年，Zuse等给出了软件度量的