过程和项目度量概述

1、Software Project ManagementSoftware Project Management第2 讲 过程和项目度量过程领域和项目领域中的度量过程领域和项目领域中的度量主要内容软件测量软件测量软件质量度量软件质量度量有软件过程中集中度量有软件过程中集中度量小型组织的度量小型组织的度量制定软件度量大纲制定软件度量大纲 通过提供目标评估的机制，测量使我们能够对项目和过程有更通过提供目标评估的机制，测量使我们能够对项目和过程有更深入的了解。深入的了解。Lord Kelvin曾经说过：曾经说过： 当你能够测量你所说的事物，并能用数字表达它时，你就对它有了一定的了解；但当你不能测量它，也

2、不能用数字表达时，就说明你对它的了解还很贫乏，不令人满意：这可能是知识的开始，但你在思想上还远远没有进入科学的境地。测量可以应用于软件过程中，目的是持续地改进软件过程。测量可以应用于软件过程中，目的是持续地改进软件过程。测量也可以应用于整个软件项目中，辅助进行估算、质量控制、测量也可以应用于整个软件项目中，辅助进行估算、质量控制、生产率评估及项目控制。生产率评估及项目控制。最后，软件工程师还可以使用测量来帮助评估工作产品的质量，最后，软件工程师还可以使用测量来帮助评估工作产品的质量，并在项目进展过程中辅助进行战术决策。并在项目进展过程中辅助进行战术决策。n 进行测量的理由：进行测量的理由：刻画

3、刻画通过刻画而获得对过程、产品、资源和环境的了解，并建立同未来评估进行比较的基线；评价评价通过评价来确定相对于计划的状况；预测预测通过理解过程和产品间的关系，并构造这些关系的模型来进行预测；改进改进通过识别障碍、根本原因、低效率和其他改进产品质量和过程性能的机会来进行改进。n 测量是一个管理工具，如果能正确地使用，它将为项目管理者提测量是一个管理工具，如果能正确地使用，它将为项目管理者提供洞察力。因此，测量能够帮助项目管理者和软件团队制定出使供洞察力。因此，测量能够帮助项目管理者和软件团队制定出使项目成功的决策。项目成功的决策。6测度、度量和指标测度、度量和指标 虽然术语虽然术语“measur

4、e”(测量测量)、“measurement”(测度测度)和和“metrics”(度量度量)经常被互换经常被互换地使用，但注意到它们之间的细微差别是很重要的。因为地使用，但注意到它们之间的细微差别是很重要的。因为“measure”(测量测量)和和“Measurement”(测度测度)既可以作为名词也可以作为动词，所以它们的定义可能会既可以作为名词也可以作为动词，所以它们的定义可能会混淆。在软件工程领域中，混淆。在软件工程领域中， “measure”(测量测量)对一个产品过程的某个属性的范围、数量、维度、容量或大对一个产品过程的某个属性的范围、数量、维度、容量或大小提供了一个定量的指示小提供了一个

5、定量的指示。 “Measurement”(测度测度)则是确定一个测量的行为则是确定一个测量的行为。 IEEE的软件工程术语标准辞典的软件工程术语标准辞典(IEEE Standard Glossary of Software Engineering Terms)IEE93中定义中定义“metric”(度量度量)为为“对一个系统、构件或过程具有的某个给定属性的度的一个对一个系统、构件或过程具有的某个给定属性的度的一个定量测量定量测量”。7测度、度量和指标测度、度量和指标 当获取到单个的数据点当获取到单个的数据点(如在一个模块的复审中发现的错误数如在一个模块的复审中发现的错误数)时，就建立了一个测时

6、，就建立了一个测量。量。 测度的发生是收集一个或多个数据点的结果测度的发生是收集一个或多个数据点的结果(如调研若干个模块的复审，以收集每如调研若干个模块的复审，以收集每一次复审所发现的错误数的测量一次复审所发现的错误数的测量)。 软件度量在某种程度上与单个的测量相关软件度量在某种程度上与单个的测量相关(如每一次复审所发现的错误的平均数，如每一次复审所发现的错误的平均数，或复审中每人或复审中每人/小时所发现的错误的平均数小时所发现的错误的平均数)。 软件工程师收集测量结果并产生度量，这样就可以获得指标软件工程师收集测量结果并产生度量，这样就可以获得指标“indicator”。指标是。指标是一个度

7、量或度量的组合，它对软件过程、软件项目或产品本身提供了更深入的了一个度量或度量的组合，它对软件过程、软件项目或产品本身提供了更深入的了解解RAG95。指标所提供的更深入的理解，使得项目管理者或软件工程师能够调。指标所提供的更深入的理解，使得项目管理者或软件工程师能够调整开发过程、项目或产品，这样使事情进行得更顺利，能被更好地完成。整开发过程、项目或产品，这样使事情进行得更顺利，能被更好地完成。9过程领域和项目过程领域和项目领域中的度量领域中的度量 测量在工程界中是常事。我们测量动力消耗、重量、物理体积、温度、电压、信测量在工程界中是常事。我们测量动力消耗、重量、物理体积、温度、电压、信号号噪音

8、比噪音比 不胜枚举。不胜枚举。 过程度量过程度量的收集涉及所有的项目，而且要经历相当长的时间，目的是提供能够引导长期的软件过程改进的一组过程指标。 项目度量项目度量使得软件项目管理都能够：(1)评估正在进行的项目的状态；(2)跟踪潜在的风险；(3)在问题造成不良影响之前发现它们；(4)调整工作流程或任务；(5)评估项目团队控制软件工程工作产品质量的能力。 测量数据由项目团队收集，然后被转换成度量数据在项目期间使用。测量数据也测量数据由项目团队收集，然后被转换成度量数据在项目期间使用。测量数据也可传送给那些负责软件过程改进的人员。因此，很多相同的度量既可以用于过程可传送给那些负责软件过程改进的人

