第7章 软件过程和项目度量 过程和项目领域中的度量 软件测量 软件质量度量 在软件工程过程中集成度量 小型组织的度量 建立软件度量计划

在软件项目管理中，主要关心生产率和质量的度量。 为了计划及估算待开发软件的生产率及质量，可以基于类似项目的历史数据进行估算： 在过去的项目中软件开发生产率是怎样的？ 生产的软件的质量是怎样的？ 如何从过去的生产率及质量数据推断出现在的？ 过去的信息如何帮助我们更加准确地计划和估算？

测度、测量和度量: 测度(measure)一词可用作名词，也可用作动词。在软件工程中，measure为产品或过程的某些属性的程度、数量、维数、容量或大小提供量化的指示。 测量(measurement)是确定测度的动作。 度量(metrics) 是一个系统、构件或过程具有给定属性的量化测量程度。

当收集了一个数据点（例如：在一个软件构件中发现的错误数），就已建立了一个测度。 收集一个或多个数据点（例如：一些构件评审、调查单元测试以收集每个单元测试错误数的测度），由此产生测量。 软件的度量以某种方式（例如：每次评审发现错误的平均数，或每个单元测试所发现错误的平均数）与单个测度相关。

测量的理由 测量的4个理由：刻画、评价、预测、改进。 刻画:我们通过刻画而获得对过程、产品、资源和环境的了解，并建立和未来评估比较的基线。 评价:通过评价来确定相对于计划的状况。 预测：通过取得对过程和产品间关系的理解，并建造这些关系的模型来进行预测 。 改进：通过识别障碍、根本原因、低效率和其它改善产品质量和过程性能的机会来进行改进。

过程和项目领域中的度量 过程度量的收集跨越所有的项目，并经历相当长的时间。目的是提供能够引导长期的软件过程改进的一组过程指标。产品度量使得软件项目管理者能够： （1）评估正在进行的项目的状态； （2）跟踪潜在的风险； （3）在问题造成不良影响之前发现它们； （4）调整工作流程或任务； （5）评估项目组控制软件工程工作产品的质量的能力。

过程度量和软件过程改进 改进过程的唯一合理的方法是测量过程的特定属性，基于这些属性开发一组有意义的度量，而后使用这组度量来提供引导改进策略的指标。 但是，在我们讨论软件度量及它们对软件过程改进的影响之前，必须注意到过程仅是众多“改进软件质量和组织性能的控制因素”中的一种。

对软件质量和组织性能有重大影响的因素： 人员的技能和动因被认为是对质量和性能最有影响的因素。 产品的复杂性对质量和小组性能产生相当大的影响。 过程中采用的技术（如软件工程方法）也有影响。 软件质量和组织有效性的决定因素

可以基于从过程中获得的以下结果，导出一组度量，间接地测量一个软件过程的功效。 在软件发布之前发现的错误数的测量； 交付给最终用户并由最终用户报告的缺陷的测量； 交付的工作产品的测量； 花费的工作量的测量； 花费的时间的测量； 与进度计划是否一致的测量等。 还通过测量特定软件工程任务的特征来导出过程度量。例如，测量保护性活动及一般软件工程活动所花费的工作量和时间。

不同类型的过程数据可以分为“私有的和公用的”的使用。因为个体软件工程师可能对在其个体基础上收集的度量的使用比较敏感，这是很自然的，因此，这些数据对此人应该是私有的，并成为仅供此人参考的指标。 私有的度量数据的例子有：（按人的）缺陷率，（按模块的）缺陷率，和开发中发现的错误。

“私有过程数据”的思想与Humphrey所建议的个人软件过程（Personal Software Process）方法相一致。Humphrey认为软件过程改进能够、也应该开始于个人级。私有过程数据是软件工程师个人改进其工作的重要驱动力。 个人软件过程（PSP）是一个过程描述、测度和方法的结构化集合，能够帮助工程师改善其个人性能。 一个基本的PSP原则是：每个人都是不同的，对于某个工程师有效的方法不一定适合另一个。这样，PSP帮助工程师测量和跟踪他们自己的工作，使得他们能够找到最适合自己的方法。

