软件度量的一些方法

软件度量的一些方法
http://cuiyingfeng.blog.51cto.com/43841/6775/
在前面我们已介绍了组成软件度量的几个方面。在这里我们将先给出关于这几个方面的一个纲要介绍。在后面我们还会作进一步具体的阐述。

当我们不从高层次的概念级来看软件度量及其目标的时候，我们很容易把这些活动看成是不同而且毫不相干的。我们现在希望表明他们是怎样恰如其分地嵌入我们的框架的。也就是我们度量的是那个属性(是外部属性还是内部属性)、他们是估计呢还是预测。当然，我们必须考虑那个过程、产品或资源与之相关。



一、费用和工作量估计

最初引入软件度量的动机完全是出于管理方面的考虑。管理者希望在软件开发周期的早期就能够预测软件的费用。于是涌现出了一大批对软件开发的费用和工作量进行估计的模型。其中最著名的有Boehm的COCOMO模型、Putnam的SLIM模型、以及Albrecht的功能点模型。在这些模型中，对工作量进行估计的通用方法是把工作量预定义成一个含有几个变量的函数。如产品的大小被定义为代码行数（在COCOMO模型中）而在Albrecht的模型中则被定义为功能点的数目（可以从产品的功能特性得到）。

Bolhm的简单COCOMO模型声称开发过程所需要的工作量（E /每人每月）和软件系统大小（S 千行交付源语句）的关系是：E ＝ aSb                     

其中a和b是随开发的软件系统而不同参数。下表是COCOMO的一些取值的例子：

开发模式               a的取值 b的取值

Organic（in-house 部门）     2．4   1．05

Embedded（实时，受限）     3．6   1．20

Semi-detached（以上二者之间）   3．0   1．12 

表B-2 COCOMO的一些取值的例子 

假设我们在自己的环境中需要使用COCOMO的模型的公式在软件需求分析阶段进行工作量预测。那么我们首先需要一个预先确定的方法来决定（预测）参数a、b和预测出最后系统的大小S。

我们在这儿使用的不是COCOMO的模型，而是COCOMO 的预测模型，即该等式。决定模型参数的办法是由过去历史、专家估计、和主观判断三方面组合而成的对参数的综合判断。这个理论基于参数"插入"原则提供了对现成的结果进行解释的各种不同的方法。因此说COCOMO模型用于费用估计是得出的费用是不确定的，因为使用不同的预测步骤后，相同的数据得到的结果是不同的。这种情况也适用于其他的各种模型和各种方法。

在COCOMO模型更高的版本中（或其它的费用估计模型中）还考虑了需求规格说明书（一种产品）中的大量的内部和外部属性；另外还考虑了用户提供的产品和资源的一些属性。例如使用了15个费用影响因素：

类型         费用影响因素

产品属性     所要求软件可靠性，数据库规模，产品复杂性

过程属性     是否使用现代编程方法，是否使用软件工具，要求的开发进度

资源属性     执行时间方面的限制，主存限制，虚拟机发散性（volatility）计算机 

周转量（turnaround）

人员属性     分析能力，应用经验，编程能力，虚拟机经验和程序设计语言的经验表B-3 费用影响因素 

每个因素用六个标尺：非常低、低、中等、高、非常高、极高。 每个因子还有一个调节因子（正常值为1）。 

简单的COCOMO模型和Albrecht的功能点费用估计模型（后面将介绍）声称：工作量是一个产品属性的间接度量。在这两个模型中，这个属性都与软件的"规模大小"这个属性有关。在Albrecht的模型中规模大小这个属性是用功能点的数目（FPs）来度量的；我们可以看得出这是有关规格度量。在这里规模大小与有关特定的称之为功能性的属性是同义词。而在COCOMO的模型中，规模大小被定义为源代码语句的数目。这是一个最后系统完成之后的属性。因此当使用该模型进行工作量预测的时候，我们必须在规格说明书阶段预测产品的属性，即为了获得工作量的预测，我们使用的方法涉及到要预测一个将来产品的属性的问题。这是不能令人满意的。因为这两个预测问题同样困难。另外一个问题是源代码的数目只考虑到了规模大小的一个方面即长度。

二．生产率度量和模型

管理的压力也致使产生了很多用来进行一些估计的度量和模型，这些模型主要用来估计在不同的环境下、不同的软件开发阶段中开发小组的生产率。在这里我们讨论一下度量资源的一个属性：在特定的环境下的开发小组（团队或个人）。通常用于进行生产率度量的模型是把生产率作为开发小组的输出（价值）和开发小组的输入（费用）的比值的函数。在这种情况下，资源的生产率这个属性被认为是过程属性度量和产品属性度量的一个间接度量。

这表明生产率是价值和费用的函数，并试图用度量的形式来决定各个组成部件。这种方式比传统的方式更精确。以前管理者所采用的是一种非常简单的度量方法：即用输出的大小（通常用代码行数表示）与工作量（通常为人每月）的比值来表示。

如今，普遍认为这种把软件的输出与软件的代码行数等价起来的做法不是很好，有一点危险性。Albrecht提出了功能点的概念作为功能性的度量。如果功能点（FPs)确实反映了功能，则我们可用如下公式来对生产率加以度量：实现的功能点数/人－月数

Albrecht的功能点计算方法如下：

1） 计算未调整前的功能数UFC：从系统的规格说明书中找出以下的条目数：

-外部输入；

-外部输出；

-外部请求：交互式的，要求响应的；

-外部文件：代表机器可读的外部系统的接口；

-内部文件。

2） 加权：按下表进行：

加权类型     简单   平均   复杂

外部输入     3     4     6 

外部输出     4     5     7 

外部请求     3     4     6 

外部文件     7     10     15 

内部文件     5     7     10 

表B-4 加权的权重因子 

3） 求和：     UFC=∑变量i的数目×权i             i =1到15 

4） 考虑技术复杂因子TCF：

TCF=0.65+0.1×∑F i   i = 1到14 

F i 取值范围为从0到5。即0,1,2,3,4,5。

0表示与该因子无关；5表示与该因子有实质关系。参见表B-5。



F i     技术复杂因子

F1     要求可靠性支持与恢复

F2     涉及数据通信

F3     有分布式功能

F4     性能要求

F5     经常性的配置管理 

F6     联机数据输入 

F7     操作方便的要求 

F8     联机更新 

F9     复杂界面 

F10   处理复杂 

