-
度量值必须简单、客观、易于收集、易于解释并很难会曲解。
-
度量值收集必须自动化且不具干扰性,即不会干扰开发人员的活动。
-
度量值必须对生命周期早期的质量评估起作用,这时改进软件质量的工作才是有效的。
-
管理人员和工程人员必须积极使用绝对度量值和趋势,以一种一致的形式进行进度和质量沟通。
-
选择最小的一组度量值还是更广泛的一组度量值将取决于项目的属性和环境:如果该项目很大或有严格的安全或可靠性需求,并且开发团队和评估团队对度量值很了解,那么收集和分析技术度量值可能很有用。合同可能要求收集某些度量值,或者组织可能尝试改进其在特定域的技能和流程。没有一种答案能适用于所有的环境,当生成评估计划时,项目经理必须选择适当的标准。但当第一次引入一个度量值计划时,很容易在单一性方面犯错误。
项目某些方面的度量值,包括:
-
在大小和复杂性方面的进度。
-
需求或实施的变更率的稳定性、大小或复杂性。
-
在变更范围方面的模块性。
-
在错误数目和类型方面的质量。
-
在错误频率方面的成熟性。
-
在项目支出方面的资源(与计划支出相比较)
趋势很重要,监视趋势比监视任何绝对时间值更重要。
度量值
|
目的
|
样本度量/角度
|
进度
|
迭代计划
完整性
|
这些度量也可以按类和按软件包收集
|
稳定性
|
汇集
|
-
变更的数目和类型(漏洞和增强相比;接口和实施相比)
此度量也可以按迭代和按软件包收集
|
适应性
|
汇集
软件“返工”
|
此度量也可以按迭代和按软件包收集
|
模块性
|
汇集
软件“碎片”
|
此度量也可以按迭代收集
|
质量
|
迭代计划
返工指示器
发行版标准
|
-
错误数
-
缺陷发现率
-
缺陷密度
-
继承深度
-
类结合
-
接口大小(操作数)
-
覆盖的方法数
-
方法大小
这些度量也可以按类和按软件包收集
|
成熟性
|
测试覆盖/充足性
使用的强健性
|
此度量也可以按迭代和按软件包收集
|
支出概要信息
|
财务性了解
计划对比实际
|
|
即使最小的项目也想要跟踪进度,以确定项目是否符合时间表和预算,如果不符合,则重新评估并确定是否需要范围变更。因此这组最小的度量值将注重于进度度量值。
-
实现价值。这用于重新评估项目剩余部分的时间表和预算,并/或确定是否需要范围变更。
-
缺陷趋势。这用于帮助计划清除缺陷所需的工时。
-
测试进度趋势。这用于确定功能的实际完成情况。
下面对它们进行更详细的描述。
实现价值
度量进度最常用的方法([PMI96])是“实现价值分析”。
度量实现价值的最简单方法是取所有已完成任务的原始估计工时之和。项目的“完成百分比”可以通过实现价值除以项目的原始估计工时总和来计算。生产率(或绩效指数)为实现价值除以对已完成任务实际付出的工时。
例如,假设编码工作已经分为若干任务,其中有许多现已完成。原先为已完成任务估计的是 30 个工作日。该项目的总估计工时为 100 天,所以我们可以预计该项目大致完成了 30%。
假设任务在预算内完成 - 只需 25 天即可完成。绩效指数为 30 / 25 = 1.2 或 120%。
我们可以预计该项目完成时将比预算低 20%,并相应地减少我们的估计值。
注意事项
-
绩效指数必须仅用于调整类似任务的估计值。较早完成需求收集任务,并不表示编码工作将更快完成。所以,仅计算类似种类任务的绩效指数,并仅对类似任务调整估计值。
-
考虑其他因素。将来的任务是否会在类似情况下由类似的熟练职员执行?数据是否已受到“局外值”(严重过高估计或估计不足的任务)的损害? 是否报告的时间一致(例如,即使不计酬,加班时间也应包括在内)?
-
是否已经把较新任务的估计值算入绩效指数?如果确实如此,则新任务的估计值将倾向于更接近目标,使绩效指数更接近 100%。您应该始终如一地重新评估所有未完成的任务,或采用以下 Extreme Programming(XP)[JEF01] 中的实践 - 将原始估计值称为“点”,并按照这些相同的“点”度量新任务,而不根据实际绩效进行调整。“点”的优势是可以跟踪绩效的提高(或降低)(XP
术语中称为“项目速率”)。
如果任务很大(超过 5 天),或有大量任务只是部分完成,您可能想要将它们计算在您的分析之内。应用一个主观的“完成百分比”,将其乘以该任务的估计工时,并将其包括在实现价值内。
如果对于指定完成百分比有明确的规则,结果就会比较一致。例如,一个规则可以是,在代码通过一次代码复审之前,指定编码任务的完成百分比不超过 80%。
实现价值将在下面的“一个完整的度量值组:项目计划”一节中作进一步讨论。
缺陷趋势
通常跟踪未结束和已结束缺陷的趋势是很有用的。这大致说明了是否有大量积压的缺陷修订工作需要完成以及它们完成的速度有多快。
缺陷趋势仅仅是 Rational ProjectConsole 提供的其中一种度量值。
注意事项
-
所有变更请求均不应具有相同的权重,无论它们影响一行代码或导致大的重新设计。 这可以通过若干以下技术来解决:
-
注意局外值。就这点而言,应确定需要大量工作的变更请求,并应将它们作为单独任务来跟踪,而不是包括到一揽子常规修订中。如果大量的小型修订主导着趋势,则考虑将它们分组,使每个变更请求都代表一个更一致的工作单元。
-
您可以记录更多信息,例如一个主观的“工作类别”(“少于 1 天”、“1 天”、“少于 5 天”、“多于 5 天”)。
-
您可以记录每个变更请求的估计 SLOC 和实际 SLOC。请参阅下面的一小组度量值。
-
缺乏缺陷记录可能意味着缺乏测试。注意检验缺陷趋势时所进行的测试工作的水平。
测试进度趋势
对完整性的最终度量是功能的集成情况。
如果您的每一个开发任务都代表一组集成的功能,则一个实现价值趋势图可能就足够了。
沟通进度的一个很简单方式是使用测试进度趋势。
注意事项
有些测试用例所代表的价值或工作可能比其他测试用例大得多。不要过于看重此图 - 它只提供向完成的功能前进的某种保证。
先前描述的最小一组度量值对于许多项目来说是不够的。
软件项目管理(一个统一框架 [ROY98])建议对所有项目使用下面的一组度量值。请注意,这些度量值要求有每个变更请求的源代码行(SLOC)估计值和实际值,这需要花费一些额外的工时来收集。
度量值和原始度量值
总 SLOC
|
SLOCt = 估计的代码总计大小。当更好地理解需求时以及设计解决方案完善时,这可能会有重要更改。包括将由团队更改的重用软件。
|
配置控制下的 SLOC
|
SLOCc = 当前基线
|
关键缺陷
|
SCO0 = 0 类 SCO 的数目(其中 SCO 是“软件变更要求,Software Change Order”- 变更请求的另一种术语)
|
普通缺陷
|
SCO1 = 1 类 SCO 的数目
|
改进请求
|
SCO2 = 2 类 SCO 的数目
|
新功能
|
SCO3 = 3 类 SCO 的数目
|
SCO 的数目
|
N = SCO0 + SCO1 + SCO2
|
未结束的返工(破损量)
|
B = 由于 SCO1 和 SCO2 而累积破损的 SLOC
|
结束的返工(修订)
|
F = 累积修订的 SLOC
|
返工工时
|
E = 修订 0/1/2 类 SCO 所花费的累积工时
|
使用时间
|
UT = 给定基线一直在现实使用场景下操作的小时数
|
最终产品的质量度量值
从这一小组度量值,可以推导出一些更有趣的度量值:
碎片率
|
B/SLOCt,产品破碎百分比
|
返工率
|
E/总工时,返工工时的百分比
|
模块性
|
B/N,每个 SCO 的平均破损量
|
适应性
|
E/N,每个 SCO 的平均工时
|
成熟性
|
UT/(SCO0 + SCO1),缺陷的平均间隔时间
|
可维护性
|
碎片率/返工率,维护生产率
|
进行中的指示器
返工稳定性
|
B - F,随时间变化的破损量与修订量的比值
|
返工积压
|
(B-F)/SLOCc,当前未结束的返工
|
模块性趋势
|
模块性,随时间变化
|
适应性趋势
|
适应性,随时间变化
|
成熟性趋势
|
成熟性,随时间变化
|
要度量的事项有:
-
流程 - 为生成软件产品(和其他工作产品)而进行的一系列任务;
-
产品 - 流程的工作产品,包括软件、文档和模型;
-
项目 - 所有项目资源、任务和工作产品;
-
资源 - 可供项目调用的人员、方法和工具、时间、工时和预算。
要完全描述流程的特征,则应按最低级别的正式计划任务进行度量。任务将由项目经理使用一组初始估计值进行计划。然后应记录随时间变化的实际值,并记录所做的任何更新过的估计。
度量值
|
注释
|
持续时间
|
任务所用的时间
|
工时
|
人工单位(工作时、工作日……)
|
输出
|
工作产品及其大小和数量(请注意,这将包括作为测试活动输出的缺陷)
|
软件开发环境使用
|
CPU、存储器、软件工具、设备(工作站、PC)、耗材。请注意,这些可以由软件工程环境委员会(SEEA)针对项目来收集。
|
缺陷发现率、更正率。
|
总修复时间/工时和总报废量/返工量(其中可以度量该值)也需要收集;将可能来自针对缺陷(被视为工作产品)收集的信息。
|
变更请求不合理率、处理率。
|
关于变更请求的不合理率和处理率的时间/工时的注释。
|
可能与这些度量值有关系的其他事件(任意形式的文本)
|
这是一个度量值,它记录影响流程的事件。
|
人数、概要信息(随时间而变)和属性
|
|
人员流动
|
一种有用的度量值,可以在事后复审时说明为何一个流程运转得特别好或特别差。
|
工时应用
|
在执行所计划的活动期间花费工夫的方式(针对这些活动正式记录了成本会计管理的时间)可能有助于说明生产率的变化:例如,工时应用的一些子类为:
-
培训
-
熟悉
-
管理(例如,由团队主管)
-
行政
-
研究
-
生产性工作 - 最好按工作产品进行记录,并尝试分离“思考”时间和获取时间,尤其对于文档。这将告诉项目经理,文档编制流程强占了工程师的多少时间。
-
损失时间
-
会议
-
检查、走查、复审 - 准备和会议工时(其中有些将是独立的活动,它们的时间和工作将针对特定复审任务记录下来)
|
检查、走查、复审(在任务进行期间 - 不是单独安排的复审)
|
记录它们的数目和持续时间以及提出的问题的数目。
|
流程偏离(作为不一致情况提出,要求项目变更)
|
记录它们的数目及其严重性。这个指标表明可能需要更多培训,流程正在被误用或流程配置的方式不正确
|
流程问题(作为流程缺陷提出,要求流程变更)
|
记录它们的数目及其严重性。这在事后审查中将是有用的信息,并是对软件工程流程管理委员会(SEPA)的必要反馈。
|
Rational Unified Process(RUP)中的产品是工作产品,即文档、模型或模型元素。这些模型是类似事项(模型元素)的集合,所以此处列出的建议度量值带有它们适用的模型:通常一个度量值适用于整个模型还是适用于元素是很明显的。在不清楚之处提供了说明文本。
工作产品的特征
一般而言,我们有兴趣度量的属性如下:
-
大小 - 度量模型中元素的数目、某个元素的长度、某个元素的范围或尺寸
-
质量
-
缺陷 - 表示一个工作产品不按指定的方式执行,或不符合其规范,或具有其他不良特征
-
复杂性 - 度量结构或算法的复杂性:复杂性越大,结构越难以理解和修改,并且有证据表明,复杂的结构更可能失败
-
耦合 - 度量一个系统的元素互相连接的广泛程度
-
内聚性 - 度量元素或组件在多大程度上符合“具有良好定义的、单一用途”的需求
-
原始性 - 某个类的操作或方法可以在多大程度上根据该类提供的其他操作和方法构成
-
完整性 - 度量工作产品在多大程度上符合所有需求(声明的和暗示的需求 -
项目经理应努力尽可能明确,以限制出现无法满足的期望的风险)。此处,我们未选择区分足够和完全。
-
可跟踪性 - 表示某一级别的工作产品正在满足较低级别的需求,换个角度来看,任何级别的工作产品都有其存在理由
-
易变性 - 由于缺陷或不断变更的需求而引起的工作产品变更或不确定性的程度
-
工时 - 生成工作产品所需的工作(工时单位)的度量
只有部分特征适用于所有工作产品:在以下各表中对特定工作产品详细阐述了相关的特征。如果对一个属性列出几个度量值,那么所有度量值都可能受到关注,因为它们从几方面对该属性进行了完整描述。例如,当考虑用例的可跟踪性时,最终所有用例必须可以追溯到(经过测试的)实施模型:在过渡期,项目经理仍将它用于了解多少用例可以追踪到分析模型,作为进度的度量。
文档
建议的度量值适用于所有 RUP 文档。
特征
|
度量值
|
大小
|
页数
|
工时
|
生产、变更和修复的工时单位
|
可变性
|
变更数、缺陷数字、未结束数、已结束数;变更页数
|
质量
|
通过缺陷数直接度量
|
完整性
|
不直接度量:通过复审作出判断
|
可跟踪性
|
不直接度量:通过复审作出判断
|
模型
需求
需求属性
这实际上是一个模型元素。
特征
|
度量值
|
大小
|
-
需求的总数(= Nu+Nd+Ni+Nt)
-
要跟踪的用例数(= Nu)
-
要跟踪的设计数、实施数、仅测试数(= Nd)
-
要跟踪的实施数和仅测试数(= Ni)
-
要跟踪的仅测试数(= Nt)
请注意,这会将需求划分为将由用例建模的需求和将不由用例建模的需求。期望为:用例可跟踪性将考虑分配给用例、跟踪设计、实施和测试的那些需求。
|
工时
|
|
可变性
|
|
质量
|
|
可跟踪性
|
|
用例模型
特征
|
度量值
|
大小
|
-
用例数
-
用例包数
-
已报告的用例级别(请参阅 IBM Web 站点的白皮书:“The Estimation of Effort and Size based on Use
Cases”)
-
场景数(总数和每个用例的场景数)
-
参与者数
-
用例长度(例如,事件流的页数)
|
工时
|
|
可变性
|
|
质量
|
-
已报告的复杂性(类级别为 0-5,与 COCOMO [BOE81],相似;抽象程度越高,复杂性范围越小 - 请参阅 IBM Web 站点上的白皮书“The Estimation of Effort and Size based on Use Cases”)
-
缺陷 - 缺陷的数目,按严重性(打开的、关闭的)
|
完整性
|
-
完成的用例(经过复审、处于配置管理下并且没有未解决的缺陷)/确定的用例(或估计的用例数)
-
需求到用例的可跟踪性(在需求属性中)
|
可跟踪性
|
|
设计
分析模型
特征
|
度量值
|
大小
|
-
类数
-
子系统数
-
子系统的子系统数……
-
包数
-
每类的方法数(内部、外部)
-
每类的属性数(内部、外部)
-
继承树的深度
-
子项数
|
工时
|
|
可变性
|
|
质量
|
复杂性
|
-
类响应(RFC):这可能很难计算,因为需要一组完整的交互图。
|
结合性
|
|
内聚性
|
|
缺陷
|
|
完整性
|
|
可跟踪性
|
不适用 - 分析模型成为设计模型。
|
此处我们看到一些可能不熟悉的特定于 OO 的技术度量值 - 继承树的深度、子项的数目、类响应、对象之间的结合等。关于这些度量值的含义和历史记录的详细信息,请参阅 [HEND96]。这些度量值中有几个最初是由 Chidamber 和 Kemerer 提出的(请参阅“A metrics suite for object oriented
design”,IEEE Transactions on Software Engineering,20(6),1994),但此处我们已按照 [HEND96]
中的建议应用这几个度量值,并采用了该著作中提出的 LCOM(方法中缺乏内聚性)的定义。
设计模型
特征
|
度量值
|
大小
|
-
类数
-
设计子系统数
-
子系统的子系统数……
-
包数
-
每类的方法数(内部、外部)
-
每类的属性数(内部、外部)
-
继承树的深度
-
子项数
|
工时
|
|
可变性
|
|
质量
|
复杂性
|
-
类响应(RFC):这可能很难计算,因为需要一组完整的交互图。
|
结合性
|
|
内聚性
|
|
缺陷
|
|
完整性
|
|
可跟踪性
|
实施模型中的类数/类数
|
实施
实施模型
特征
|
度量值
|
大小
|
-
类数
-
文件数
-
实施子系统数
-
子系统的子系统数……
-
包数
-
每类的方法数(内部、外部)
-
每类的属性数(内部、外部)
-
方法大小*
-
属性大小*
-
继承树的深度
-
子项数
-
估计完成时的大小*
|
工时
|
|
可变性
|
-
缺陷和变更请求的数目
-
每个纠正性或完善性变更的破损量*,估计值(修订之前)和实际值(结束后)
|
质量
|
复杂性
|
|
结合性
|
-
子项数
-
对象之间的结合(类发散)
-
传递结合的消息(MPC)***
|
内聚性
|
|
缺陷
|
|
完整性
|
|
* 应选择某种度量代码大小的方法,然后始终如一地应用,例如无注释、无空格。关于对度量值的讨论以及将“代码行”作为度量值的应用,请参阅 [ROY98]。
另外,参阅同一参考项可了解“破损量”的定义。
** 圈复杂度的使用并没有得到普遍接受 - 尤其在应用于某一类的方法时。 关于该度量值的讨论,请参阅 [HEND96]。
*** 原出自 Li 和 Henry 的“Object-oriented metrics that predict maintainability”,J. Systems and Software,23(2),1993,在 [HEND96] 中也有所描述。
测试
测试模型
特征
|
度量值
|
大小
|
|
工时
|
-
生成测试用例等的工时单位(分别针对生产、变更和修复)
|
可变性
|
|
质量
|
-
缺陷 - 缺陷数,按严重性(打开的、关闭的);它们是针对测试模型本身提出的缺陷,而不是由测试团队针对其他软件提出的缺陷
|
完整性
|
|
可跟踪性
|
|
管理
变更模型 - 这是为使表示一致而使用的概念模型 - 这些度量值将从用于管理变更请求的任何系统中收集。
特征
|
度量值
|
大小
|
-
缺陷数、变更请求数(按严重性和状态),也分为完善性变更数、改编性变更数和纠正性变更数。
|
工时
|
|
可变性
|
|
完整性
|
-
发现的缺陷数/预测的缺陷数(如果使用了可靠性模型)
|
项目计划(软件开发计划的第 4.2 节)
这些度量是因为将实现价值技术应用于项目管理而得来的;它们一起被称为成本/时间表控制系统标准(C/SCSC)。简单的实现价值技术在上文中作为最小的一组度量值中的一部分有所描述。可以使用相关度量值执行更详细的分析,包括:
-
BCWS,已计划工作的预算成本
-
BCWP,已执行工作的预算成本
-
ACWP,已执行工作的实际成本
-
BAC,完成时的预算
-
EAC,完成时的估计
-
CBB,合同预算基数
-
LRE,最新修订估计(EAC)
以及推导出的成本变化、时间表变化的因素。关于将实现价值方法应用于软件项目管理的讨论,请参阅 [ROY98]。
项目需要在类型、大小、复杂性和正式性方面进行刻画(尽管类型、大小和复杂性通常决定了正式性),因为这些方面将决定关于较低级度量的各阈值的期望值。其他约束应包括在合同(或规范)中。从流程、产品和资源中推导出的度量值将记录所有其他项目级别的度量值。项目类型和域可以使用文本描述来记录,确保有足够的详细信息可供精确刻画项目。
按照成本、工时、工期、要开发的代码的大小、要交付的功能点记录项目大小。可以通过将该项目画在图上,显示相对于其他已完成项目的技术和管理复杂性来(有点主观地)描述项目的复杂性。[ROY98],图 14-1 显示了这样一个图。
[ROY98] 中描述的推导度量值是项目经理的主要指示器,可以从收集的产品和流程度量值中获得。 它们是:
-
模块性 = 实施模型上每个完善性变更或更正性变更的平均破损量(NCNB*)
-
适应性 = 实施模型上每个完善性变更或更正性变更的平均工时
-
成熟性 = 活动测试时间/更正性变更的数目
-
可维护性 = 维护生产率/开发生产率 = [实际累积修订数/完善性变更和更正性变更的累积工时]/[完成时的 NCNB 估计数目/完成时的估计生产工时]
-
返工稳定性 = 累积破损量 - 累积修订数
-
返工积压量 = [累积破损量 - 累积修订数]/经过单元测试的 NCNB
* NCNB 是无注释、无空格的代码大小。
应从项目计划报告进度,它使用工作产品完成度量值来表示状态:将特定权重(从挣值角度)指定给工作软件的生产。
如果使用一个估计模型,如 COCOMO(请参阅 [BOE81]),则应记录各种比例因子和成本驱动因子。它们实际上就形成了对该项目的非常详细的刻画。
要度量的项包括人员(经验、技能、成本、绩效)、方法和工具(在对生产率和质量的影响、成本方面)、时间、工时、预算(消耗的资源、剩余的资源)。
人员配备概要信息应随着时间的变化而记录,显示类型(分析人员、设计人员等)、等级(意味着成本)、和要分配到的团队。实际值和计划值都应记录。
同样,COCOMO 模型要求刻画员工的经验和能力以及软件开发环境,它是保存这些度量值的良好框架。
支出、预算和时间表信息将来自项目计划。
|