某些过程度量对软件项目组是私有的，但对所有小组成员是公用的。 例如，主要软件功能（由多个开发人员完成）的缺陷报告、正式技术复审中发现的错误、以及每个模块和函数的代码行或功能点。这些数据可由小组进行复查以找出能够改善小组性能的指标。

公用度量一般吸取了原本是个人的或小组的私有信息。项目级的缺陷率、工作量、时间、及相关的数据被收集和评估，以找出能够改善组织的过程性能的指标。 软件过程度量能够对一个组织提高其总体的过程成熟度提供很大的帮助。不过，它们也可能被误用，产生比它们解决的问题更多的问题。

统计软件过程改进（statistical software process improvement，SSPI）：SSPI使用软件故障分析方法，来收集软件应用、系统或产品的开发及使用中所遇到的所有错误及缺陷的信息。

故障分析采用如下方式： (1) 根据来源分类所有的错误和缺陷（如，规格说明中的错误，逻辑错误，与标准不符的错误等）。 (2) 记录修改每个错误和缺陷的成本。 (3) 统计每一类错误和缺陷的数目，并按降序排列。 (4) 计算每一类错误和缺陷的总成本。 (5) 分析结果数据，找出造成组织最高成本的错误和缺陷类型。 (6) 制定修改过程的计划，目的是消除成本最高的错误和缺陷类型（或降低其出现的频率）。

由上述的第(1)步和第(2)步，能够得到一个简单的缺陷分布情况。

项目度量 软件过程度量主要用于战略的目的。 软件项目度量则是战术的。即，项目度量及从其中导出的指标是由项目管理者和软件项目组使用，以改进项目工作流程和技术活动。 从过去的项目中收集的度量可用来作为估算现在软件项目的工作量及时间的基础。随着项目的进展，所花费的工作量及时间的测量可以和预估算值（及项目进度）进行比较。 项目管理者使用这些数据来监督和控制项目的进展。

生产率度量：根据文档的页数、复审的时间、功能点、及交付的源代码行数来测量生产率。 除此之外，每一个软件工程任务中所发现的错误也会加以跟踪。 软件在从需求规格说明到设计的演化中，需要收集技术度量以评估设计质量，并提供若干指标，这些指标会影响代码生成及模块测试和集成测试所采用的方法。

项目度量的目的是双重的： 首先，这些度量能够指导进行一些必要的调整以避免延迟，并减少潜在问题及风险，从而使得开发时间减到最少。 其次，项目度量可在项目进行的基础上评估产品质量，并且可在必要时修改技术途径以改进质量。

* 输入――完成工作所需的资源（如人员，环境）的测量。 软件项目度量建议每个项目都应该测量：  * 输入――完成工作所需的资源（如人员，环境）的测量。 * 输出――软件工程过程中产生的交付物或工作产品的测量。 * 结果――表明交付物的效力的测量。 这个模型既可以用于过程也可以用于项目。在项目范畴中，该模型能够在每个框架活动发生时递归地使用。这样，一个活动的输出是下一个活动的输入。结果度量能够提供关于工作产品的有用指标。

软件测量 测量在现实世界中可分为两类：直接的测量和间接的测量。 软件测量也可以这样分类。软件工程过程的直接测量包括花费的成本和工作量。 产品的直接测量包括产生的代码行（lines of code，LOC）、执行速度、内存大小、及某段时间内报告的缺陷。 产品的间接测量包括功能、质量、复杂性、有效性、可靠性、可维护性等。

构造软件所需的成本和工作量、生产的代码行数、以及其它直接测量是相对容易收集到的，然而，软件的质量和功能或其功效或可维护性是更难于评估的，只能间接测量。

软件度量划分为过程、项目和产品度量。 对个人私有的产品度量常常被结合起来以形成对软件项目组公用的项目度量。项目度量又被联合起来产生对整个软件组织公用的过程度量。

面向规模的度量 面向规模的软件度量是通过规范化质量或生产率的测量而得到的，这些测量是基于所生产的软件的“规模”。