9、员。因此，很多相同的度量既可以用于过程领域，又可用于项目领域。领域，又可用于项目领域。10过程领域和项目过程领域和项目领域中的度量领域中的度量过程度量和软件过程改进 改进任何过程的唯一合理的方法是测量该过程的特定属性，再根据这些属性建立改进任何过程的唯一合理的方法是测量该过程的特定属性，再根据这些属性建立一组有意义的度量，然后使用这组度量提供的指标来导出过程改进策略。一组有意义的度量，然后使用这组度量提供的指标来导出过程改进策略。 但是，在我们讨论软件度量及它们对软件过程改进的影响之前，必须注意到过程但是，在我们讨论软件度量及它们对软件过程改进的影响之前，必须注意到过程仅是众多仅是众多“改进软

10、件质量和组织性能的控制因素改进软件质量和组织性能的控制因素”中的一种中的一种PAU94。图21 软件质量和组织有效性的决定因素 在图在图21中，过程位于三角形的中央，连接了三中，过程位于三角形的中央，连接了三个对软件质量和组织绩效有重大影响的因素。人个对软件质量和组织绩效有重大影响的因素。人员的技能和激励被认为是对质量和绩效最有影响员的技能和激励被认为是对质量和绩效最有影响的因素的因素BOE81。产品复杂性对质量和团队绩。产品复杂性对质量和团队绩效也有相当大的影响。过程中采用的技术效也有相当大的影响。过程中采用的技术(如软件如软件工程方法工程方法)也有影响。另外，过程三角形存在于环也有影响。另

11、外，过程三角形存在于环境条件的圆圈之内，环境条件包括：开发环境境条件的圆圈之内，环境条件包括：开发环境(如如CASE工具工具)、商业条件、商业条件(如交付期限，业务规则如交付期限，业务规则)、客户特性客户特性(如通信的容易程度如通信的容易程度)。11过程领域和项目过程领域和项目领域中的度量领域中的度量过程度量和软件过程改进n 我们可以间接地测量一个软件过程的功效。也就是说，我们可以根据从过程中我们可以间接地测量一个软件过程的功效。也就是说，我们可以根据从过程中获得的结果导出一组度量。这些结果包括：获得的结果导出一组度量。这些结果包括： 在在软件发布之前发现的错误数的测量软件发布之前发现的错误数

12、的测量， 交付交付给最终用户并由最终用户报告的缺陷的测量给最终用户并由最终用户报告的缺陷的测量， 交付交付的工作产品的测量的工作产品的测量， 花费花费的工作量的测量的工作量的测量， 花费花费的时间的测量的时间的测量， 与与进度计划是否一致的测量，以及其他测量进度计划是否一致的测量，以及其他测量。n 我们还可以通过测量特定软件工程任务的特性来导出过程度量。如测量一般软我们还可以通过测量特定软件工程任务的特性来导出过程度量。如测量一般软件工程活动所花费的工作量和时间。件工程活动所花费的工作量和时间。12过程领域和项目过程领域和项目领域中的度量领域中的度量过程度量和软件过程改进n 不同类型的过程数据

13、的使用可以分为不同类型的过程数据的使用可以分为“私有的和公用的私有的和公用的”。因为某个软件工程。因为某个软件工程师可能对在其个人基础上收集的度量的使用比较敏感，这是很自然的，这些数师可能对在其个人基础上收集的度量的使用比较敏感，这是很自然的，这些数据对此人应该是私有的，是仅供此人参考的指标。私有度量的例子有据：据对此人应该是私有的，是仅供此人参考的指标。私有度量的例子有据： 个人缺陷率个人缺陷率 软件构件缺陷率软件构件缺陷率 开发过程中开发过程中发现的发现的错误数。错误数。 私有过程数据是软件工程师个人改进其工作的重要驱动力。私有过程数据是软件工程师个人改进其工作的重要驱动力。13过程领域和

14、项目过程领域和项目领域中的度量领域中的度量过程度量和软件过程改进 某些过程度量对软件项目团队是私有的，但对所有团队成员是公用的。例如：某些过程度量对软件项目团队是私有的，但对所有团队成员是公用的。例如： 主要主要软件功能软件功能(由多个开发人员完成由多个开发人员完成)的缺陷报告的缺陷报告、 正式正式技术复审中发现的错误技术复审中发现的错误、 以及每个构件或功能以及每个构件或功能的代码的代码行数或行数或功能功能点数。点数。 这些数据可由团队进行复查，以找出能够改善小组性能的指标。这些数据可由团队进行复查，以找出能够改善小组性能的指标。 公用度量一般吸取了原本是个人的或团队的私有信息。收集和评估项

15、目级的缺公用度量一般吸取了原本是个人的或团队的私有信息。收集和评估项目级的缺陷率陷率(肯定不能归因于某个个人肯定不能归因于某个个人)、工作量、时间及相关的数据，以找出能够改善、工作量、时间及相关的数据，以找出能够改善组织过程性能的指标。组织过程性能的指标。14过程领域和项目过程领域和项目领域中的度量领域中的度量过程度量和软件过程改进 软件度量规则：软件度量规则： 解释度量数据时解释度量数据时使用常识，使用常识，并考虑组织并考虑组织的敏感性的敏感性。 向向收集收集测量和度量的个人测量和度量的个人及团队定期及团队定期提供提供反馈。反馈。 不要不要使用度量去评价个人。使用度量去评价个人。 与与开发者