F11   可复用 

F12   安装方便的要求 

F13   多站点 

F14   设施的变更 

表B-5   技术复杂因子 

5）计算功能点：       FP=UFC×TFC 

Albrecht方法的优点是不需要建模，就可以进行计算。

其缺点是需要考虑的技术因子，在实质上涉及了系统内部的复杂性概念，及从用户观点出发的复杂性概念。而人们总是希望能从纯功能的度量，或直接进入生产率的度量。   



三．数据收集

即使是最简单的费用/工作量估计模型或生产率度量模型都依赖于精确的过程属性度量、资源属性度量以及一个小范围的产品属性。一般来说，产品度量只需要人为的极少的干预，而过程度量和资源度量则不是这样。因此，大量的数据收集工作关心的是怎样设计出严格的步骤来收集过程和资源有关的，与以前已识别出的基本属性的精确的数据。

手工收集度量数据容易有偏差，利用自动工具收集是获得度量数据的重要一环。但仍然常常需要人工收集。

关键是有：简明的收集步骤；减少不必要的记录；培训记录人员；

迅速以有用的方式把分析结果反馈给数据提供者，以支持其工作；验证在中心收集点上收集的一切数据。很显然，为了获得对软件过程的控制和测试，预测和度量费用与生产率的活动依赖于细致的数据收集。现在，数据收集其自身已被认为是一种学科。Grady和Caswell 曾在"Software Metrics: Establishing a Company-wide Program"一书中详细地描述了一个进行精确的数据收集的管理性的框架。这个框架建立在他们开发一个度量程序的过程中获得的经验基础之上。在这里软件度量的概念被具体化为了一个纯管理性的问题。Basili 和 Weiss 描述了进行有效数据收集的基本方法论；而Mellor则描述了进行数据收集对可靠性度量的重要性。



四．质量模型和度量

质量模型所作的工作与产品度量所作的工作是大致相同的。

在前面我们注意到费用和生产率都依赖于不同过程阶段产出的产品的质量。图B-2的生产率模型明显考虑了输出产品的质量这个因素；它使用了一个过程的内部属性－发现的缺陷数来度量质量。在前面我们也简单地描述了使用质量模型的一般方法。现在，我们发现"质量"这个因素通常与产品的外部属性有关；而"准则"这个因素则通常与产品和过程的内部属性有关；"度量"通常与内部属性的度量有关。在这里我们都使用了"通常"两个字，这是因为使质量模型化的工作有很多令人困扰的地方。

大多数试图对软件的费用和生产率进行估计的专家们都声称：不考虑输出（例如生成的产品）的质量，要得到精确、有意义的模型和度量是不可能的。因此人们在构造所谓的质量模型方面也作了大量的工作，这些质量模型可被输入到精巧的费用和生产率模型中。一个非常有名的模型是McCall的FCM模型(Factor Criteria Metric Model) 这个模型是基于这样一种想法：几个最主要的比较高层的因素影响着软件的质量， 其中包括可靠性、 可再用性等 （见图B-3）。而这几个因素又是由一些比较低层的如模块化、数据通用性等标准决定的。标准比因素相对来说要易于度量一些。实际的度量是针对这些标准而言的。模型描述了因素和他们所依赖的标准之间的一致性。因此，我们通常以度量因素所依赖的标准的方式来度量因素。在最新的IEEE的计算机方面的报道中已提议把这种思想作为度量软件质量的标准。



§3.5。可靠性模型

位于软件质量度量下面的基本工作是围绕度量和因此每个特定的产品的属性而开展的更细致的工作。在后面我们可以看到对软件的可靠性进行度量和预测所展开的工作可以被看成是一个严格而有效的对软件的一个重要的质量特性

图 B-3   软件质量模型:(IEEE推荐): 



五．可靠性模型

可靠性是在所有的质量模型中都使用的、一个高层次的产品外部属性。在产品中与可靠性这个属性有关的只有可执行代码。通常这个属性被认为对代码来说是最重要的质量属性；因此研究和预测可靠性其本身已成为了一个学科研究分支。

一些人认为可靠性可以用一些内部过程度量象正式测试阶段发现的Bugs的数量、测试阶段的平均故障时间等来度量。事实上这种观点是不正确的。这我们将在后面加以讨论。



六、性能评价和模型

性能评价主要关注于对产品的效率这个属性的度量。这包括时间效率（对给定的输入的反应时间和计算速度）和空间效率（对给定的输入所需的存储量）。但通常我们只考虑前者。和可靠性一样，效率是一个出现在大多数质量模型的高层的产品属性。一般性能评价主要关注于度量可执行产品的外部属性--效率。一般人们可能会得出这样一个结论：在某种意义上，效率只能是一个外部属性（如同可靠性）而不可能是其他类型的度量。然而，即使在对编译器和目标机器几乎一无所知的情况下，无论源代码是何种表示形式，我们都可以相当精确地对效率进行估计。尤其对核心算法所进行的高层次描述，通常足以很好地预测实现后的代码效率。 

在时间效率方面，通常的做法是首先决定关键输入和基本的机器操作；然后决定基本操作的次数并把它作为函数的输入大小。这一方面的工作（传统上是计算机科学家所作的主要工作）被称为算法分析或算法复杂性，这里的复杂性和效率是同义词。从我们的框架来说，说法的效率是一个内部属性，它可以被度量并用于预测可执行代码的外部属性－效率。

计算复杂性与时间复杂性是密切相关的，也是我们的软件度量框架的一部分。在计算复杂性的度量中，我们感兴趣的是对一个"问题"的固有的复杂性的度量，这里的"问题"是指需求规格说明书（从我们的意义上说是一个产品）；而复杂性则是解决这个问题的最快的算法的效率。例如：假设我们的需求规格说明书有这样一条：

对一个N个结点的网络（图的一种）来说，已知每一对结点之间的距离，要求计算出遍历网络中的每一个结点的最短的路径。

这条需求规格说明（即寻找一个解决售货员旅行问题的通用算法〕的复杂性是很高的。这是因为最底层的问题属于一个被称之为NP－Complete的复杂性很高的问题。

这也是关于软件的某个特定属性的度量。性能评价方面所作的工作包括外部可看到的系统性能如反应时间和完成率等。同样，还有一个系统内部工作的性能问题，我们称之为算法的效率（可具体化为计算和算法的复杂性）。其中后者也与以一个优化方法的效率来度量的问题固有的复杂性有关。 



