软件工程
第19章 过程和项目度量
主要内容
过程领域和项目领域中的度量
软件测量
软件质量度量
小结
过程和项目度量
软件过程和项目度量是定量的测量，这
些测量能使软件工程师更深入地了解软件
过程的功效，以及使用该过程作为框架进
行开发的项目的功效。度量时，首先收集
基本的质量数据和生产率数据，然后分析
这些数据、与过去的平均值进行比较，通
过评估来确定是否已有质量和生产率的提
高。度量也可以用来查明问题区域，以便
确定合适的补救方法，并改进软件过程。
过程和项目度量
软件度量由软件管理者来分析和评估。
测量数据通常由软件工程师来收集。
如果不进行测量，只能根据主观评价来
做判断。通过测量，可以发现趋势，可以
更好地进行估算，随着时间的推移能够获
得真正的改进。
过程和项目度量
首先确定一组有限的易于收集的过程测
量和项目测量。通常使用面向规模或面向
功能的度量对这些测量进行规范化。然后，
对测量结果进行分析，并与该组织以前完
成的类似项目的平均数据进行比较。最后
评估趋势，并给出结论。
工作产品是得到一组软件度量，它们提
供了对过程的洞察力和对项目的理解。
过程和项目度量
通过提供目标评估的机制，测量使我们
能够对项目和过程有更深入的了解。Lord
Kelvin曾经说过：
当你能够测量你所说的事物，并能用数
字表达它时，你就对它有了一定的了解；
当你不能测量它，也不能用数字来表达时，
就说明你对它的了解还很贫乏，不能令人
满意：这可能是知识的开始，但你在思想
上还远远没有进入科学的境地。
过程和项目度量
测量可以应用于软件过程中，目的是持
续地改进软件过程。测量也可以应用于整
个软件项目中，辅助进行估算、质量控制、
生产率评估及项目控制。最后，软件工程
师还可以使用测量来帮助评估工作产品的
质量，并在项目进展过程中辅助进行战术
决策。
过程和项目度量
[PAR96]讨论了进行测量的理由：
(1)刻画——通过刻画而获得对过程、产品、资源
和环境的了解，并建立同未来评估进行比较的基线；
(2)评价——通过评价来确定相对于计划的状况；
(3)预测——通过理解过程和产品间的关系，并构
造这些关系的模型来进行预测；
(4)改进——通过识别障碍、根本原因、低效率和
其他改进产品质量和过程性能的机会来进行改进。
测量是一个管理工具，如果能正确地使用，它将
为项目管理者提供洞察力。因此，测量能够帮助项
目管理者和软件团队制定出使项目成功的决策。
过程领域和项目领域中的度量
过程度量的收集涉及所有的项目，而且要经历
相当长的时间，目的是提供能够引导长期的软件
过程改进的一组过程指标。项目度量使得软件项
目管理者能够：(1)评估正在进行中的项目的状
态；(2)跟踪潜在的风险；(3)在问题造成不良影
响之前发现它们；(4)调整工作流程或任务；(5)
评估项目团队控制软件工作产品质量的能力。
测量数据由项目团队收集，然后被转换成度量
数据在项目期间使用。测量数据也可以传送给那
些负责软件过程改进的人员。因此，很多相同的
度量既可用于过程领域，又可用于项目领域。
过程度量和软件过程改进
改进任何过程的唯一合理方法就是
测量该过程的特定属性，再根据这些
属性建立一组有意义的度量，然后使
用这组度量提供的指标来导出过程改
进策略。但是，在讨论软件度量及其
对软件过程改进的影响之前，必须注
意到：过程仅是众多“改进软件质量
和组织性能的控制因素”中的一种。
软件质量和组织有效性的决定因素
图19-1 软件质量和组织有效性的决定因素
过程度量和软件过程改进
在图19-1中，过程位于三角形的中央，
连接了三个对软件质量和组织绩效有重大
影响的因素。其中，人员的技能和动力被
认为是对质量和绩效影响最大的因素，产
品复杂性对质量和团队绩效也有相当大的
影响，过程中采用的技术也有一定的影响。
另外，过程三角形位于环境条件圆圈内，
环境条件包括：开发环境、商业条件、客
户特性。
过程度量和软件过程改进
可以间接地测量软件过程的功效。即，
可以根据从过程中获得的结果来导出一组
度量。这些结果包括：在软件发布之前发
现的错误数的测度，提交给最终用户并由
最终用户报告的缺陷的测度，交付的工作
产品的测度，花费的工作量的测度，花费
时间的测度，与进度计划是否一致的测度，
以及其他测度。还可以通过测量特定软件
工程任务的特性来导出过程度量。
过程度量和软件过程改进
[GRA92]认为不同类型的过程数据的使用可以分为“
私有的和公有的”。私有度量的例子有：个人缺陷率、
软件构件缺陷率和开发过程中发现的错误数。
“私有过程数据”的观点与Humphrey所建议的个人
软件过程方法相一致。Humphrey认为过程改进能够、
也应该开始于个人级。私有过程数据是软件工程师个人
改进其工作的重要驱动力。
有些过程度量对于软件项目团队是私有的，但对所有
团队成员是公用的。例如，主要软件功能的缺陷报告、
正式技术评审中发现的错误，以及每个构件或功能的代
码行数或功能点数。这些数据可由团队进行评审，以便
找出能够改善团队性能的指标。
过程度量和软件过程改进
公用的度量一般吸收了原本是个人或团
队的私有信息。收集和评估项目级的缺陷
率、工作量、时间以及相关的数据，来找
出能够改善组织过程性能的指标。
软件过程度量对于组织提高其整体的过
程成熟度能够提供很大的帮助。不过，就
像所有其他度量一样，软件过程度量也可
能被误用，产生的问题比它们所能解决的
问题更多。
过程度量和软件过程改进
[GRA92]提出一组“软件度量规则”。管理者和
开发者在制定过程度量大纲时，这些规则都适用：
解释度量数据时使用常识，并考虑组织的敏感性。
向收集测量和度量的个人及团队定期提供反馈。
不要使用度量去评价个人。
与开发者和团队一起设定清晰的目标，并确定为达到这些目标需
要使用的度量。
不要用度量去威胁个人或团队。
指出问题区域的度量数据不应该被“消极地”看待，这些数据仅
仅是过程改进的指标。
不要在某一个别的度量上纠缠，而无暇顾及其他重要的度量。
过程度量和软件过程改进
随着一个组织更加得心应手地收集和使用
过程度量，简单的指标获取方式就会逐渐被
更加精确的方法所取代，该方法称为统计软
件过程改进。本质上，SSPI使用软件失效分
析方法收集在应用软件、系统或产品的开发
及使用过程中所遇到的所有的错误及缺陷信
息。
项目度量
软件过程度量用于战略目的，而软件项目度量
则用于战术目的。即，项目管理者和软件项目团
队通过使用项目度量及从中导出的指标，可以改
进项目工作流程和技术活动。
在大多数软件项目中，项目度量的第一次应用
是在估算阶段。从过去项目中收集的度量可以作
为估算当前软件工作量及时间的基础。随着项目
的进展，可以将花费的工作量及时间的测量与最
初的估算值(及项目进度)进行比较。项目管理者
可以使用这些数据来监控项目的进展。
项目度量
随着技术工作的启动，其他项目度量也
开始有意义了。生产率可以根据创建的模
型、评审的时间、功能点以及交付的源代
码行数来测量。此外，对每个软件工程任
务中所发现的错误也要进行跟踪。在软件
从需求到设计的演化过程中，需要收集技
术度量来评估设计质量，并提供若干指标，
这些指标将会影响代码生成及测试所采用
的方法。
项目度量
项目度量的目的是双重的。首先，利用
度量能够对开发进度进行必要的调整，以
避免延迟，并减少潜在的问题及风险，从
而使得开发时间减到最少。其次，项目度
量可在项目进行过程中评估产品质量，必
要时可调整技术方法以提高质量。
随着质量的提高，缺陷会减到最少。而
随着缺陷数的减少，项目中所需的修改工
作量也会降低，这将使整个项目成本降低。
软件测量
软件测量有两种分类方法：(1)软件过程
(如花费的成本和工作量)和产品(如产生的
代码行(LOC)、运行速度以及某段时间内
报告的缺陷) 的直接测量;(2)产品的间接
测量，包括功能、质量、复杂性、有效性、
可靠性、可维护性，以及许多其他的“产
品特性”。
将项目度量联合起来可以得到整个软件
组织公用的过程度量。
面向规模的度量
面向规模的软件度量是通过规范化质量
和(或)生产率的测量值而得到的，这些测
量都基于已经开发的软件的规模。如果软
件组织一直在做简单的记录，就会产生一
个如图19-2所示的面向规模测量的表。该
表列出了在过去几年中完成的每一个软件
开发项目及其相关的测量数据。
面向规模的度量
图19-2 面向规模的度量
面向规模的度量
为了产生能和其他项目中同类度量进行
比较的度量，选择代码行作为规范化值。
根据表中所包含的基本数据，每个项目都
能得到一组简单的面向规模的度量：
每千行代码(KLOC)的错误数；
每千行代码的缺陷数；
每千行代码的成本；
每千行代码的文档页数；
此外，还能计算出其他有意义的度量。
面向功能的度量
面向功能的软件度量使用功能测量数据
作为规范化值。应用最广泛的面向功能的
度量是功能点FP。功能点是根据软件信息
域的特性及复杂性来计算的。
调和代码行和功能点的度量方法
代码行和功能点之间的关系依赖于实现
软件所采用的程序设计语言及设计的质量。
很多研究试图将FP测量和LOC测量联系起
来。
表19-1(P340页)给出了在不同的程序
设计语言中实现一个功能点所需的平均代
码行数的粗略估算。
调和代码行和功能点的度量方法
人们发现基于功能点和LOC的度量都是对软件
开发工作量和成本的比较精确的判定。然而，如
果使用LOC和FP进行估算，还必须要建立一个
历史信息基线。
在过程度量和项目度量中，最关心的是生产率
和质量——软件开发“输出量”（作为投入的工
作量和时间的函数）的测量和对生产的工作产品
的“适用性”的测量。为了进行过程改进和项目
策划，必须掌握历史的情况。在以往的项目中，
软件开发的生产率是多少？生产的软件质量如何
？怎样利用以往的生产率数据和质量数据推断现
在的生产率和质量？如何利用这些数据帮助我们
改进过程，以及更精确地规划新的项目？
面向对象的度量
传统的软件项目度量也可以用于估算面
向对象的软件项目。但是，这些度量并没
有提供对进度和工作量进行调整的足够的
粒度，而这却是在演化模型或增量模型中
进行迭代时所需要的。[LOR94]提出了下
列用于OO项目的度量。
场景脚本的数量
关键类的数量
支持类的数量
每个关键类的平均支持类数量
子系统的数量
面向用例的度量
与LOC或FP相类似，使用用例作为规范
化的测量应该是合理的。同FP一样，用例
也是在软件过程早期进行定义的。在重大
的建模活动和构造活动开始之前，就允许
使用用例进行估算。用例描述了用户可见
的功能和特性，这些都是系统的基本需求。
用例与程序设计语言无关。另外，用例的
数量同应用系统的规模和测试用例的数量
成正比，而测试用例是为了充分测试该应
用系统而必须设计的。
软件质量度量
软件工程的基本目标是在某个时间框架
内开发出满足市场需要的高质量的系统、
应用或产品。为了达到这个目标，软件工
程师必须在成熟的软件过程背景下，使用
有效的方法及现代化的工具。此外，一个
优秀的软件工程师必须通过测量来判断能
否实现高质量。
软件质量度量
将软件工程师个人收集的私有度量结合
起来，可以提供项目级的度量。虽然可以
收集到很多质量测量数据，但在项目级上
最主要的还是测量错误和缺陷的数量。从
这些测量中导出的度量能够提供一个指标，
表明个人及小组在软件质量保证和控制活
动上的效力。
软件质量度量
度量——比如说工作产品(如需求或设计
)——每功能点的错误数、在评审中每小时
发现的错误数、测试中每小时发现的错误
数，使我们能够深入了解度量所涉及的活
动的功效。有关错误的数据也能用来计算
每个过程框架活动的缺陷排除效率DRE。
测量质量
正确性、可维护性、完整性和可用性为项目团
队提供了有用的指标。
正确性：一个程序必须能够正确地执行，否则
对于用户就没有价值了。正确性是软件完成所要
求的功能的程度。最常用的关于正确性的测量是
每千行代码的缺陷数。
可维护性：可维护性是指遇到错误时程序能够
被修改的容易程度，环境发生变化时程序能够适
应的容易程度，用户希望变更需求时程序能够被
增强的容易程度。还没有一种方法可以直接测量
可维护性，只能采用间接测量。有一种简单的面
向时间的度量，称为平均变更时间MTTC。
测量质量
完整性：这个属性测量的是一个系统对
安全性攻击的抵抗能力。软件的所有三个
成分都会遭到攻击。
为了测量完整性，必须定义另外两个属
性：危险性和安全性。危险性是指一个特
定类型的攻击在给定的时间内发生的概率。
安全性是指一个特定类型的攻击将被击退
的概率。一个系统的完整性可定义为：
完整性=∑[1-(危险性×(1-安全性))]
测量质量
可用性：如果一个程序不容易使用，即
使它完成的功能很有价值，也常常注定要
失败。可用性力图对“使用的容易程度”
进行量化。
缺陷排除效率
缺陷排除效率DRE是在项目级和过程级
都有意义的质量度量。本质上，DRE是对
质量保证及控制活动中滤除缺陷能力的测
量，而这些质量保证及质量控制活动贯穿
应用于所有过程框架活动中。
当把项目作为一个整体来考虑时
DRE=E/(E+D)
其中E是软件交付给最终用户之前发现的
错误数，D是软件交付之后发现的缺陷数。
缺陷排除效率
在项目内部，也可以使用DRE来评估一个团队
在错误传递到下一个框架活动或软件工程任务之
前发现错误的能力。在这种情况下，将DRE重新
定义为：
DREi=Ei/(Ei+Ei+1)
其中，Ei是在软件工程活动i中发现的错误数；
Ei+1是在软件工程活动i+1中发现的错误数，这
些错误都是在软件工程活动i中没被发现的错误。
软件项目团队的质量目标是使DREi接近于1，
即错误应该在传递到下一个活动之前被过滤掉。
小结
作业
P345页