16、开发者和团队一起和团队一起设定清晰的设定清晰的目标，并确定为达到目标，并确定为达到这些这些目标需要使用的目标需要使用的度度量。量。 不要不要用度量去威胁个人用度量去威胁个人或团队。或团队。 指出问题区域的指出问题区域的度量数据不应该度量数据不应该被被“消极地消极地”看待，这些看待，这些数据仅仅是过程改数据仅仅是过程改进的指标。进的指标。 不要在某一个别的度量上纠缠，而无暇顾及其他重要的度量。不要在某一个别的度量上纠缠，而无暇顾及其他重要的度量。15过程领域和项目过程领域和项目领域中的度量领域中的度量项目度量 软件过程度量主要用于战略的目的。软件项目度量则是战术的。即，项目管理软件过程度量主要用

17、于战略的目的。软件项目度量则是战术的。即，项目管理者和软件项目组经过使用项目度量及从其中导出的指标，可以改进项目工作流者和软件项目组经过使用项目度量及从其中导出的指标，可以改进项目工作流程和技术活动。程和技术活动。 在大多数软件项目中，项目度量的第一个应用是在估算阶段。从过去的项目中在大多数软件项目中，项目度量的第一个应用是在估算阶段。从过去的项目中收集的度量可以作为估算当前软件工作工作量及时间的基础。随着项目的进展收集的度量可以作为估算当前软件工作工作量及时间的基础。随着项目的进展，可以将花费的工作量及时间的测量与最初的估算值，可以将花费的工作量及时间的测量与最初的估算值(及项目进度及项目进

18、度)进行比较。项进行比较。项目管理者可以使用这些数据来监控项目的进展。目管理者可以使用这些数据来监控项目的进展。 随着技术工作的启动，其他项目度量也开始有意义了。生产率可以根据创建的随着技术工作的启动，其他项目度量也开始有意义了。生产率可以根据创建的模型、评审的时间、功能点以及交付的源代码行数来测量。此外，对每个软件模型、评审的时间、功能点以及交付的源代码行数来测量。此外，对每个软件工程任务中所发现的错误也要进行跟踪。在软件从需求到设计的演化过程中，工程任务中所发现的错误也要进行跟踪。在软件从需求到设计的演化过程中，需要收集技术度量来评估设计质量，并提供若干指标，这些指标将会影响代码需要收集技

19、术度量来评估设计质量，并提供若干指标，这些指标将会影响代码生成及测试所采用的方法。生成及测试所采用的方法。16过程领域和项目过程领域和项目领域中的度量领域中的度量项目度量 项目度量的目的是双重的。项目度量的目的是双重的。 首先首先，这些度量能够指导进行一些必要的调整以避免延迟，并减少潜在问题，这些度量能够指导进行一些必要的调整以避免延迟，并减少潜在问题及风险，从而使得开发时间减到最少及风险，从而使得开发时间减到最少。 其次其次，项目度量可在项目进行的基础上评估产品质量，并且可在必要时修改，项目度量可在项目进行的基础上评估产品质量，并且可在必要时修改技术方法以改进质量。技术方法以改进质量。 随着

20、质量的提高，错误会减到最小，而随着错误数的减少，项目中所需的修改随着质量的提高，错误会减到最小，而随着错误数的减少，项目中所需的修改工作量也会降低。这就导致整个项目成本的降低。工作量也会降低。这就导致整个项目成本的降低。18软件测量软件测量 测量在现实世界中可分为两类：直接测量测量在现实世界中可分为两类：直接测量(如螺钉的长度如螺钉的长度)和间接测量和间接测量(如生产的如生产的螺钉的螺钉的“质量质量”，由计算其次品率来测量，由计算其次品率来测量)。 软件测量也有两种分类方法：软件测量也有两种分类方法： 软件工程过程的直接测量，包括花费的成本和软件工程过程的直接测量，包括花费的成本和工作量；产品

21、工作量；产品的直接测量，的直接测量，包括产生的代码行包括产生的代码行( lines of code，LOC )、运行速、运行速度、内存大小及某段时间内度、内存大小及某段时间内报告的缺陷报告的缺陷。 产品产品的间接测量，包括功能、质量、复杂性、有效性、可靠性、可维护性及的间接测量，包括功能、质量、复杂性、有效性、可靠性、可维护性及许多许多其他的其他的“产品特性产品特性”。19软件测量软件测量 将项目度量联合起来可以得到整个软件组织公用的过程度量。但是，一个组织将项目度量联合起来可以得到整个软件组织公用的过程度量。但是，一个组织如何将来自不同个人或项目的度量结合起来呐？如何将来自不同个人或项目的度

22、量结合起来呐？ 为了说明这个问题，我们看一个简单的例子：为了说明这个问题，我们看一个简单的例子： 两两个不同个不同项目团队中的人将他们项目团队中的人将他们在软件工程过程中所发现的所有在软件工程过程中所发现的所有错误进行了错误进行了记录和分类。然后，将这睦个人记录和分类。然后，将这睦个人的的测量结合起来就产生了团队的测量结合起来就产生了团队的测量测量。 在软件发布在软件发布前前，团队，团队A在在软件过程软件过程中发现了中发现了342个错误个错误，团队，团队B发现发现了了184个错个错误。所有其他情况都相同误。所有其他情况都相同，那么在整个过程中哪个团队能更有效，那么在整个过程中哪个团队能更有效地