七．结构和复杂性度量

很多高层次的质量属性如产品的外部属性等很难进行度量。因此我们通常被迫考虑对产品的内部属性进行度量。Halstead的度量就是这样的一个例子，它定义在源代码级上。也有相当多的度量被定义在源代码或设计的图形模型上。他们度量的是特定的内部属性象控制流结构、信息流和不同路径的数目。

Halstead的软件科学提出程序的复杂度V（程序工作量）

H = n1×log n1+n2×log n2

其中n1表示程序中的不同运算符数；n2表示程序中的不同运算对象数。 

N =N1+N2

其中N1表示程序中的运算符总数；N2表示程序中的运算对象总数。

    n = n1+ n2 

    V = N×log（n1+n2） 

Halstead利用V进一步估计编程语言的抽象级别L、程序员工作量E和程序潜在错误数B： 

    L = Vmin/V或 L =（2/ n1）×（n2   /N2） 

    E = V/L或E = H×log（n1+n2）×[（n1×n2）/（2×n2）] 

    B = （N1+N2）×log（n1+n2）/3000 

Halstead的重要意义在于：度量能根据词汇表来进行，也就是说，在程序编码没有完成前，就可以进行度量。特别是在许多场合，Halstead的度量与实际十分接近。当然，这方法有其缺陷：如不同语言间相同运算符的关系及嵌套关系等都未考虑。因此，在一些复杂情形不能处理。

但这个领域的大量工作受到了一些说法的阻力而夭折，这些说法认为这样的度量也同时度量了复杂性的外部属性；并声称：和类似费用和工作量的过程属性一样，单一的复杂性度量就可以作为很多外部属性的预测，是可疑的。

结构复杂性度量所作的工作被看作位于度量特定质量属性的工作之下。所期望的属性象可靠性和可维护性等只有在有代码的几种版本的情况下才能度量出来。但是，我们仍希望能预测软件的那一个部分有可能不可靠而这个部分需要比其它部分更多的维护。因此，我们的思路是我们能在执行（或根本不需要〕这个软件之前能得到软件的结构表示并对它的结构属性进行度量。我们这样做是希望我们能建立经验预测理论来支持质量保证、质量控制、和质量预测。 

除了从代码行长度来估计外，McCabe（1976）提出了根据程序的回路数目进行复杂性度量，从而估计程序的可测试性、可理解性（可维护性）。计算回路复杂性公式如下：

          M = V（G）= e - n +2p 

其中：G为代表程序控制流的图；e为G中的边；n为G的节点；p是G中不连通部分数量。M或V（G）为G的回路数目。 

McCabe复杂性度量的物理意义是：程序中的分支或回路数目增加时，意味着复杂性（测试难度）也增加。有数据表明：在回路数目大于10的模块中发现的错误比回路数目小于10的模块要高21%。所以应把模块的回路数目保持在小于10。

McCabe复杂性度量的缺点是没有考虑控制的不同类型的影响；也没有考虑软件规模对复杂性的影响。因此，一些场合也不一定适用。但是，不管这些局限性，McCabe复杂性度量的简单，易用；使其一出台就大受欢迎。在选择方案和估计纠错费用等方面发挥优势。



八、GQM法（Goal/Question/Metric）：

1、基本概念：

目标/问题/度量方法用来测量和评价一组可操作的目标。建立在详尽的说明项目和组织的需求情况下，系统地把软件过程，产品和重要的质量远景结合起来。

目标是模型中可操作、易管理及可识别的。通过把自身提炼为一组能够抽象出适当信息的可度量问题。为收集和提供这些问题和模型的解释框架，依次定义一组精确的度量或数据。 当初开发目标/问题/度量方法是用于评价美国国家航空和宇宙航行局和高达德空间飞行中心环境下的一组工程项目的缺点。包括一组场景学习试验，然后扩展为用于不同类型的试验方法，包括受控的试验。

尽管当初目标/问题/度量法是用在特定的环境下，定义和评价特定的工程项目的目标，但它的用途已经被推广到更大的范围。

目标/问题/度量的应用包括：

（1）为生产能力和品质（例如用户满意程度，及时交付能力，品质的改进等等）开发一套共同的，协作的设计目标；

（2）在可度量的方式下，尽可能完整地产生问题（在模型的基础上），来定义上述目标； 

（3）需要收集详尽的度量来回答这些问题，并跟踪过程和产品与目标的一致性；

（4）发展数据收集机制；

（5）实时地收集，验证和分析数据，为项目的矫正提供反馈，对数据进行事后分析，评价与目标的一致程度，为未来的改进作出建议。

2、Motorola公司目标/问题/度量法的实例：

这里，我们以Motorola公司为软件开发的质量政策运用目标/问题/度量法为例，说明目标/问题/度量法的具体实施要点。

①基本条件如下：

目标： 

目标1：改进项目计划；

目标2：增强缺陷遏制；

目标3：增强软件可靠性；

目标4：减少软件缺陷密度；

目标5：改进顾客服务；

目标6：降低不一致损失费用；

目标7：提高软件生产率。 

测量范围：

交付的缺陷总量和交付的单位产品的缺陷量；

过程中的总工作量；

进度相符程度；

估计精度；

未解决的顾客问题数；

时间段：其间问题尚未解决；

不一致的代价；

软件的可靠性。

②运用目标/问题/度量法的具体内容：

  目标1：改进项目计划；

    问题1.1 项目进度的实际值的估计精度是多少? 

度量1.1 进度估计精度(SEA) SEA = 项目实际时间段/项目估计时间段 

        问题1.2 项目工作量的实际值的估计精度是多少? 

        度量1.2 工作量估计精度(EEA) EEA = 项目实际工作量/项目估计工作量 

    目标2：增强缺陷遏制； 

        问题2.1 在产品发布前，目前缺陷侦察过程的已知效果是什么？

        度量2.1 总体缺陷遏制效果（TDCE）TDCE = 发布前的缺陷数/（发布前的缺陷数+发布后的缺陷数）

问题2.2 对一个特定软件产品的软件开发的每个构建阶段中引入的故障，目前已知的缺陷遏制效果如何？

度量2.2 阶段i的阶段遏制效果 (PCE i) PCE i = 阶段i的错误数/（阶段i的缺陷数+ 阶段i的错误数） 

注意：这里对缺陷、错误和故障的定义如下：

