概念:度量值
度量值是用来对比较不同项或时间段的质量标准进行评测的数字。
关系
相关元素
主要描述

为什么要评测?

我们进行评测的主要目的是为了控制项目,以便能够管理项目。通过评测,我们可以评估项目在完成情况、质量情况、对需求的满足情况等方面与计划所设定目标之间的差距。

通过评测,我们还能够根据过去的经验更准确地估计新项目的工时、成本和质量。最后,我们可以通过评测评估我们是如何随着项目的进展改进流程性能一些关键方面的,以便了解变更所造成的影响。

评测项目的某些关键方面会增加不可忽略的成本。因此,不能因为我们能够进行评测便对所有方面都进行评测。我们必须对这项工作设定非常明确的目标,并且只收集那些能够帮助我们实现这些目标的度量值。

目标有两种类型:

  1. 了解情况的目标:使用动词如估计、预测、监控来表述。您要更好地了解开发流程。例如,可能要评估产品质量、获得用来预测测试工作的数据、监控测试覆盖率或跟踪需求变更等。
  2. 变更或成果目标:使用动词如增加、减少、提高或实现来表述。通常,您感兴趣的是,随着项目的进展,事情如何从一个迭代到另一个迭代、从一个项目到另一个项目发生变更或得到改进。

示例:

  • 监视计划相关流程
  • 提高客户满意度
  • 提高生产率
  • 提高可预见性
  • 提高复用性

这些一般的管理目标无法轻易地转换成度量值。我们必须将它们转换成一些更小的子目标(或操作目标),这些目标确定项目成员为实现目标必须采取的操作。而且,我们必须确保相关人员都了解这些好处。

示例

“提高客户满意度”目标可以分解为:

  • 定义客户满意度
  • 通过几次发布,评测客户满意度
  • 验证是否提高了满意度

“提高生产率”目标可以分解为:

  • 评测工时
  • 评测进度
  • 通过几次迭代或几个项目,计算生产率。
  • 比较结果

然后,部分子目标(但不是全部)将要求收集一些度量值。

示例

“评估客户满意度”可通过以下途径得到

  • 客户调查(其中客户会针对多个不同的方面打分)
  • 拨打客户支持热线电话的次数和热线电话的繁忙程度。

关于更多信息,请参阅 [AMI95]。

按组织、项目和技术需要进行分类是对这些目标进行分类的有效方法。这为上面讨论的改进措施提供了一个框架。

度量值的组织需要

在交付已知质量(客观的和主观的)的产品和相应的维护需求时,组织需要知道(并且可能降低)其单“项”成本,并缩短构建时间(推向市场的时间)。组织可能要不时地(甚至不断地)改进产品的性能,以保持竞争力。要减少风险,组织需要知道人员的技能和经验情况,并确保自己拥有其他资源和能力,以便在所选择的领域内展开竞争。组织必须能够引入新技术并确定该技术的成本效益。 下表列出了一些度量值类型的示例,这些度量值类型与软件开发组织的需要有关。

关注事项

度量值

单项成本 每行代码的成本、每个功能点的成本、每个用例的成本。每行代码、每个功能点或每个用例的标准工时(跨生命周期、编程语言、人员级别等方面的确定部分)。请注意,这些度量值通常不是简单的数字 - 它们取决于要交付系统的规模,以及是否压缩了时间表。
构造时间 每行代码或每个功能点所花费的时间。注意,这还将取决于系统的规模。还可以通过增加人员来缩短时间表 - 但不能无限制地缩短时间表。组织的管理能力将准确确定该限制。
已交付的产品中的缺陷密度 每行代码或每个功能点存在的(在交付后发现的)缺陷。
主观质量 易用性、易操作性、客户接受程度。尽管这些内容有点模糊,但已经设计了尝试进行量化的方法。
易维护性 每行代码或每个功能点每年的维护成本。
技能概要信息和经验概要信息 人力资源组可能会保存某种技能和经验数据库。
技术能力
  • 工具 - 组织应了解经常使用哪些工具,以及不常用工具的专业性程度。
  • 流程完善程度 - 例如,如果用 SEI CMM 来衡量,组织应处于什么情况?
  • 域能力 - 组织的执行能力处于哪个应用领域?
流程改进评测
  • 流程执行时间和工时。
  • 缺陷率、原因分析统计信息、修复率、报废和返工情况。