23、发现错误地发现错误呢呢？ 因为不知道因为不知道项目的规模或复杂性，所以我们不能回答这个问题。不过，如果项目的规模或复杂性，所以我们不能回答这个问题。不过，如果度量采用规范化度量采用规范化的的方法方法，就有可能产生能够在更大的组织范围内进行比较的就有可能产生能够在更大的组织范围内进行比较的软件度量软件度量。如此说来，面向规模的度量和面向功能的度量都是规范化的方法。如此说来，面向规模的度量和面向功能的度量都是规范化的方法。20软件测量软件测量面向规模的度量 面向规模的软件度量是通过规范化质量和（或）生产率的测量值而得到的，这面向规模的软件度量是通过规范化质量和（或）生产率的测量值而得到的，这些测量

24、都基于已经开发的软件的些测量都基于已经开发的软件的“规模规模”。 如果软件组织一直在做简单的记录，就会产生一个如图如果软件组织一直在做简单的记录，就会产生一个如图22所示的面向规模测所示的面向规模测量的表。该表列出了在过去几年中完成的每一个软件开发项目及其相关的测量量的表。该表列出了在过去几年中完成的每一个软件开发项目及其相关的测量数据。数据。 查看查看alpha项目的数据项目的数据(图图22)：花费了：花费了24个人个人月的工作量，成本为月的工作量，成本为168 000美元美元，产生了，产生了12 100行代码。行代码。 应该注意到表中记录的工作量和成本涵盖了所有软件工程活动应该注意到表中记

25、录的工作量和成本涵盖了所有软件工程活动(分析、设计、编分析、设计、编码及测试码及测试)，而不仅仅是编码。，而不仅仅是编码。 alpha项目更进一步的信息包括：产生了项目更进一步的信息包括：产生了365页的文档；在软件发布之前，发现页的文档；在软件发布之前，发现了了134个错误；软件发布给客户之后运行的第一年中遇到了个错误；软件发布给客户之后运行的第一年中遇到了29个缺陷；有个缺陷；有3个人个人参加了参加了alpha项目的软件开发工作。项目的软件开发工作。图22 面向规模的度量22软件测量软件测量面向规模的度量 为了产生能和其他项目中同类度量进行比较的度量，我们选择代码行作为规范为了产生能和其他

26、项目中同类度量进行比较的度量，我们选择代码行作为规范化值。根据表中所包含的基本数据，每个项目都能产生一组简单的面向规模度化值。根据表中所包含的基本数据，每个项目都能产生一组简单的面向规模度量：量： 每千每千行代码行代码(KLOC)的错误数。的错误数。 每千每千行代码行代码(KLOC)的缺陷数的缺陷数。 每千行每千行代码代码(KLOC)的成本的成本。 每千每千行代码行代码(KLOC)的文档页数。的文档页数。 除此之外，还能够计算出其他有意义的度量：除此之外，还能够计算出其他有意义的度量： 每人每人月月错误数错误数。 每人每人月千代码月千代码行行( KLOC )。 每每页文档的成本。页文档的成本。

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

28、OC。 另一方面，反对者们则认为另一方面，反对者们则认为LOC测量依赖于程序设计语言；它们对设计得很好测量依赖于程序设计语言；它们对设计得很好，但较小的程序会产生不利的评判；它们不适用于非过程语言；而且它们在估，但较小的程序会产生不利的评判；它们不适用于非过程语言；而且它们在估算时需要一些可能难以得到的信息算时需要一些可能难以得到的信息(如，早在分析和设计完成之前，计划者就必如，早在分析和设计完成之前，计划者就必须估算出要产生的须估算出要产生的LOC)。24软件测量软件测量面向功能的度量 面向功能的软件度量使用功能（由应用系统提供）测量数据作为规模化值。应面向功能的软件度量使用功能（由应用系统

29、提供）测量数据作为规模化值。应用最广泛的面向功能的度量是功能点（用最广泛的面向功能的度量是功能点（Function Point,FP）。功能点是根据软件）。功能点是根据软件信息域的特性及复杂性来计算的。信息域的特性及复杂性来计算的。 与与LOC测量一样，功能点测量也是有争议的。支持者们认为测量一样，功能点测量也是有争议的。支持者们认为FP与程序设计语言无与程序设计语言无关，对于使用传统语言和非过程语言应用系统来说，它都比较理想的；而且它关，对于使用传统语言和非过程语言应用系统来说，它都比较理想的；而且它所依据的数据是在项目开发初期就可能得到的数据。因此，作为一种估算方法所依据的数据是在项目开发

30、初期就可能得到的数据。因此，作为一种估算方法，FP更有吸引力。更有吸引力。 反对者们则声称这种方法需要某种反对者们则声称这种方法需要某种“熟练手法熟练手法”，因为计算的依据是主观的而，因为计算的依据是主观的而非客观的数据，信息域（及其他方面）的计算可能难以在事后收集。而且非客观的数据，信息域（及其他方面）的计算可能难以在事后收集。而且FP没没有直接的物理意义，它仅仅是一个数字而已。有直接的物理意义，它仅仅是一个数字而已。25软件测量软件测量调和代码行和功能点的度量方法 代码行和功能点度量之间的关系依赖于实现软件所采用的程序设计语言及设代码行和功能点度量之间的关系依赖于实现软件所采用的程序设计语

31、言及设计的质量。很多研究试图将计的质量。很多研究试图将FP测量和测量和LOC测量联系起来。引用测量联系起来。引用Albrecht和和GaffneyALB83的话说：的话说：本研究的论点是：应用本研究的论点是：应用( (程序程序) )所提供的功能数能够从所使用的所提供的功能数能够从所使用的数据或提供的数据或提供的数据的主要数据的主要组成部分的详细记录中估算出来，或是直接从记录中得到。更进组成部分的详细记录中估算出来，或是直接从记录中得到。更进一步，功能的估算应该与要开发的一步，功能的估算应该与要开发的LOCLOC数及开发所需的工作量关联起来数及开发所需的工作量关联起来。 表表2-1QSM02给出