错误（Error）：在引入问题的复审阶段找出的问题；

缺陷（Defect）：在复审以后找出的问题；

故障（Fault）：以上二者。 

目标3：增强软件可靠性；

问题3.1 什么是软件的失效率？如何随时间而变化？

度量3.1 失效率（FR）FR = 失效数/执行时间 

目标4：减少软件缺陷密度；

  问题4.1 什么是过程内部故障的标准化数量？什么是过程内部故障数量？

度量4.1a 过程内部故障（IPF）IPF = 由于软件增量开发所引发的过程内部故障/与装配相当的软件规模差 

度量4.1b 过程内部缺陷（IPD）IPD = 由于软件增量开发所引发的过程内部缺陷/与装配相当的软件规模差 

问题4.2 什么是相当于装配规模标准的交付使用软件中目前已知的缺陷内容？

度量4.2a 总体已发布的缺陷总计（TRD总计）TRD总计= 已发布的缺陷数/与装配相当的软件规模总计 

度量4.2b 总体已发布的缺陷差（TRD差）TRD差 = 已发布的由于软件增量开发所引发的缺陷/与装配相当的软件规模总计 

问题4.3 什么是相当于装配规模标准的交付使用软件中目前已知的顾客发现缺陷内容？

度量4.3a顾客发现缺陷总计（CFD总计）CFD总计= 顾客发现缺陷数/与装配相当的软件规模总计 

度量4.3b 顾客发现的缺陷差（CFD差）CFD差 = 顾客发现的由于软件增量开发所引发的缺陷/与装配相当的软件规模总计 

目标5：改进顾客服务；

问题5.1 在月内尚未解决的新问题数是多少？

度量5.1 新的未解决问题（NOP）NOP = 新的、发布后未解决的、且在月内未解决的问题

问题5.2 什么是月末未解决的问题总计？

度量4.2未解决的问题总计（TOP）TOP= 新的、发布后未解决的、且在月末还未解决的问题总计 

问题5.3 什么是月末未解决的问题的平均年龄？ 

度量5.3 未解决的问题的平均年龄（AOP）AOP= 新的、发布后未解决的、且在月末还未解决的问题的总时间/新的、发布后未解决的、且在月末还未解决的问题总计 

问题5.4 什么是月内解决的问题的平均年龄？

度量5.4 解决的问题的平均年龄（ACP）ACP = 在月内已解决的发布后问题的问题延续总时间/在月内已解决的发布后问题的问题数

目标6：降低不一致损失费用；

问题6.1 在月内改正发布后问题的费用需多少？

度量6.1 改正问题的费用（CFP）CFP = 在月内改正发布后问题相关的美元费用 

目标7：提高软件生产率。

问题7.1a 软件开发项目的生产率是什么（按源程序的规模计）？

度量7.1a 软件生产率总计（SP总计）SP总计 = 与装配相当的软件规模总计/软件开发工作量 

度量7.1b 软件生产率差异（SP差异）SP差异 = 与装配相当的软件规模差异/软件开发工作量 

③小结：

我们可以看到度量3.1，4.2a，4.2b，4.3a，和4.3b都是与最终产品的质量有关的度量；度量 5.1到5.4是与软件维护有关的；而度量 2.1，2.2，4.1a，和4.1b是过程内的质量度量。其他的则是与进度、评估和生产率相关的度量。这些度量数据经收集与分析后，可与预计要求相对照，判断是否达到目标要求，以利于管理和改进。除了上述特定要求下的一些度量外，该公司的软件工程过程组（SEPG）有更为详细的GQM技术和其他方面的度量。 



3、模板：

设置目标并将其精炼成为可计量的问题的过程是复杂的，需要经验。为了能够支持这种过程，已经开发完成了一套用来设置目标的模板和一套得到问题和标准的指导方针。这些模板和指导方针反映了我们已经在不同环境下应用目标/问题/度量方法所获得的经验。并将随着我们经验的增长不断改变。可以为任何对象定义目标；为不同的原因，考虑不同的质量模型，从不同的观点，联系一个特定的环境等。有了模板，可以通过给模板的一系列参数填写相应的数值来定义目标。模板的参数包括目的（什么对象和为什么），观点（什么方面和谁） 

，环境特征（什么地方）。

目的：分析一些（目标：过程，产品，其他经验模型）以实现（为什么：描述，评价，预测，动机，改进）的目的。

观点：从（谁：使用者，顾客，开发人员，公司…）的角度来考虑（焦点：花费，正确性，错误的消除，变化，可靠性，使用者的友善性…）

环境：如下的环境（问题要素，人员要素，资源要素，过程要素…）

样例：在如下的环境分析（系统实验方法），从（开发人员）的角度考虑（消除错误效果）模型以达到（评价）目的：NASA/GSFC（美国国家航空和宇宙航行局和高达德空间飞行中心）标准环境，即：处理模型（软件工程实验室（SEL）版的瀑布模型…），应用程序（卫星地面支持系统），机器（运行在VMS下的DEC 780），等等。 

目的是指对象，或是研究的目标，我们要做什么和我们为什么要做。也许会有很多的目标，我们也可能为多个目标服务。显然，目的制定者必须避免特别复杂的对象。有些情况下，把一个复杂的目标分割成为多个简单的目标会比较明智。

观点是指从一个独特的角度或一系列角度来评价问题。制定者可以选择多个方式（例如错误和变化），也可以有多个角度（例如公司和项目经理）。把自己置身于想从中了解信息的人的思维方式中是选择观点的好办法。

通过定义项目的各个方面来定义研究的环境。典型的因素包括：过程因素，人员因素，问题因素，方法，工具，约束条件等等。通常，环境应该包括所有那些可能在各种项目中都是常见的因素，而且成为将来对照的基础数据的一部分。因此环境因素更应该与项目和组织中的目标保持一致。

有了GQM的模板，这技术将有更广泛的应用。



九、统计工具：

在各种度量和质量控制中常需要一些统计类的工具。依西卡瓦（Ishikawa）在1989年总结软件开发中利用度量来控制质量的七种工具。它们是：

检查表（Check list或 Check sheet）：是标出待检查项的书面形式。

帕雷多图（Pareto diagram）：降序排列的频率条。常用于表示相应各类问题。

直方图（Histogram）：表示采样的频率或分布的图形表示。

散布图（Scatter diagram）：形象化地代表了两个区间变量的关系。