为了产生可以与其它项目中同类度量相比较的度量，我们选择代码行作为规范化值。根据表中所包含的基本数据，能够为每个项目产生一组简单的面向规模度量： * 每千行代码（KLOC）的错误数 * 每千行代码（KLOC）的缺陷数 * 每行代码（LOC）的花费 * 每千行代码（KLOC）的文档页数

除此之外，还能够计算出其它有意义的度量：   * 每人月的错误数 * 每人月的代码行（LOC） * 每页文档的花费

面向规模的度量并不被普遍认为是测量软件开发过程的最好方式。大多数的争议都是围绕着使用代码行（LOC）作为关键的测量是否合适。 LOC测量的支持者们认为LOC是所有软件开发项目的“生成品”，并且很容易进行计算；许多现有的软件估算模型使用LOC或KLOC作为关键的输入，并且关于LOC已经有大量的文献和数据。

反对者们则认为LOC测量依赖于程序设计语言；它们对设计得很好但较小的程序会产生不利的评判；它们不适用于非过程语言；而且它们在估算时需要一些可能难以得到的信息（如，早在分析和设计完成之前，计划者就必须估算要产生的LOC）。  面向规模的度量是被广泛接受的，但是，关于其有效性和可应用性的争论一直在进行。

面向功能的度量 面向功能的软件度量使用软件所提供的功能的测量作为规范化值。因为“功能”不能直接测量，所以必须通过利用其它直接的测量来间接地导出。面向功能度量是由Albrecht首先提出来的，他建议一种称为功能点的测量。 功能点是基于软件信息域的特性及软件复杂性的评估而导出的。

功能点是通过完成下面的表而计算出来的。其中确定了五个信息域特征，并在表中合适的位置提供计算。 计算功能点度量

信息域值按下列方式定义： 用户输入数：计算每个用户输入，它们向软件提供不同的面向应用的数据。输入应该与查询区分开来，分别计算。 用户输出数：计算每个用户输出，它们向用户提供面向应用的信息。这里，输出是指报表、屏幕、出错信息，等等。一个报表中的单个数据项不单独计算。 用户查询数：一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应。每一个不同的查询都要计算。

文件数：计算每个逻辑的主文件（即，数据的一个逻辑组合，它可能是某个大型数据库的一部分或是一个独立的文件）。 外部接口数：计算所有机器可读的接口（如，磁带或磁盘上的数据文件），利用这些接口可以将信息从一个系统传送到另一个系统。 KEYPOINT：功能点从信息域的直接测量导出。

一旦已经收集到上述数据，就将每个计算与一个复杂度值（加权因子）关联上。采用功能点方法的组织建立一个标准，以确定某个特定的条目是简单的、平均的还是复杂的。