32、了在不同的程序设计语言中实现一个功能点所需的平均给出了在不同的程序设计语言中实现一个功能点所需的平均代码行数的粗略估算：代码行数的粗略估算：28 查看上表可知：查看上表可知：C+的一个的一个LOC所提供的所提供的“功能性功能性”大约是大约是C的一个的一个LOC的的2.4倍（倍（平均来讲）。而且，平均来讲）。而且，Smalltalk的一个的一个LOC所提供的所提供的“功能性功能性”至少是传统程序设至少是传统程序设计语言（如计语言（如Ada、COBOL或或C）的）的4倍。利用上表中所包含的信息，只要知道了程倍。利用上表中所包含的信息，只要知道了程序设计语言的语句行数，就可以序设计语言的语句行数，就

33、可以“逆向逆向”估算出现有软件的功能点数量。估算出现有软件的功能点数量。软件测量软件测量调和代码行和功能点的度量方法 基于功能点和基于功能点和LOC的度量都是对软件开发工作量和成本的比较精确的判定。然的度量都是对软件开发工作量和成本的比较精确的判定。然而，如果使用而，如果使用LOC和和FP进行估算，还必须要建立一个历史信息基线。进行估算，还必须要建立一个历史信息基线。 在过程度量和项目度量中，最关心的是生产率和质量软件开发“输出量”（作为投入的工作量和时间的函数）的测量和对生产的工作产品的“适用 性”测量。为了进行过程改进和项目策划，必须掌握历史的情况。在以往的项目中，软件开发的生产率是多少？

34、生产的软件质量如何？怎样利用以往的生产率数据和质量数据推断现在的生产率和质量？如何利用这些数据帮助我们改进过程，以及更精确地规划新项目？29 传统的软件项目度量（传统的软件项目度量（LOC或或FP）也可以用于估算面向对象的软件项目。但是，）也可以用于估算面向对象的软件项目。但是，这些度量并没有提供对进度和工作量进行调整的粒度，而这却是我们在演化模这些度量并没有提供对进度和工作量进行调整的粒度，而这却是我们在演化模型或增量模型中进行迭代时所需要的。型或增量模型中进行迭代时所需要的。 用于用于OO项目的度量：项目的度量： 场景脚本的数量场景脚本的数量 关键类的数量关键类的数量 支持类的数量支持类的

35、数量 每个关键偶氮染料平均支持类数量每个关键偶氮染料平均支持类数量 子系统的数量子系统的数量软件测量软件测量面向对象的度量软件测量软件测量用于OO 项目的度量n 场景脚本的数量场景脚本的数量 场景脚本是一个详细的步骤序列，用来描述用户和应用系统之间的交互。应用系统的规模及测试用例的数量都与场景脚本的数量紧密相关。n 关键类的数量关键类的数量 关键类是“高度独立的构件”，在面向对象分析的早期进行定义。由于关键类是问题域的核心，因此这些类的数量既是开发软件所需工作量的指标，也是系统开发中潜在的复用数量的指标。n 支持类的数量支持类的数量 支持类是实现系统所必需的但又不与问题域直接相关的类。例如，U

36、I类、数据库访问及操作类、计算类。另外，对于每一个关键类，都可以开发其支持类。支持类的数量既是开发软件所需工件量的指标，也是系统开中潜在的复用数量的指标。软件测量软件测量用于OO 项目的度量n 每个关键类的平均支持类数量每个关键类的平均支持类数量 通常，关键类在项目的早期就可以确定下来，而支持类的定义则贯穿于项目通常，关键类在项目的早期就可以确定下来，而支持类的定义则贯穿于项目的始终。对于给定的问题域，如果知道了每个关键类的平均支持类数量，估的始终。对于给定的问题域，如果知道了每个关键类的平均支持类数量，估算（根据类的总数）将应得非常简单。在采用算（根据类的总数）将应得非常简单。在采用GUIG

37、UI的应用的应用 中，支持类是关键中，支持类是关键类的类的2323倍；在不采用倍；在不采用GUIGUI的应用中，支持类是关键类的的应用中，支持类是关键类的1212倍。倍。n 子系统的数量子系统的数量 子系统是实现某个功能（对系统最终用户可见）的类的集合。一旦确定了子子系统是实现某个功能（对系统最终用户可见）的类的集合。一旦确定了子系统，人们就更容易制定出合理的进度计划，并将子系统的工作在项目人员系统，人们就更容易制定出合理的进度计划，并将子系统的工作在项目人员之间进行分配。之间进行分配。软件测量软件测量面向对象的度量 为了将类似于上述的那些度量有效地应用于面向对象的软件工程环境中，必须为了将类

38、似于上述的那些度量有效地应用于面向对象的软件工程环境中，必须将它们随同项目测量（例如花费的工作量、发现的错误和缺陷、建立的模型或将它们随同项目测量（例如花费的工作量、发现的错误和缺陷、建立的模型或文档资料）一起收集。文档资料）一起收集。 随着数据库规模的增长（在完成大量项目之后），面向对象的测量数据和项目随着数据库规模的增长（在完成大量项目之后），面向对象的测量数据和项目测量数据之间关系将提供有助于项目估算的度量。测量数据之间关系将提供有助于项目估算的度量。软件测量软件测量 面向用例的度量 与与LOCLOC或或FPFP相类似，使用用例作为规范化的测量应该是合理的。同相类似，使用用例作为规范化的