运行图（Run diagram）：跟踪所关心的变量随时间的行为变化。

控制图（Control chart）：在运行图的基础上，标出了中心线和上下限。

因果图（Cause and Effect diagram）：如同鱼骨图，在一张图上标出全部原因。鱼骨的头部表示质量特性，后面的刺表示影响该特性的因素；每根刺又看作一个鱼骨，依此类推，可把关系自粗到细都表示出来。



综合运用七个工具和其他统计方法，在软件度量中是和有用的。 



十、主要度量方法汇总：文档，复杂性和规模 

1、主要度量方法：

分类   度量方法     定义   应用对象     应用何处

费用，成效，生产能力和人员 COCOMO，COCOMO II模型   E=CS∑M，其中：E=，C=常量，S=规模，∑=规模指数，M=成本驱动力，

费用，成效和人员评估 不同的美国空军软件项目功能点评价 成效=f（外部输入数，外部输出数，外部查询数，内部逻辑文件数，外部界面文件数，权重因子）

成效，生产力和规模评估 澳大利亚软件开发组织 文档，复杂性和规模 注释数量     文档所缺少的注释数量和一个模块中代码的操作数量

质量控制和预测 美国国家航空和宇宙航行局太空飞船 循环复杂性E=N+2P，E是边缘数，N是节点数，P是连接的部件数   

测试策略和复杂性评估 惠普Waltham分公司 相关复杂性 dΛ，d是域矩阵向量，Λ是域特征函数值的转置矩阵向量     

质量评定和预测 命令，控制和通讯系统语句数 一个模块中执行原代码中语句的数量     质量控制和预测 

美国国家航空和宇宙航行局太空飞船质量 错误/KNCSS每一千个非注释原代码数量中的错误数量   

质量控制和测试的管理 惠普 差错报告数量 一个模块中差错报告数量

质量控制和测试 美国国家航空和宇宙航行局太空飞船 可靠性 错误程度 每个单位时间里错误的数量     

软件发布决定 美国电报电话公司交换系统 剩余错误片段   预见的剩余错误数/预见的总错误数 

可靠性预测，风险评价和测试评价 美国国家航空和宇宙航行局太空飞船 MTTF 平均错误间隔时间     

可靠性预测和风险评价 美国电报电话公司交换系统 剩余错误 软件生命周期里从头至尾预见的错误数     

可靠性预测，风险评价和测试评价 美国国家航空和宇宙航行局太空飞船 剩余错误的风险评价度量 （剩余错误阈值）/希望可靠性目标 

可靠性预测，风险评价和测试评价 美国国家航空和宇宙航行局太空飞船 错误发生时间的风险评价度量 （直至下一次错误间的任务持续时间）/任务持续时间   

可靠性预测，风险评价和测试评价 美国国家航空和宇宙航行局太空飞船 直至下一次错误的时间 从指定时间至下一次错误的间隔 

可靠性预测和风险评价 美国国家航空和宇宙航行局太空飞船 总错误 整个软件生命周期内预见的错误数 

可靠性预测，风险评价和测试评价 美国国家航空和宇宙航行局太空飞船 以上主要度量方法的汇总 



2、面向对象度量方法描述：

随着面向对象技术（O-O）的发展和应用，面向对象度量方法已经变得越来越重要。但是，这些度量方法还没有达到实际应用的水平和象上面提到的那样有确定的应用。下面包括了一些被广泛宣扬和评论的面向对象度量方法。 

度量方法     定义   应用对象     应用何处 

分类权重度量   类的方法的复杂性总计   类的方法复杂性的评价   软件经销商，半导体制造商 

继承树的深度   在继承树中节点到根节点的最大深度   重新使用类的评价 软件经销商，

半导体制造商子类的数量 类继承关系中一个类的直接子类数量 类在设计时影响的评价   软件经销商，半导体制造商 

对象类的配对关系 和一个给定类配对的类数量 模块设计和重用的评价 软件经销商，半导体制造商 

类的响应 类中有可能在收到其他类对象的消息做反应时被调用的方法数量 一个类和其他类通讯的评价 软件经销商，半导体制造商

方法凝聚力的缺乏 相似方法对和不相似方法对之间的差别 一个程序中不同部分之间相互关系的评价 软件经销商，半导体制造商 



十、实验设计和分析： 

我们想用软件度量来比较不同的软件工程方法；我们也想评价软件费用预测系统的精确性；我们还想知道在维护阶段所占费用的比例等等。通常我们也想测试软件工程领域的新理论、解释和预测不同属性之间的不同的关系。在所有上面所说的情况或类似的情况下我们又想知道我们得到的结果是否重要。但是如果不进行精心的实验设计和分析的话，我们是不可能达到上面的任何一个目标的。

实验设计和统计分析技术是把在成熟的软件度量的实践得到的数据转化成能够应用于决策制定过程的信息的必不可少的工具。

至此，我们已对软件度量有了一个全新的认识。这些方法为我们提供了一个构造。计算、和合理应用这些度量的严格的途径。



第四节 软件基本度量

一、 过程度量 

1、度量过程的属性

要评价软件的这里，我们必须度量一些重要的属性如可靠性、可用性和可维护性等。他们都是产品的外部属性，通过观察系统在测试和操作阶段的行为来进行评价；对他们的度量主要是间接通过对过程的其他内部属性的度量得到的。例如：通过分析执行时间的故障次数来计算可靠性整个度量。

意外事件、故障、缺陷、和变化是在开发、测试、和操作一个系统的过程中所观察的基本实体。为了有一个成熟的基础来进行间接度量，我们必须合理地定义对这些基本实体的属性进行直接度量的方法。

1.1度量事件、故障、和更改

在这里提出的一组度量是很实用的，因为他们被应用于在软件开发过程中实际收集到的数据，适用于不同类型的项目；而且，他们也足以严格从而可以保证间接度量的有效性。

1。定义 

在软件开发过程中的一个错误将导致在规格说明或代码中产生缺陷。如果在检查代码或开发过程的中间产品中没有被检查出来而且被消除的话，它将随开发而扩散，最后导致在测试系统时产生错误即故障。如果在测试阶段没有被测试出来的话，错误将一直存在，并在系统被应用于操作时就会暴露出来。错误将被称为缺陷直到软件被应用与执行时为止。它们有可能在软件的执行或检查的过程中被发现。因此我们把错误和缺陷归为一类，因为他们的区别仅仅在与他们被探测到的方式不同而已。