度量值的项目需要

项目在交付前必须符合以下条件:

  • 具有必需的功能和非功能性能
  • 符合各种技术约束
  • 符合预算和既定约束
  • 交付具有某些移交、可操作和维护特征的产品

项目经理必须能够判断她/他是否正在努力实现这样的目标,下表进行了详细说明,以便您在进行项目评测时考虑到相应的事项:

关注事项

项目工时和预算
  • 项目如何按照计划对工时和成本进行跟踪?
项目进度安排
  • 项目是否达到里程碑目标?
移交/安装
  • 预计工时、成本和技能需求是否可以接受?
操作
  • 客户是否支持预计工时和技能需求?
维护/可支持性
  • 对客户来说,预计工时和技能需求是否可以接受?
功能需求
  • 需求是否有效、是否完整?
  • 是否已将需求分配到迭代?
  • 是否正在按计划实现需求?
非功能需求
  • 性能
    • 系统是否满足对响应能力、吞吐量、恢复时间的需求?
  • 容量
    • 系统是否能够同时处理所需数量的用户?Web 站点是否能够处理所需每秒点击数?是否有足够的存储空间用于所需数量的客户记录?
  • 质量因素
    • 可靠性:允许的系统故障频率是多少?系统故障是什么?
    • 可用性:是否可以简单舒适地使用系统?需要多长时间才能学会如何使用系统?需要哪些技能?
    • 容错能力/强壮性/弹性/抗毁性:如果发生故障,系统是否能够继续工作?系统是否能够处理错误输入?发生故障后,系统是否能够自动恢复?
  • 专业工程需求
    • 安全性:系统是否能够在不危及生命或(有形的或无形的)财产的情况下执行操作?
    • 安全性/保密性:系统是否可以保护敏感数据免受未经授权的访问?系统是否不受恶意访问的侵入?
    • 环境影响:系统是否满足环境需求?
  • 其他法律法规方面的需求
  • 约束
    • 外部环境:系统是否能够在规定的环境中执行操作?
    • 资源、主机和目标:系统是否符合其 CPU、内存、语言、硬件/软件环境的约束?
    • 使用商品(COTS)软件或其他现有软件:系统是否满足其复用约束?
    • 人员可用性和技能:是否能提供一定数量和类型的人员来构建系统?
    • 接口支持/兼容性:系统是否能够支持对其他系统的(或来自其他系统的)必需访问?
    • 复用性:采取了什么措施使系统能够复用?
    • 强制标准:系统和开发方法是否相符?
    • 其他设计约束(例如,体系结构方面的和算法方面的):系统是否正在使用必需的体系结构风格?是否正在使用规定的算法?

以上列出了项目经理的关注事项,虽然涵盖面较广,但并非面面俱到。许多关注事项需要收集并分析度量值,有一些还需要进行特定的测试(得到评测结果)才能回答所提出的问题。

度量值的技术需要

许多项目需要将没有直接的评测指标,即使有评测指标,但应该采取什么措施或进行什么更改来完善这些指标可能并不明显。 各种高层次质量属性,如在 ISO 标准 9126(软件质量特征及度量值)中确定的质量属性和上面“项目需要”中提到的质量属性,可以和低层次的质量属性一同使用来提高质量。这些技术评测指标具有工程(结构和行为)特征和作用(涵盖流程和产品),共同构成度量值的项目级别需要。下表中的属性已用来构成一组 Rational Unified Process 工作产品和流程的度量值样本。可以在工作产品指南:度量值中找到此度量值样本。

质量

属性

需求的质量
  • 变更率:变更的频率,引入新需求的速率
  • 有效性:这些是否是合适的需求?
  • 完整性:是否缺少某些需求?
  • 表达的正确性:是否适当地表达了需求?
  • 清晰性:描述是否容易理解,是否明确?
设计的质量
  • 耦合:系统元素之间连接的程度如何?
  • 内聚:是否每个组件都有单个明确的目的?
  • 原始性:是否能够从类的其他方法或操作构建出该类的方法或操作?如果可以,则它们不是原始的(理想的特征)。
  • 完成程度:设计是否完全地实现了需求?
  • 变更率:体系结构变更的频率。
实施的质量
  • 规模:为解决问题所实施的最小规模是什么?实施是否符合约束?
  • 复杂性:在算法上,代码是否困难或复杂?是否难以理解和修改?
  • 完整性:实施是否如实地实现了所有设计?