39、测量应该是合理的。同FPFP一样，用一样，用例也是在软件过程早期进行定义的。在重大的建模活动和构造活动开始之前，就例也是在软件过程早期进行定义的。在重大的建模活动和构造活动开始之前，就允许使用用例进行估算。允许使用用例进行估算。 用例描述了（至少是间接地）用户可见的功能和特性，这些都是系统的基本需求用例描述了（至少是间接地）用户可见的功能和特性，这些都是系统的基本需求。用例与程序设计语言无关。另外，用例数量同应用系统的规模（。用例与程序设计语言无关。另外，用例数量同应用系统的规模（LOCLOC）和测试）和测试用例的数量成正比，而测试用例是为了充分测试该应用系统而必须设计的。用例的数量成正比，而

40、测试用例是为了充分测试该应用系统而必须设计的。 由于可以在不同的抽象级别上创建用例，所以用例的大小没有标准。由于对用例由于可以在不同的抽象级别上创建用例，所以用例的大小没有标准。由于对用例本身还没有标准的测量，因此将用例作为规范化的测量（如，每个用例花费的工本身还没有标准的测量，因此将用例作为规范化的测量（如，每个用例花费的工作量）是不可信的。尽管许多研究人员试图推导出用例度量，但仍有很工作要做作量）是不可信的。尽管许多研究人员试图推导出用例度量，但仍有很工作要做。软件测量软件测量Web 工程项目度量 所有Web工程项目的目标都是建立一个Web应用（WebApp），交付给最终用户一个内容和功能

41、的结合体。很难将那些用于传统软件工程项目的测量和度量直接转化应用于Web应用系统中。然而，Web工程组织应该建立一个数据库，随着大量项目的完成，就可以使用该数据库来评估组织内部的生产率和质量。在这些测量中，可以收集的有： 静态静态WebWeb页的数量页的数量 动态动态WebWeb页的数量页的数量 内部页面链接的数量内部页面链接的数量 永久数据对象的数量永久数据对象的数量 通过界面连接的外部系统的数量通过界面连接的外部系统的数量 静态内容对象的数量静态内容对象的数量 动态内容对象的数量动态内容对象的数量 可执行的功能数量可执行的功能数量软件测量软件测量Web 工程项目度量n 静态静态Web页的数

42、量页的数量 静态内容的静态内容的WebWeb页（即最终用户不能控制页面显示的内容）是所有页（即最终用户不能控制页面显示的内容）是所有WebWeb应用应用系统最普通的特征。这些页面复杂性较低，通常构造静态页面所需的工作量系统最普通的特征。这些页面复杂性较低，通常构造静态页面所需的工作量少于动态页面。这项测量提供了一个指标，标志着应用系统的整体规模和开少于动态页面。这项测量提供了一个指标，标志着应用系统的整体规模和开发应用系统所需的工作量。发应用系统所需的工作量。n 动态动态Web页的数量页的数量 在所有的电子商务应用、搜索引擎、金融应用以及许多其他在所有的电子商务应用、搜索引擎、金融应用以及许多

43、其他WebWeb应用中，动应用中，动态内容的态内容的WebWeb页（即根据最终用户的操作，页面上显示出相应的定制内容）页（即根据最终用户的操作，页面上显示出相应的定制内容）是必需的要素。动态页面复杂性较高，构造动态页面所需的工作量高于静态是必需的要素。动态页面复杂性较高，构造动态页面所需的工作量高于静态页面。这项测量提供了一个指标，标志着应用系统的整体规模和开发应用系页面。这项测量提供了一个指标，标志着应用系统的整体规模和开发应用系统所需的工作量。统所需的工作量。软件测量软件测量Web 工程项目度量n 内部页面链接的数量内部页面链接的数量 内部页面链接就是一个指针，它在内部页面链接就是一个指针

44、，它在WebWeb应用中提供了到达其他某个应用中提供了到达其他某个WebWeb页的页的超链接。这项测量提供了一个超链接。这项测量提供了一个WebWeb应用内部结构互连程度的指标。随着页面应用内部结构互连程度的指标。随着页面链接的增加，花费在导航设计和开发上的工作量也会增加。链接的增加，花费在导航设计和开发上的工作量也会增加。n 永久数据对象的数量永久数据对象的数量 WebWeb应用可以访问一个或多个永久数据对象（如数据库或数据文件）。随着应用可以访问一个或多个永久数据对象（如数据库或数据文件）。随着永久数据对象数量的增加，永久数据对象数量的增加，WebWeb应用系统的复杂性也会增加，实现应用系

45、统应用系统的复杂性也会增加，实现应用系统所需的工作量也会成比例地增加。所需的工作量也会成比例地增加。软件测量软件测量Web 工程项目度量n 通过界面连接的外部系统的数量通过界面连接的外部系统的数量 WebWeb应用系统必须经常与应用系统必须经常与“后台的后台的”业务应用相连接。随着界面连接需求的业务应用相连接。随着界面连接需求的增多，系统复杂性和开发工作量也会增加。增多，系统复杂性和开发工作量也会增加。n 静态内容对象的数量静态内容对象的数量 静态内容对象包括静态文本、图像、视频、动画和音频信息，它们在静态内容对象包括静态文本、图像、视频、动画和音频信息，它们在WebWeb应应用中被集成在一起