错误将在一次故障中表现出来，也就是在测试或操作中从所要求的系统行为中暴露出来。在测试和操作中，我们将对系统的行为进行观察，当一个未预测到的或是不期望的行为出现的时候，我们称之为一个事件。一些事件的出现可能并不是是系统设计的错误，而是硬件错误或操作错误等等。与故障相对，有分类例程对其进行处理。 

如果检查发现事件是被探测到的一个错误引起的话，我们就需要对产品进行一次更改，消除这个错误。这就被称之为更正性维护，这并不改变这个产品的版本号的基线。更改也被用于完善性的维护即增加新的功能和适应性的维护即修改产品以适应特殊用户的需要，这都将改变产品的基线。因此，将使用不同的版本号：主版本号表明了产品的基线，而次版本号则记录了进行更正的修改次数。

因设计错误而产生的故障是系统在与其环境进行交互时产生的。因此它依赖于硬件配置、使用产品的方式等等。这些都将影响产品的可靠性。一个特征化的环境包括用法和使用模式或称为操作方式。在一次试验中，软件按照操作方式加以执行，这种方式是非常接近于它投入使用后的操作的。

2。度量的类型

设计、故障、和更改用下三种方式度量：

(1).名义上的或普通级：根据实体的一个属性对实体加以归类即把一个更改的原因分为：更正性，完善性和适应性三种。

(2).内部或比例级：例如：度量从产品发布之后事件发生的时间日志。

(3).绝对级：即统计给定类的实体或是给定属性值的数目。例如：统计在产品发布后的一个给定的星期里"严重"事件的数目。

选择一个度量法就是定义一个轴从而可以使用度量对实体进行定位。选择的度量应尽可能独立，这样，一根轴上的度量不会影响到另一根轴上的度量（有时候称之为轴线交叉）。当我们清楚了每个度量能应用于那些属性时我们就能做到这一点。这将变得简单，如果我们能弄清楚每个度量回答的是实体的哪一个问题的话，例如：

地点：给定实体的位置，指定事件发生位置；

时间：指定事件发生时刻；

影响：观察到什么；

表现：特定实体自己如何表现；

原因：为何指定事件出现；

代价：花费多少资源；

计量：观察到多少实体和事件。



3、对事件的度量：可以有以下的记录和处理：

1、 标识安装的代码；

2、 出现的时间区间及执行时间到事件出现的时间的比例关系；

3、 症状：如：

系统丢失（crash 或loop）； 

丢失应用程序； 

丢失一个终端 

丢失数据（如文件删除）； 

坏数据（如文件的corruption）； 

坏输出（如计算出不正确的结果）； 

可用性问题（如难于积累用户界面方面的经验）； 

被动安全问题（如非授权读文件）； 

主动安全问题（如非授权更改文件）； 

修饰（如屏幕上的拼写错）。 

4、 可进行分类：按使用和操作的概况； 

5、 分析研究后，解决事件问题。原因可能有： 

产品设计错误：设计不符合要求； 

用户错误：用户操作错误； 

硬件问题； 

未明； 

等。

6、 对用户及厂商的成本核算： 

用户方面： 

事件的严重性分类：如：灾难性；巨大损失；关键性；主要的；微小的；可忽略的。

资源损失：如时间损失，无法使用系统（或应用，或某终端服务）的时间；恢复时间等。 

厂商方面：

处理及报告事件的费用。

7、用上述同样方法可处理可靠性等同类属性。



4、故障的度量：可以有以下的记录和处理：

1、 标识配置控制版本号，子系统，模块，文档，中间产品；

2、 对某些无影响的故障，应在源程序中注明；

3、 标明故障查明方法：如通过审查或测试； 

4、 标明故障分类：如丢失/错误/超出；

5、 标明故障原因：例如： 

交流问题：如信息传递不好，概念不理解等；

事务问题：如打印或编辑错误等；

原因还可细分。 



5．更改的度量：可以有以下的记录和处理： 

1、 标识更改的模块和子系统，那一部分要为此而更改；

2、 何时"更改"首次放入发布版本；

3、 更改理由：改正/适应/完善维护； 

4、 实施更改（如作回归测试等）的费用。



1.2 工作量、时间和费用度量

1。执行时间 

系统的使用必须根据至少一种定义的度量（比例级）来加以记录。例如：执行时间或一个与之等价的度量。可靠性和可使用性估计相对于不同的时间度量可能需要不同的故障模式来进行估计。建议对不同类型的系统使用以下的定义：

实际执行时间：系统在一段时间持续使用，例如：不间断的工业控制执行的时间。

转换时间：是指软件使用时其安装操作的整个时间。例如：安装软件或操作系统的时间等。

正常化转换时间：一根软件能运行于不同的硬件环境，使用一个修正因子来使软件不同的安装方式具有不同的处理能力。

程序已装入时间：一个应用程序尽管被暂时中断了，但它在装入后的整个时间里一直是活动的。 

处理器时间：处理器有一个时钟，从而它可以记录软件消耗的处理时间。

对话时间：当人介入处理问题时，其占用终端的时间量。

消息数：交互式系统处理的数据包的事务的次数。 

机器指令数：执行的机器指令的数目（有一个硬件计数器）。 

源指令数：执行的源指令的数目（有一个跟踪机制）。

命令数：软件以不规则和不可预料的时间间隔被调用以执行某一指定的功能。例如：紧急关闭等。 

2。项目时间 

度量"实际时间"（也被称之为时钟时间或日历时间）的目的有两个：即(1).度量开发的进度从而可以管理它；(2).记录事件和产生错误的时间。

为了对开发进行管理，一天的精确的记录是必要的。记录事件所需的精确性依赖于系统和事件。例如：对商业软件系统的事件来说，精确到分钟通常就足够了；但对嵌入和实时系统来说，可能需要精确到百万分之一秒；对这么高的精度来说，自动记录是必要的。

安装的系统的分布在地理上是广泛分布的，因此，在事件的报告发给系统的支持维护机构的时候，事件发生的当地时间要调整为某一参考时区（如GMT）的时间。实际时间是以间隔的时间来度量的，因此，通过选择不同的来源可以获得与之等价的度量。通常的习惯是使用00.00小时或 0.A.D.表示。但是也习惯从项目开始的时间开始度量。

3。工作量