测试的质量
  • 覆盖率:测试软件的程度如何?是否在一组测试中执行了所有指令?该测试是否覆盖了代码的多条执行路径?
  • 有效性:测试本身是否正确地反映了需求?
流程的质量(最低级别)
  • 缺陷率、缺陷原因 - 任务中的缺陷发生率是多少,原因是什么?
  • 工时和工期 - 活动需要多长时间和多少工时?
  • 生产率 - 单位工时,活动的成果是什么?
  • 工作产品的质量 - 任务输出中缺陷的程度如何?
流程/工具变更的有效性 (与流程的质量相同,仅用百分比变化表示,而不用变化总量表示):
  • 缺陷率、缺陷原因
  • 工时和工期
  • 生产率
  • 工作产品的质量

关于度量值概念的详细介绍,请参阅 [WHIT97]。

什么是度量值?

度量值分为两种:

  • 度量值是实体的可评测属性。例如,项目工时是对项目规模的评测(即度量值)。要计算此度量值,您可能需要汇总项目的所有考勤记录。
  • 原始度量值是用来计算度量值的原始数据项。在以上示例中,考勤记录是原始度量值。通常,原始度量值是数据库中存在但不应孤立解释的度量值。

每个度量值都由一个或多个收集的度量值组成。所以,必须清楚地确认每个原始度量值,明确其收集过程。

随着时间(或迭代、项目)的发展,支持变更或成果目标的度量值通常是“首先派生的”。我们感兴趣的是趋势,而不是绝对值。要“提高质量”,我们需要检查已知缺陷的剩余级别是否随着时间的推移而降低。

模板

度量值的模板

名称 度量值的名称和所有已知同义词
定义 使用该度量值评测的实体所具有的属性,如何计算度量值,以及它是从哪些原始度量值计算而来的。
目标 与该度量值相关的目标和问题的列表。以及关于收集度量值的原因的一些解释。
分析过程 打算如何使用度量值。解释度量值的前置条件(例如,其他度量值的有效范围)。目标值或趋势。要使用的分析技术和工具的模型。隐含的假设(例如,环境或模型的隐含假设)。 校准过程。存储。
职责 谁将收集并集中评测数据、准备报告并分析数据。

原始度量值的模板

名称 原始度量值的名称
定义 从项目的环境方面对度量值的明确描述
收集过程 收集过程的描述。要使用的数据收集工具和形式。收集数据时在生命周期中相应的点。要使用的验证过程。将要存储数据的位置、格式、精度。
职责 谁负责收集数据。谁负责验证数据。

度量值任务

有两种任务:

  • 确定评估计划
  • 收集评估度量值

评测计划的制定在每个开发周期中(先启阶段)一次性完成,并作为常规计划活动的一部分,或者有时作为开发案例中流程配置的一部分。像软件开发计划的其他部分一样,可以在项目进行过程中重新查看评测计划。

收集评测指标要重复进行,每次迭代至少进行一次,并且有时会更加频繁;例如,对时间长达数月的迭代要每周进行一次。

收集的度量值是“状态评估”文档的一部分,将用来评估项目的进度和状态。经过积累,它们还用于后来的整个组织的项目估计和趋势报告。

如何使用度量值?

估计

特别是项目经理需要制定计划,即根据预算和时间表将资源分配给任务。通过判断将要产生的结果来估计出工时和时间表,或者相反,即资源和时间表已经固定,需要估计的是可以产生什么结果。出于计划目的,估计常常与对基于其他因素(通常是规模和生产率)的资源需要进行的计算有关。

预测

预测与估计稍有不同,它常常与根据某些因素现在的值和其他影响因素计算这些因素的未来值有关。例如,给定性能数据的样本,如果能通过它知道(预测)在满负荷情况下、资源紧张或退化的配置中系统的性能,将十分有用。可靠性预测模型使用缺陷率数据来预测系统将何时达到某个可靠性级别。计划好某个活动后,项目经理将需要数据来预测完成时间和全部工时。

评估

评估用来确定当前位置,以便与某个阈值(或者说,趋势的标识)进行比较、在不同的备选方案之间进行比较或作为估计或预测的基础。

关于项目管理中度量值的更多信息,请参阅 [ROY98]。