46、。在一个用中被集成在一起。在一个WebWeb页中，可能同时出现多个内容对象。页中，可能同时出现多个内容对象。软件测量软件测量Web 工程项目度量n 动态内容对象的数量动态内容对象的数量 动态内容对象是根据最终用户的操作而产生的，包括内部产生的文本、图动态内容对象是根据最终用户的操作而产生的，包括内部产生的文本、图像、视频、动画和音频信息，它们在像、视频、动画和音频信息，它们在WebWeb应用中被集成应用中被集成 在一起。在一个在一起。在一个WebWeb页中，可能同时出现多个内容对象页中，可能同时出现多个内容对象。n 可执行的功能的数量可执行的功能的数量 可执行的功能（如，脚本和小程序）为最终用

47、户提供了某些计算服务。随可执行的功能（如，脚本和小程序）为最终用户提供了某些计算服务。随着可执行功能数量的增加，建模和构造的工作量也会随之增加。着可执行功能数量的增加，建模和构造的工作量也会随之增加。软件测量软件测量Web 工程项目度量上面提到的每个测量都可以在上面提到的每个测量都可以在Web工程过程的初期就确定下来。工程过程的初期就确定下来。 例如，我们可以定义一个度量，来反映Web应用所需的最终用户的定制程度，并使它与Web工程项目花费的工作量以及评审中发现的错误关联起来。为此，我们进行以下定义： Nsp = 静态Web页的数量 Ndp = 动态Web页的数量那么 定制指数 C = Ndp

48、 /( Ndp + Nsp )C的取值范围是0到1。随着C值的增大，Web应用的定制水平将成为一个重大的技术问题。类似的类似的Web应用度量也呆以被计算出来，并同项目测量（如花费的工作量、发现的错误和缺陷、应用度量也呆以被计算出来，并同项目测量（如花费的工作量、发现的错误和缺陷、已建立的模型或文档）关联起来。随着数据库规模的扩大（在完成了很多项目之后），已建立的模型或文档）关联起来。随着数据库规模的扩大（在完成了很多项目之后），Web应用应用测量与项目测量之间的关系将提供有助于项目估算的指标。测量与项目测量之间的关系将提供有助于项目估算的指标。41软件质量度量软件质量度量 软件工程的基本高目标

49、就是在某个时间框架内开发出满足市场需要的高质量的系统、应用软件或产品。为了达到这个目标，软件工程师必须掌握在成熟的软件过程背景下，使用有效的方法及现代化的工具。此外，一个优秀的软件工程师(及优秀的软件工程管理者)必须通过测量来判断能否实现高质量。 将软件工程师个人收集的私有度量结合起来，可以提供项目级的度量。虽然可以收集到很多质量测量数据，但在项目级上最主要的还是测量错误和缺陷的数目。从这些测量中导出的度量能够提供一个指标，表明个人及小组在软件质量保证和控制活动上的效率。 度量比如说工作产品（如需求或设计）每功能点的错误数、在评审中每小时发现的错误数、及测试中每小时发现的错误数，使我们能够深入

50、了解度量所涉及的活动的功效。有关错误的数据也能用来计算每个过程框架活动的缺陷排除率（defect removal efficiency, DRE） 。软件质量度量软件质量度量测量质量 虽然有很多软件质量的测量方法，但对软件进行正确性、可维护性、完整性、及可用性的测量为项目组提供了有用的技术指标。GilbGIL88给出了这些属性的定义及测量。 正确性：正确性：一个程序必须能够正确地执行，否则对于用户就没有价值了。正确性是软件完成所要求的功能的程度。最常用的关于正确性的测量是每千行(KLOC)的缺陷数，这里缺陷是指已被证实不符合需求的地方。当考虑软件产品的的整体质量时，缺陷是指在程序发布后经过了全

51、面使用，由程序用户报告的问题。为了进行质量评估，缺陷是按标准时间段来计数的，典型的是一年。软件质量度量软件质量度量测量质量 可维护性：可维护性：与任何其他软件工程活动相比，软件维护需要更多的工作量。 可维护性是指遇到错误时程序能够被修改的容易程度， 环境发生变化时程序能够适应的容易程度， 用户希望变更需求时程序能被增强的容易程度。 可维护性无法直接测量；因此我们必须采用间接测量。有一种简单的面向时间的度量，称为平均变更时间( mean-time-to-change，MTTC )。它包括分析变更请求、设计合适的修改方案、实现变更并进行测试、以有把该变更发布给全部用户所花的时间。一般情况下，与那些

52、不可维护的程序相比，可维护的程序应有较低的 MTTC(相对于相同类型的变更)。软件质量度量软件质量度量测量质量 完整性：在防火墙和完整性：在防火墙和在黑客在黑客时代，时代，软件完整性已变得日益重要。软件完整性已变得日益重要。 这个属性测量的是一个系统对安全性攻击(包括偶然的和蓄意的)的抵抗能力。软件的所有三个成分（即程序、数据及文档）都会遭到攻击。 为了测量完整性，必须定义另外两个属性：危险性和安全性。危险性是指一个特定类型的攻击在给定时间内发生的概率(能够估算或根据经验数据导出)。安全性是指一个特定类型的攻击将被击退的概率(能够估算或根据经验数据导出)。一个系统的完整性可以定义为： 完整性完

53、整性 = 1 危险性危险性 ( 1 安全性安全性 ) 例如，假设危险性（发生攻击的可能性）是 0.25，安全性（击退攻击的可能性）是 0.95，则系统的完整性是 0.99（很高）；另一方面，假设危险性是 0.5，击退攻击的可能性仅是 0.25，则系统的完整性只有 0.63（低得无法接受）。软件质量度量软件质量度量测量质量 可用性：如果一个程序不容易使用，即使它完成的功能很有价值，也常常注定要可用性：如果一个程序不容易使用，即使它完成的功能很有价值，也常常注定要失败。失败。 可用性力图对“使用的容易程度”进行量化，根据四个特性来测量：(1)学会一个系统所需的体力的和/或智力的投入；(2)在系统的