工作量用完成一给定任务所耗费的总的职员－小时、天和星期等（比例级）来度量。这通常是手工记录的，不可能要求很高的精确率，尤其是职员把他们的时间分花到很多不同的活动上了。除非有系统偏差，否则不精确性将平均地分布在整个大任务（例如完成开发的一个阶段）中。但要注意精确度。

4。费用

通常，费用是用货币来度量（比例级）的。而且，当我们关心的是开发和维护的费用的时候，费用是由工作量支出、加上间接费用和管理费用三部分组成的。工作量本身是不足以度量费用的。处理事件报告一类的文秘性的劳动的报酬要比那些高技术的雇员的低，因为这些高技术雇员能分析、诊断和修改错误。

对某一特定的事件的工作量（如在某一事件后恢复整个系统）将被记录下来，须特别小心以保证数据准确。

要注意经销商的费用与用户的费用是不同的。

5．费用估计方法：

通常包括人员工作量，跨越时间及雇员的水平的估计。在美国，在费用估计时，一般假定软件费用主要是雇员的费用。通常以概率估计其上下限。存在四种常用估计方法：

专家意见（猜测）；仿效（与过去项目相比较）：初始估计+调整；分解：从最小单元的估计出发；按复杂性（难度）的最小单元的估计后，求总和。利用估计公式：如COCOMO模型；Rayleigh曲线模型（适用于大于70000行的系统）；功能点方法等； 

这些方法的问题不少，如：

估计不精确：实际情况与估计往往相差悬殊。不同模型公式结果不一样；

过分复杂；

需要产品规模的估计，但事先无法从需求中获得，因此结果是极不精确的；

常常无法用单一模型来解决问题。

对以上几个方面的可能补救的办法是：采用本地的经验数据，统计后，得到模型和计算方法公式；再考虑一些调整的偏差；要有独立的估计小组，减少偏见；改进模型的输入数据。使其尽可能精确；反复估计，以求减少偶然性；使用不同的模型公式度量费用，比较结果。特别要提供反馈，以改进估计者的技能及估计模型的准确率。

2、进行过程预测：

这是非常困难的任务。暂不讨论。



二、产品内部属性度量 

在前面我们内部属性的定义。他们是仅依赖于产品自身的软件产品（包括文档）的属性。在这里 我们将详细论述重要的内部属性及度量他们的方法。

1．内部属性的重要性

内部属性是极其重要的，他们是提高软件产品的关键。这正是当今软件工程方法所关心的；内部属性可用于质量控制和保证；他们是度量复杂性的基本组成部分；内部属性可在软件项目的早期度量；而且他们对估计软件方法效率来说是关键的。

2．软件工程方法提供结构

大多数的软件工程方法是在30年内提出和发展起来的，他们为生产软件产品提供了准则、工具和启发。尤其是这些方法表明了如何提供结构。这种结构在开发过程（即在某个阶段那个产品需要生产出来）和产品自身都必须遵循某种结构原则。

在后一种情况下，使用软件工程方法来引导构造具有某种结构特性的产品。特别是，这些产品由某种层次的内部属性来特征化，这些内部属性包括模块化、再使用、耦合性、集聚性、冗余性、D－结构和层次性等。

而且，在软件工程师专家中广泛有这种看法，那就是内部结构属性将保证：

1。软件用户期望的外部属性，例如：可靠性、可维护性和可用性等。

2。管理者期望的过程外部属性，如生产率和费用－效率等。

结论是好的内部属性（结构）将导致好的外部质量。但是要注意，实际上，可能发生的情况是：从开始到结束都用了全部最好的软件工程实践，但得不到好的结局。因为前者往往只提供如设计文档化的结构，而不是针对保证满足用户要求。因此，还需要尽早度量，来预见最终系统的费用、工作量、规模、复杂性和质量。评价人员的行为--生产率，评价产品和方法的质量。 

3、对质量控制和保证进行度量

当谈到提高软件产品问题上，仅仅度量产品和过程的外部属性是不够的。通过度量我们会发现维护费用太高或是软件不可靠。但是，这并没有告诉我们在进行新产品的开发时如何进行改进。一种方法是识别出导致这种不好状态的内部属性；确信在今后的开发中对这些内部属性加以合理的监视和控制。

在软件的整个生命周期中，可以把内部属性用于质量控制和保证中。例如：在设计阶段，从内部属性的角度我们可以识别出软件模块的大致框架，从中我们可以看到他们是易于故障的或是难以维护和测试。

4、 度量复杂性需要内部属性 

在已经知道了度量和控制软件产品的复杂性的需要。复杂性这个术语通常用于考虑所有的内部属性的整体性。当人们谈到度量和控制复杂性是必要的时候，实际是说是需要度量和控制产品的一些内部（结构〕属性。他们并不是试图把那些他们认为对复杂性有贡献的特定的属性接合起来。他们感到他们所有的认识和对复杂性的结构的理解应该归结为一个简单的数字。而这个数字应能反映出与一个复杂的系统相关的所有属性。如维护性差或可靠性等。 

我们将考虑一些起着一定作用的重要的内部属性并想办法来度量他们。近20多年的软件工程方面的研究告诉我们：如果我们能再向前迈进一步而学会很好地控制他们的话，我们将在系统的质量方面获得很大的提高和改进。

对某一属性的精确的度量应优先于任何试图定义一个通用的复杂性度量，甚至使对后者的需要成为多余的。

5、 度量内部属性以评价方法

几乎每一天都有新的软件工程方法被提出来用以帮助解决软件危机问题。甚至有新的软件标准被引入以介绍其中的一些方法。其目的是不可避免地得到更好质量的系统。不幸的是，大多数的这些方法并没有得到客观公正的评价。如果我们能正确地评价他们，然后比较相似但不同的方法的效率了，也就可以决定采用一种新方法是否会效率－费用比更合理。

从增强某几个重要的内部属性的角度来说，软件工程方法提供了改进产品结构的机制。如果我们想合理地评价方法，我们需要度量：

1。方法实际上应用的程度。

2。使用这种方法的效果。对这我们主要是看：

a.产品的质量类型的外部属性中哪些是使用它的结果；

b.与使用它有关的过程属性（象费用、工作量和时间等）；

c.需要使用它的资源属性，如开发小组的生产率或系统的费用等。

其中第一条往往被忽略了，但没有它就不可能得到有意义的结果。

6．主要属性的度量：

1、 规模：通常是评估费用、生产率、日工作量的关键因素。