我们采用下面的方式计算功能点： FP=总计数值×(0.65＋0.01×(∑Fi) 其中“总计数值”是从上图得到的所有条目的总和。

Fi（ i=1 到 14）是基于对下列问题的回答而得到的“复杂度调整值”：   1. 系统是否需要可靠的备份和恢复？ 2. 是否需要数据通信？ 3. 是否有分布处理的功能？ 4. 是否性能成为关键？ 5. 系统是否运行在既存的高度实用化的操作环境中？ 6. 系统是否需要联机数据项？ 7. 联机数据项是否需要建立多重窗口显示和操作，以处理输入处理。

8. 主文件是否联机更新？ 9. 输入、输出、文件、查询是否复杂？ 10. 内部处理过程是否复杂？ 11. 程序代码是否可复用？ 12. 设计中是否包括了转移和安装？ 13. 系统是否设计成可以重复安装在不同机构中？ 14. 系统是否设计成易修改和易使用？

一旦计算出功能点，则以类似LOC的方法来使用它们以规范化软件生产率、质量及其它属性的测量： 每个功能点（FP）的错误数 每个功能点（FP）的缺陷数 每个功能点（FP）的花费 每个功能点（FP）的文档页数 每人月完成的功能点（FP）数

调和不同的度量方法 代码行和功能点度量之间的关系依赖于实现软件所采用的程序设计语言及设计的质量。很多研究试图将FP和LOC联系起来。引用Albrecht和Gaffney的话：  　 应用（程序）所提供的功能数能够从将使用的或提供的数据的主要组成部分的详细记录中估算出来。更进一步，功能的估算应该与要开发的LOC数及开发所需的工作量关联起来。

在不同的程序设计语言中建造一个功能点所需的平均代码行数的一个粗略估算： 汇编语言 C Cobol Fortran Pascal C＋＋ Ada95 Visual Basic Smalltalk Powerbuilder（代码生成器） SQL LOC/FP（平均值） 320 128 106 90 64 53 32 22 16 12

LOC和FP测量常常用于导出生产率度量。 是否应该将某个组的LOC/人月（或FP/人月）与另一个组的类似数据进行比较？管理者是否应该根据这些度量来评价个人的表现？ “No”。这个回答的理由在于很多因素都会影响生产率。 基于功能点和LOC度量已被发现是软件开发工作量和成本的相对精确的判定。

软件质量度量 软件工程的最高目标就是产生高质量的系统、应用、或产品。 为了达到这个目标，软件工程师必须在成熟的软件过程背景下应用有效的方法及现代化的工具。 一个优秀的软件工程师（和优秀的软件工程管理者）必须测量是否能够实现高质量。

一个系统、应用或产品的质量依赖于描述问题的需求、建模解决方案的设计、产生可执行程序的编码、以及运行软件以发现错误的测试。 一个优秀的软件工程师使用度量来评估软件开发过程中产生的分析及设计模型、源代码和测试用例的质量。为了实现这种实时的质量评估，工程师们必须采用技术测量客观地评估质量，而不能采用主观的方法。

在项目进展过程中，项目管理者也必须评估质量。个体软件工程师所收集的私有度量可用于提供项目级的信息。 虽然可以收集到很多质量测量，在项目级最主要的还是测量错误和缺陷。从这些测量中导出的度量能够提供一个关于个人及小组的软件质量保证及控制活动的效率的指标。

诸如每个功能点的工作产品（如，需求或设计）错误、复审中每小时所发现的错误及测试中每小时所发现的错误等度量，使我们能够洞悉度量所涉及的那些活动的功效。错误数据也能够用于计算每个过程框架活动的缺陷排除效率（DRE）。

影响质量的因素 25年前，McCall和Cavano定义了一组质量因素，这是走向软件质量的度量的第一步。这些因素从三个不同的视点来评估软件: (1) 产品的操作（使用）; (2) 产品的修改（改变）; (3) 产品的变迁（修改它使之能够用于另一个环境，即“移植” ）。

这些质量因素之间的关系（称之为“框架”）以及软件工程过程的其它一些方面： 首先，框架为项目管理者提供了一个机制，以标识哪些质量因素是重要的。除了软件的功能正确性和性能之外，这些质量因素也都是软件的属性，在生命周期中有重要意义。一些因素，诸如可维护性及可移植性，近年来已显示出对整个生命周期的成本有重要影响... 其次，该框架提供了定量评估的方法，以评价相对于已建立的质量目标而言，开发进展得如何...

再次，该框架在整个开发工作中，提供了更多的 QA（质量保证）人员之间的交互... 最后，...，质量保证人员能够利用低质量的指标去帮助确定将来要增强的更好的标准。

自从McCall和Cavano在1978年完成他们的最初工作之后，几乎关于计算的每一个方面都发生了根本的改变，但提供软件质量指标的属性仍然没有改变。 这意味着什么？如果一个软件组织采用一组质量因素作为评估软件质量的一个“检查表”，那么就有可能今天建造的软件一直到二十一世纪的头几十年仍展现出良好的质量。

即使计算的体系结构经历了根本的改变（事实上也肯定会），在操作、修改和变迁上表现出高质量的软件仍会继续给用户提供很好的服务。 KEYPOINT：令人惊奇的是，在1970年代定义软件质量的因素和继续用于定义本世纪头10年的软件质量的因素是相同的。

测量质量 虽然有很多软件质量的测量，但是，正确性、可维护性、完整性、及可用性为项目组提供了有用的指标。Gilb给出了它们的定义及测量。 正确性：一个程序必须能够正确操作，否则对于用户就没有价值了。正确性是软件完成所需的功能的程度。关于正确性的最常用的测量是每千行（KLOC）的缺陷数，这里缺陷定义为验证出的与需求不符的地方。当考虑某软件产品的整体质量时，缺陷是在程序针对一般的使用而发布后由程序的某用户报告的那些问题。出于质量评估的目的，缺陷是按某标准时间段计数的，比如1年。

可维护性：软件维护所占的工作量比任何其它软件工程活动都大。可维护性是指遇到错误时程序能被修改的容易程度；环境发生变化时程序能够适应的容易程度，用户希望改变需求时程序能被增强的容易程度。可维护性无法直接测量；因此，我们必须采用间接测量。一个简单的面向时间的度量是平均修改时间（mean-time-to-change，MTTC），即分析改变的需求，设计合适的修改方案，实现修改，测试，并将修改后的结果发布给用户所花的时间。

完整性：在黑客及防火墙的时代，软件完整性已变得日益重要。这个属性测量系统在安全方面的抗攻击（包括偶然的和蓄意的）能力。攻击可以针对软件的三个主要成分：程序、数据及文档。 为了测量完整性，必须定义两个附加的属性：威胁和安全性。威胁是某个特定类型的攻击在给定时间内发生的可能性（能够根据经验估算或推断出来）。安全性是某个特定类型的攻击将被击退的可能性（也能够根据经验估算或推断出来）

一个系统的完整性可以定义为： 完整性 =  [ 1－ （威胁×（1－安全性） ）] 这里威胁及安全性针对每种类型的攻击求和。 可用性：在对软件产品的讨论中，“用户友好性”这个词已经是普遍存在的。如果一个程序不是“用户友好的”，那么它是注定会失败的，即使它所完成的功能很有价值。

可用性试图量化“用户友好性”，并根据四个特性来测量： (1) 学会一个系统所需的体力的和/或智力的技能； (2) 在系统的使用上达到中等效率所需的时间； (3) 当系统由某个具有中等效率的人使用时，测量到的生产率的净增长(与被该系统替代的老系统相比)； (4) 用户对系统的态度的一个主观评估（有时可以通过问卷调查获得）。 上述的四个因素仅仅是被建议作为软件质量测量的众多因素中的一个样板。

缺陷排除效率 缺陷排除效率（DRE）在项目级和过程级都能提供有益的质量度量。本质上，DRE是对质量保证及控制活动的过滤能力的一个测量，这些活动贯穿于所有过程框架活动。 当把一个项目作为一个整体来考虑时，DRE按如下方式定义： DRE = E/（E＋D） 其中E= 软件交付给最终用户之前所发现的错误数 D= 软件交付之后所发现的缺陷数

最理想的DRE值是1，即，软件中没有发现缺陷。现实中，D会大于0，但随着E值的增加，DRE的值仍能接近1。事实上，随着E的增加，D的最终值可能会降低（错误在变成缺陷之前已经被过滤了）。 如果DRE作为一个度量，提供关于质量控制和保证活动的过滤能力的指标，则DRE鼓励软件项目组采用先进技术，以在交付之前发现尽可能多的错误。

DRE也能够用于在项目中评估一个小组在错误传递到下一个框架活动或软件工程任务之前发现这些错误的能力。 DREi = Ei /（ Ei＋Ei+1）

其中E i = 在软件工程活动i中所发现的错误数 E i+1= 在软件工程活动i＋1中所发现的错误数，这些错误起源于软件工程活动i中未能发现的错误。 一个软件项目组（或单个软件工程师）的质量目标是使DREi接近1，即，错误应该在传递到下一个活动之前被过滤掉。

在软件过程中集成度量 大多数软件开发者仍然没有进行测量，这是文化的问题。试图收集过去从来没有人收集的测量常常会遇到阻力。困扰的项目管理者问“为什么我们要做这个？”。工作过度的开发者抱怨“我看不出这样做有什么用”。 考虑某些支持软件度量的论点，并给出一种在软件工程组织内部启动度量收集计划的方法。

支持软件度量的论点 为什么测量软件工程过程及其产生的产品（软件）如此重要？ 如果我们不进行测量，就没法确定我们是否在改进。

软件项目工作的日常繁忙使得几乎没有时间去进行战略性的思考。 软件项目管理者更关心现实的问题：进行有意义的项目估算；产生高质量的系统；按时交付产品等。 通过使用测量来建立项目基线，将使得这些问题更加容易管理。 我们已经知道基线是估算的基础，此外，质量度量的收集使得一个组织能够“调整”其软件工程过程，以排除引发对软件开发有最大影响的缺陷的“致命”原因。

在项目级和技术级，软件度量能够提供立即可见的好处。软件设计完成后，大多数开发者都急于知道以下问题的答案： * 哪些用户需求最有可能发生改变？ * 本系统中哪些部分最易于出错？ * 对于每一个模块需要设计多少测试？ * 当测试开始时，我们能够预测将有多少（特定类型的）错误吗？

建立基线 通过建立度量基线，可以在过程、项目以及产品（技术）级别上获得收益。

为了有效地帮助过程改善或成本和工作量估算，基线数据必须具有下述属性： (1) 数据必须是合理精确的――关于过去项目的“推测”应该避免； (2) 数据应该从尽可能多的项目中收集； (3) 测量必须一致，例如，代码行必须在所有收集数据的项目中被一致地解释； (4) 应用应该和将被估算的工作类似――用批处理信息系统工作的基线来估算实时嵌入式应用是没有意义的。

度量收集、计算和评估 软件度量的收集过程

建立软件度量计划 软件工程研究所（SEI）开发了一个全面的指导手册，以用于建立一个“目标驱动的”软件度量计划。该手册建议了如下的步骤： 1. 标识你的业务目标。 2. 标识你你想知道或学习什么。 3. 标识你的子目标。 4. 标识和你的子目标关联的实体和属性。

5. 定型你的测度目标。 6. 标识可量化的问题和相关的指标，你将用它们来帮助你达到你的测度目标。 7. 标识你将收集以构造帮助你回答上面问题的指标的数据元素。 8. 定义将被使用的测量，并使这些定义可操作。 9. 标识你将用于实现测量的动作。 10. 准备实现测量的计划。

因为软件支持业务功能、区分基于计算机的系统或产品、或者本身就是产品，因此，针对业务所定义的目标几乎总是可以被向下跟踪到在软件工程层次上的特定目标。例如，考虑一个公司，它生产高级的家庭安全系统，该系统含有实质性的软件内容。

通过在一个小组内共同工作，软件工程和业务管理者可以开发出一组优先的业务目标： 1. 用我们的产品改善我们的客户的满意度。 2. 使我们的产品易于使用。 3. 减少我们将新产品推向市场的时间。 4. 使我们产品的技术支持更容易。 5. 改善我们的整体收益率。

小结 测度使得管理者和开发者能够改善软件过程；辅助软件项目的计划、跟踪及控制；评估生产的产品（软件）的质量。对过程、项目及产品的特定属性的测量被用于计算软件度量。这些度量被分析以产生指导管理及技术动作的指标。 过程度量使得一个组织能够从战略级洞悉一个软件过程的功效。项目度量是战术的，使得项目管理者能够以实时的方式改进项目的工作流程及技术方法。

面向规模和面向功能的度量都普遍用于产业界。面向规模的度量使用代码行作为其它测量如人月或缺陷的规范化因子。功能点则是从信息域的测量及对问题复杂度的主观评估中导出的。 软件质量度量，如生产率度量，集中于过程、项目及产品上。通过建立和分析质量的度量基线，一个组织能够采取行动以纠正引起软件缺陷的那些软件过程区域。

度量是有意义的，仅仅当它们已经进行了统计有效性检查之后。控制图是达到该目标并同时检查度量结果的变化性和位置的一种简单方法。 度量导致文化的改变。如果打算开始进行度量，则数据收集、度量计算及度量评估是必须执行的三个步骤。通常，目标驱动的方法帮助一个组织关注于针对其业务的正确度量。 通过创建一个度量基线――一个包含过程及产品测度的数据库――软件工程师及管理者能够更好地了解他们所做的工作及所开发的产品。

Bye!