54、使用上达到中等效率所需的时间；(3)当系统由某个具有中等效率的人使用时，测量到的生产率的净增长(与被该系统替代的老系统相比)；以及(4)用户对系统的态度的一个主观评估(有时可以通过调查表获得)。 上述的四个因素仅仅是被建议作为软件质量测量的众多因素中的一个样板。上述的四个因素仅仅是被建议作为软件质量测量的众多因素中的一个样板。软件质量度量软件质量度量缺陷排除效率 DRE 缺陷排除效率缺陷排除效率（DRE）是在）是在项目级和过程级都项目级和过程级都有意义的有意义的质量度量。本质上，质量度量。本质上，DRE是对质量保证及控制活动的过滤能力的一个测量，是对质量保证及控制活动的过滤能力的一个测量，而而

55、这些活动贯穿这些活动贯穿应用应用于于所有所有过过程框架活动程框架活动中中。 当把项目作为一个整体来考虑时，当把项目作为一个整体来考虑时，DRE 按如下方式定义：按如下方式定义： DRE = E /（ E D ） 其中其中 E = 软件交付给最终用户之前所发现的错误数软件交付给最终用户之前所发现的错误数 D = 软件交付之后所发现的缺陷数。软件交付之后所发现的缺陷数。软件质量度量软件质量度量缺陷排除效率 DRE 最理想的最理想的DRE值是值是1，即软件中没有发现缺陷。，即软件中没有发现缺陷。 现实中，D会大于0，但随着E值的增加，DRE的值仍能接近1。 事实上，随着E的增加，D的最终值可能会降低

56、(错误在变成缺陷之前已经被过滤了)。 如果如果DRE作为一个度量，提供关于质量控制和保证活动的过滤能力的衡量指标，作为一个度量，提供关于质量控制和保证活动的过滤能力的衡量指标，则则DRE就能促进就能促进软件项目软件项目团队团队采用先进采用先进的的技术，技术，力求力求在在软件软件交付之前发现尽可能交付之前发现尽可能多的错误。多的错误。软件质量度量软件质量度量缺陷排除效率 DRE 在项目内部，也可以使用在项目内部，也可以使用 DRE 来评估一个团队在错误传递到下一个框架活动或来评估一个团队在错误传递到下一个框架活动或软件工程任务之前发现错误的能力。软件工程任务之前发现错误的能力。 例如，在需求分析

57、任务中创建了一个分析模型，而且对该模型进行了评审以发现和改正其中的错误。那些在评审过程中未被发现的错误会传递给了设计（在设计中它们可能被发现，也可能不被发现）。在这种情况下，我们重新定义DRE为：DREi = Ei / ( Ei Ei1 ) 其中 Ei = 在软件工程活动i中所发现的错误数; Ei1=在软件工程活动i1中所发现的错误数，这些错误都是在软件工程活动 i 中没被发现的错误。 软件项目软件项目团队团队(或软件工程师或软件工程师个人个人)的质量目标是使的质量目标是使 DREi 接近接近1。即错误应该在传。即错误应该在传递到下一个活动之前被过滤掉。递到下一个活动之前被过滤掉。50在软件过

58、程中集在软件过程中集成度量成度量 大多数软件开发者仍然没有进行测量，更可悲的是，他们中大多数根本没有开大多数软件开发者仍然没有进行测量，更可悲的是，他们中大多数根本没有开始测量的愿望。正如我们在本章开始所说的，这是文化的问题。试图收集过去始测量的愿望。正如我们在本章开始所说的，这是文化的问题。试图收集过去从来没有人收集的测量常常会遇到阻力。从来没有人收集的测量常常会遇到阻力。备受折磨备受折磨的项目的项目经理会经理会问问“为什么我们为什么我们要做这个？要做这个？”。超负荷工作超负荷工作的开发者抱怨的开发者抱怨“我看不出这样做有什么用我看不出这样做有什么用”。 在本节中，我们要考虑一些有关软件度量

59、的观点，并给出软件工程组织内部制在本节中，我们要考虑一些有关软件度量的观点，并给出软件工程组织内部制定度量收集计划的方法。但在此这前，先看看定度量收集计划的方法。但在此这前，先看看Grady和和Casewell GRA87所说的所说的话：话：我们在这里描述的一些事情听起来似乎相当容易。但实际上，成功地制定全公司范围内的软件度量计划是很困难的工作。如果我们说，你必须至少等上3年才能在组织内形成显著的趋势，你就可以对这一工作量的规模有个概念。51在软件过程中集在软件过程中集成度量成度量支持软件度量的论点 测量软件工程及其生产出来的产品（软件）为什么这么重要？答案其实很明显。测量软件工程及其生产出来

60、的产品（软件）为什么这么重要？答案其实很明显。如果不进行测量，就无法确定我们是否在改进。如果我们没有在改进，就会导致如果不进行测量，就无法确定我们是否在改进。如果我们没有在改进，就会导致失败失败 通过对生产率测量和质量测量提出要求，并进行评估，软件团队（及其管理者）通过对生产率测量和质量测量提出要求，并进行评估，软件团队（及其管理者）能够建立改进软件工程过程的有意义的目标。如果软件开发过程能够得到改进，能够建立改进软件工程过程的有意义的目标。如果软件开发过程能够得到改进，对最终结果（对最终结果（bottom line）将产生直接的影响。而要建立改进目标，就必须了解软）将产生直接的影响。而要建立