长度：通常用产品的长度--程序中的代码行（非注释或空白行）行数、注释密度、字符数、字节数来代表。由于它不反映冗余和复杂性，因此也不能真正反映生产率与费用。为此有人对不同难度的代码行加权：提出"扩展比"概念以预测规模等方法来进行改进。不管怎样，长度仅仅是一种度量指标而已，不能想象只用长度度量来完全解决费用估计问题。

功能：Albrecht 的功能点方法；DeMarco方法等。

所处理问题的复杂性：问题的复杂性涉及解决问题所需的资源总量。如计算机时间复杂性和空间复杂性，NP问题等。

2、 控制流结构：可以用程序流程图（有向图）表示结构。相关的度量有：

层次性度量--最大嵌套层数；图的节点数、边数、基本图中的判断数、某种控制结构的出现次数；

递归性的度量；结构的复杂性，如McCabe的公式等；测试覆盖率与路径度量，全部路径、遍历每个循环路径测试、简单路径测试、结构化测试、分支测试、语句测试等。

3、 模块化与信息流属性：涉及模块内及模块间关系的属性。

模块信息流：涉及调用图、数据依赖关系图；

全局模块性：M1=模块数/过程数     M2=模块数/变量数

形态：规模（节点数、边数）、深度（根到叶子节点）、宽度（某层的最大节点数）、边数/节点数等。

树（非纯的程度）。

复用：产品公共复用比例（P）=长度（P1）+长度（P2）和私有的复用。这里P1是新的产生的部分，P2是有外部构造的部分，P=P1+P2。

耦合。

聚合。

信息流：扇入/扇出，测试覆盖度量。

4、 数据结构：D/P=数据库规模（字节或字符）/程序规模（交付的源指令）

5、 算法效率与复杂性：算法理论中涉及的算法度量和复杂性度量。 

6、 完整的复杂性度量。 



三、度量产品的外部属性 

软件工程的一条主要的目标是提高软件产品的质量。但是，质量，如同美一样，存在与观察者的眼睛之中。对软件质量的意思尚存在哲学上的争议。在这里，我们所关心的是软件产品的用户感兴趣的属性以及我们怎样才能度量在我们的软件产品中该属性被表示的程度。一旦我们能够做到这些，我们将能够以可度量的形式来指定产品的特定的属性。

在前面我们定义了产品的外部属性即依赖与实体和我们考虑的产品的属性。如果产品是软件代码的话，它的可靠性便是有关外部属性：依赖于机器环境和用户；在前面，我们讨论产品的内部属性，也影响外部属性。现在，我们将集中讨论几个重要的外部属性及他们的度量方法。 

1、 度量软件质量和软件质量度量的模型

在前面的章节中，通过把它分解为一些质量属性的组合， 我们描述了一个高层次的模型化软件质量的方法。特殊的质量模型有McCall和Boehm的模型。这种方法主要把注意力集中在用户对最终产品（通常是可执行代码）的看法上，而试图从这个观点来识别质量的一些关键属性。这些关键属性通常被称之为质量因子。他们和通常的高层次的如可靠性、可用性、和可维护性等外部属性的性质一样，同时也包含我们可能认为是内部属性的属性如可测试性和效率等。

一种假设认为：这些质量因素，和质量这个属性自身一样，层次太高以至于没什么意义或是不能直接度量。他们必须被进一步分解为更低层次的属性，通常叫做质量标准。例如：在McCall的模型中，可靠性这个因素是由一致性、准确性、容错性和简单性这几个质量标准组成的。

在很多情况下，质量标准是内部属性如结构化和模块化等。开发人员认为内部属性将对外部属性产生影响。当质量标准与一组低层次的可直接度量的属性（包括产品和过程的）相关的时候，就需要对质量标准作更进一层的分解。这时我们便称之为质量度量。

一个软件工程师或是软件使用者可使用分解来以两种不同的方式监视软件质量：

A.固定模型方式：即监视所需的所有的重要的质量因素都是所选模型（McCall）的一个子集。为了控制和度量质量因素，他接受了所提出的因素、标准和度量之间的关系。

B.定义自己的质量模型的方式：这种方式接受了分解的原则。但是，对一个给定的产品，工程师和用户就软件质量的什么属性是重要的的观点是一致的。于是，他们便在一起决定了分解过程（在一个已有模型的指导下）。在这个分解过程中，他们就一些低层次的属性（标准）的度量达成了一致。在这种方式下，可对感兴趣的质量属性有目的地加以度量从而看一看他们是否满足特定的度量目标。 



四、资源度量 

1、 生产率度量 

Fred Brooks曾说过这样一句话：如果你把更多的人投入到一个最新的项目中时，你将会发现项目将推迟。有过大项目开发经验的人都同意这个观点。事实上，在这句话中，有很多与生产率有关的直觉性的概念。如果我们使用工业标准的度量方法来度量程序员的生产率（LOC每人每月〕的话，Brooks的话将得到证明。在这一节中，我们在度量生产率的时候将不仅考虑输出的大小（在传统的生产中只考虑了这一点）而更重要的是考虑输出的质量和功能性。 

1.1生产率的含义 

通常生产率是用输出的大小（LOC）和产生该输出付出的工作量（人－天数）的比值来间接度量的。其公式如下：

          LOC / 人－月数               

在传统的工业生产中，"复制"这个产品是一个产品的主要生命周期之所在。假设生产某一类型的汽车，设计该汽车的阶段与一个复杂的软件系统的设计阶段是类似的；建造一个汽车的工作原型也可以看作是与软件系统的编码阶段相类似；但是，生产100000辆汽车仍然是一个主要的生产问题，即使某个人对工作原型都很满意。

而对一个复杂的软件系统来说，相比之下，所需作的复制工作只是制作该软件系统的支持版本而已。而且这个费用同开发和构造该原始系统的费用相比是很少的；正是在这个意义上把软件"生产"和传统的工业"生产"区分开来了。因此，在传统的生产中，生产率通常是用每人每月生产的产品的数目来度量的；但对软件产品就不一样了。这正如同诗歌创作。我们不能用统计得到的诗人创作的诗的行数来度量诗人的生产率。我们所要做的是找出一个度量输出的标准，这个标准和大小相比，它与输出的价值和质量有更直接的关系。我们也应认识到输入也不能简单的用时间来度量；在软件中，资源也应当被考虑进去。