第 7 章软件过程和项目度量

第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)步，能够得到一个简单的缺陷分布情况。由上述的第(1)步和第(2)步，能够得到一个简单的缺陷分布情况。缺陷分布情况

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

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

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

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

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

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

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

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

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

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

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

反对者们则认为LOC测量依赖于程序设计语言；它们对设计得很好但较小的程序会产生不利的评判；它们不适用于非过程语言；而且它们在估算时需要一些可能难以得到的信息（如，早在分析和设计完成之前，计划者就必须估算要产生的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的方法来使用它们以规范化软件生产率、质量及其它属性的测量：一旦计算出功能点，则以类似LOC的方法来使用它们以规范化软件生产率、质量及其它属性的测量： • 每个功能点（FP）的错误数 • 每个功能点（FP）的缺陷数 • 每个功能点（FP）的花费 • 每个功能点（FP）的文档页数 • 每人月完成的功能点（FP）数

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

在不同的程序设计语言中建造一个功能点所需的平均代码行数的一个粗略估算：在不同的程序设计语言中建造一个功能点所需的平均代码行数的一个粗略估算：

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

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

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

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

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

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

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

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

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

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

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

第 7 章 软件过程和项目度量