RW-CL2-I-MA-B04-度量信息模型

《度量信息模型》 度量信息模型 文件编号：RW-CL2-I-MA-B04 生效日期：2004.5.20 受控编号： 密级：秘密 版次：Ver1.0 修改状态： 总页数：20 正文：17 附录：0 编制：刘峰 审核：马玉杰 批准： 北京江河瑞通技术发展有限公司 （版权所有，翻版必究） 文件修改控制 修改编号 修改条款 修改状态 修改人 审核人 批准人 修改日期 目 录 11 前言 11.1 目的 11.2 适用范围 11.3 缩略语 11.4 参考文献 12 目标 13 角色和职责 24 入口准则和输入 24.1 入口准则 24.2 输入 25 活动 25.1 信息需要描述 35.2 度量构造描述 35.2.1 属性 35.2.2 基本度量 35.2.3 派生的度量 35.2.4 指示器 35.3 实例化模型 45.3.1 物理规模和稳定性 45.3.2 里程碑完成 65.3.3 工作单元进展－软件进展 65.3.4 人员工作量 75.3.5 财务性能－获得价值 95.3.6 功能规模和稳定性 105.3.7 功能正确性－缺陷 115.3.8 功能正确性－缺陷密度 125.3.9 有效性－响应时间 135.3.10 过程符合性 135.3.11 过程有效性 145.3.12 技术适合性 165.3.13 客户反馈 176 输出和出口准则 176.1 输出 176.2 出口准则 1 前言 1.1 目的 本模型定义了具体对项目度量的执行的具体分析过程、方法以及需要注意的部分。用来指导ＭＡ活动的争正确开展。它具体规定了如下内容：项目的信息需要、度量构造和以及实例。 1.2 适用范围 本模型适用于组织的所有软件项目。 1.3 缩略语 PP 项目 PMC 项目监督和控制 MA 度量和分析 PPQA 软件质量保证 SCM 软件配置管理 SDP 软件开发计划 CMMI 能力成熟度模型集成 1.4 参考文献 《CMMI-SW V1.1》 2 目标 该模型的目的开发和维持一个度量能力。该能力用于支持项目信息需要、度量构造以及实例化度量。刚开始是集中于项目级别。不过在处理组织级或企业级信息需要、度量构造和实例化度量方面，将更加有用。 MA集成为项目的过程，其度量信息模型的目标包括： · 定义、分析信息需要； · 定义、分析度量构造； · 实例化度量分析； 3 角色和职责 度量组根据项目的规模和范围，可以由一个兼职的度量分析师或一组人构成。 角色 职责 度量分析师（度量分析组） ·制定度量分析计划； ·可能的度量分析计划的变更； ·执行度量分析具体活动； ·提交度量分析结果、数据等文档给项目经理； 4 入口准则和输入 4.1 入口准则 · 度量分析师或者度量分析组已经到位； · 软件项目计划已经得到批准； · 度量计划已经完成； · 度量分析师或者度量分析组成员接受了度量分析相关技术方面的培训。 4.2 输入 · 软件项目计划（包括PPQA计划和SCM计划等）； · 估计记录、进度表、风险评估报告等； · 资源、度量元、指示器等； · 度量计划； 5 活动 5.1 信息需要描述 度量分析的信息需要根据已建立的项目目标、问、风险和信息缺乏。其中分为下面七类： · 进度和进展：这类信息分类针对的是项目里程碑的实现以及个人工作单元的完成问题。落后于进度的项目要想按时交付，通常只能削减功能或是牺牲产品质量。 · 资源和费用：这个信息分类涉及在要执行的工作与项目分配的人力资源之间做出平衡。超出预算工作量的项目通常只能通过削减软件功能或牺牲产品质量来恢复。 · 产品规模和稳定性：这个信息分类针对功能的稳定性以及要求的软件能力。它还与提供所需能力的要交付的软件容量有关。稳定性包括功能范围或数量的变更。软件规模的增长通常要求增加所用的资源或是延长项目的进度计划。 · 产品质量：这个信息分类针对已交付的软件产品支持用户的需要而不出错的能力。若交付了低质量的产品，则使其正常运转的责任通常落在了负责维护的组织身上。 · 过程性能：这个信息分类涉及与项目需要相关的供应商的能力。缺乏软件开发过程或低生产率的供应商可能难以满足积极进取的项目进度和费用目标。 · 技术有效性：这个信息分类针对已提议的技术方法的可行性。它针对工程方法，如软件重用、商业软件组件的使用、对高级软件开发过程的依赖以及通用软件构架的实现。如果已提出的技术方法中的关键元素无法实现，那么可能导致费用的激增和进度的拖延。 · 客户满意度：这个信息分类针对项目交付的产品与服务满足客户期望的程度。满意程度的指示器可能来自客户的反馈以及所要求的客户支持的级别。 5.2 度量构造描述 [度量描述包括下面单元，在度量计划中具体用RW-CL2-I-MA-C07-度量元.xls表示] 5.2.1 可度量概念 [列出度量项目的一些可度量概念。比如要度量资源和费用的信息需要，可度量概念可以选择是人员工作量、财务性能、环境和支持资源等的可度量概念。其中同时要反应信息需要与提供的可度量概念之间的对应关系。] 5.2.2 相关的实体 [描述已定义的信息需要的数据的获取所可以通过度量的许多不同的软件过程元素和产品特性。可度量概念就是关于实体的概念。比如说资源和费用就是一个实体。] 5.2.3 属性 [描述实体的属性相关信息。属性即软件实体的可识别的特征和特性。比如实体包括过程、产品、项目和资源四个属性。但只有部分适应于度量。这里就是描述这些适应于度量的部分。] 5.2.4 基本度量 [一个基本度量是由一个指定的度量方法定义的一个单个属性的度量，当采集数据时，值被赋给基本度量。比如项目中的计划代码行数，到目前为止的累计成本。都可以作为基本度量。] 5.2.5 度量方法 [描述计算每个基本度量的计算规则的操作的逻辑顺序。一般指的是计算发生的次数或者观察时间的流逝这样的活动等。] 5.2.6 方法的类型 [分为客观度量和主管度量两种。客观度量指的是量化基于数据，比如：ada代码的行数可以通过计算分号来量化。主观度量指的是人的判断和估计。比如：专家对功能的复杂性分为高中低三类。方法的类型指的是量化特定属性的操作本身。推荐使用客观方法。] 5.2.7 刻度 [描述刻度。刻度指的是连续的或离散的值的有序集，或者是一个属性被映射到的分类集。具体实际中指的是执行度量方法产生的可能值的范围。所以一个度量单元都会有一个刻度对应。] 5.2.8 刻度的类型 [说明：描述刻度上值之间关系的类型。可以是以下类型： · 比率——数字数据，相同的间距对应于相同的属性量，数值0不对应任何属性。代码行的计算会产生从0到无穷大的取值范围。 · 间隔——数字数据，相同的间距对应于相同的属性量，不使用0。圈复杂度（Cyclomatic complexity）（通过一个软件组件的逻辑路径的数量）提供了一个间隔刻度，因为最小的可能取值是1。 · 序号——离散的等级排列（ranking）。例如，一组软件单元可能会根据预期的实现难度排序：最困难（most difficult）和很困难（second most difficult）等等。 · 标称——分类的数据。例如，一组问题报告可能根据问题的来源分类：需求和设计等等。] 5.2.9 刻度的单位 [描述用于导出基本度量值的化的定量的数量。比如：一小时或一行代码。] 5.2.10 派生的刻度 [描述由两个或多个度量的值导出的度量。] 5.2.11 度量的函数 [描述用于计算派生的度量的公式。] 5.2.12 指示器 [用图形或者图表方式显示一个或者多个度量（基本或派生的）。] 5.2.13 分析模型 [描述应用决策准则包括两个或多个基本或者派生的度量的算法或计算。] 5.2.14 决策准则 [用来解释度量结果的数字阈值、目标和界限。具体描述的话，决策准则可能来源于历史数据、计划和直观判断或者作为统计控制界限或统计置信界限被计算。] 5.3 实例化模型 模型中具体度量分析的内容，包括：物理规模和稳定性、里程碑完成、工作单元进展－软件设计进展、人员工作量、财务性能－获得价值、功能规模和稳定性、功能正确性－缺陷、功能正确性－缺陷密度、有效性、过程符合性、过程有效性、技术合适性、客户反馈几个方面。 5.3.1 物理规模和稳定性 评估原始规模估计的充分性，以便评估进度和成本问题。 具体度量分析实体如下： 信息需要 评价一个软件组件的规模来评估原始的预算估计 信息分类 产品规模和稳定性 可度量概念 物理规模和稳定性 指示器 软件规模增长趋势 分析模型 软件规模增长率的增加表明达到成本和进度预算的风险的增加 决策准则 如果规模增长率超过1.2，则应该进行调查 派生的度量 软件规模增长率 度量函数 将迄今为止完成的实际代码行除以计划的代码行 基本度量 1、 计划的软件源代码行数 2、 实际的软件源代码行数 度量方法 1、计算到当前时期为止计划完成的累计代码行数 2、计算在目前已批准的软件源代码库中的源代码行数 方法类型 1、 客观的 2、 客观的 刻度 1、 从0到无穷大的整数 2、 从0到无穷大的整数 刻度的类型 1、 比率 2、 比率 度量单位 1、 源代码行 2、 源代码行 相关实体 1、 软件开发计划或进度 2、 基线化的软件源代码库 属性 1、 在每个时期计划完成的代码行数 2、 软件源代码行数 5.3.1.1 分析指导 在代码生产中代码增长和进展延迟都是工作量和进度滞后的主要指示器，因此在整个开发过程中应该严密监控代码增长。 · 过度增长的分析可以揭示范围变更、未满足关于商用产品的重用或使用的技术假设或者过低估计代码量。 · 延迟的进展分析可以揭示变更的需求、人员配置不足或者比计划更低的生产率。人员配置不足的分析应该考虑返工、并行分配、非项目时间和程序员生产率。 5.3.1.2 实现考虑 分析代码增长和稳定性时考虑： · 多种语言开发； · 可重用的代码、已生成的代码、已修改的代码和新代码以及这些代码源或分组； 实际操作过程中考虑：规模数据通常在一个项目的编码和测试阶段采集。数据至少每月收集一次。配置工具提供一个好的手段获取实际的代码行。一个配置经理或者软件组长负责收集和报告这个信息。数据通常通过配置管理记录或一个电子数据表（RW-CL2-I-MA-C01-物理规模和稳定性.xls）收集。所用的聚集结构一般是组件。 5.3.2 里程碑完成 用来评价关键开发活动和事件的进度、进展和依赖关系。项目经理需要客观地按项目计划评估开发的进展。这个信息需要通过度量所有里程碑的总的延迟天数来处理。 里程碑完成度量完整的度量构造如下： 信息需要 评价关键的开发活动和事件的进度、进展和依赖关系 信息分类 进度和进展 可度量概念 里程碑性能（监督在整个项目过程中一个项目的里程碑完成的状态） 指示器 里程碑进度差异 分析模型 比较相对于总进度的进度差异 决策准则 如果进度差异超过10%，则需要进行调整。必要的话，重计划进度 派生的度量 1、 总的延迟天数 2、 进度差异 度量函数 1、 为所有里程碑增加延迟天数 2、 将总的延迟天数除以总进度长度 基本度量 1、 一个里程碑的延迟天数 2、 总进度长度 度量方法 1、 对于每个里程碑，从实际开始日期减去计划开始日期 2、 从最近的计划结束日期减去最早的计划开始日期 方法类型 1、 客观的 2、 客观的 刻度 1、 从0到无穷大的整数 2、 从0到无穷大的整数 刻度的类型 1、 比率 2、 比率 度量单位 1、 天 2、 天 相关实体 1、 里程碑进度计划 2、 里程碑进度报告 属性 1、 在项目进度计划中的里程碑日期 2、 里程碑实际到达的日期 5.3.2.1 分析指导 在可行性分析期间，应该评价每个活动的开始和结束日期，确保它们是合理的，假定要生成多少代码量和应用多少工作量。评价应该包括一次评估，该评估包括所有活动在内，什么活动影响键关键路径，以及各种活动之间的重叠量。计划变更的分析应该包括评估对未来活动变更的影响。如果多个发布或构造被计划，那么应该为每个发布或构造定义独立的活动和里程碑。 在性能分析期间，人员配置等级、在一个特定活动或任务内的工作单元进展以及缺陷率的分析可以帮助标识进度拖延的原因。最需要高度关注的是在关键任务上的活动和里程碑中的拖延，因为这些拖延直接影响最终交付的进度。 5.3.2.2 实现考虑 这个进度度量通常在整个项目期间收集和报告。数据收集和报告的职责通常分配给为项目经理工作的一名支持人员。报告至少每月一次；对于较小的、较短的而且数据能按周收集的项目，可能每周一次。对于每个可交付的软件产品来讲，所用的聚集结构通常是组件；对于每个项目活动和任务，所用的聚集结构通常是活动。 对于进度差异超过决策准则（比如决策准则定位10%）所规定的界限，因此应该调查延迟的原因。如果有必要的话，应该重新计划更现实的进度。 里程碑完成度量可以用RW-CL2-I-MA-C02-里程碑完成。 5.3.3 工作单元进展－软件设计进展 这个度量实例用于客观地评估软件设计活动的进展。这个信息需要通过按已定义的出口准则度量某个软件组件或单元的设计的完成量来处理。 完整的度量构造如下： 信息需要 评价软件设计活动的状态 信息分类 进度和进展 可度量概念 工作单元进展 指示器 设计完成量 分析模型 以图表画出随时间完成的设计。设计完成量的值达到100%时关闭 决策准则 90%或更少的设计完成结果或者在设计完成中3次连续的下降，应该进行调查 派生的度量 已完成的设计包的百分比 度量函数 将总的已完成的设计单元数除以估计的单元数 基本度量 1、 每个周期计划的设计单元数 2、 已经完成设计的设计单元数 度量方法 1、 到目前为止计划的设计单元的累计数 2、 在配置管理下的已批准的设计单元的统计数 方法类型 1、 客观的 2、 客观的 刻度 1、 从0到无穷大的整数 2、 从0到无穷大的整数 刻度的类型 1、 比率 2、 比率 度量单位 1、 设计单元 2、 设计单元 相关实体 1、 设计包计划或进度 2、 已完成的和已批准的设计单元的配置管理记录 属性 1、 已计划的设计单元 2、 设计单元的状态 5.3.3.1 分析指导 作为可行性分析过程的一部分，应该评审计划的进展比率，确保它是合理的且通常不是急剧升降的。另外，应该检查计划，确保它反映了系统的估计的单元总数。 在性能分析期间，除了使用决策准则外，任何实际进展比率的主要变更，都应该调查根源。一旦建立了一条实际的趋势线，要修改完成的比率就比较困难了，除非采取纠正行动或改变过程。还有，当实际进展落后于计划进展时，通常需要更详细的分析。例如，分析子系统的进展有助于标识哪些组件总是落后于进度。人员配置等级、经验水平、变更的范围和质量问题是影响进展的主要原因，应该加以调查。 5.3.3.2 实现考虑 工作单元进展度量通常只是为一个特定的项目时间周期（即在设计正被开发期间）收集和报告的。报告至少每月一次；对于较小的、较短的而且数据能按周收集的项目，可能每周一次。要度量的工作单元的“所有者”（即设计者）通常负责数据交付。所用的聚集结构通常是组件。 工作单元进展－软件设计进展度量可以用RW-CL2-I-MA-C03-工作单元进展.xls完成 5.3.4 人员工作量 用来评估是否有足够的人力资源来按进度完成项目。这个信息需要通过与计划比较度量应用到项目的人员数来处理。对于这个度量，假定原始的人员配置计划是足够的。 完整的度量构造如下： 信息需要 确定人力资源是否足以满足项目委托 信息分类 资源与成本 可度量概念 人员 指示器 人员配置差异 分析模型 实际与计划的人员比例应该接近100% 决策准则 如果人员配置差异超过+/-15%，应该进行调整 派生的度量 人员配置差异 度量函数 对每个报告周期，将实际的人员数除以计划的人员数 基本度量 1、 计划的人员数 2、 实际指派的人员数 度量方法 1、 计算项目中每个人员分类的计划的职位数 2、 计算满足每个人员分配的人员数 方法类型 1、 客观的 2、 客观的 刻度 1、 从0到无穷大的整数 2、 从0到无穷大的整数 刻度的类型 1、标称 2、比率 度量单位 1、 人 2、 人 相关实体 1、 人员配置计划 2、 人员目录 属性 1、 已分配给项目的（或没有） 2、 已指派给项目的（或没有） 5.3.4.1 分析指导 人员配置的定期监督可以在早期指出可能的进度延迟和资源可用性问题。在分析人员配置问题和寻找人员配置为什么无法遵循计划时，应该考虑要执行工作的范围、人员经验、任务分配、进度、质量问题和返工。当构造、迭代或阶段完成时，跟踪工作量花在什么地方也是有用的。这个分析可能指出在项目的早期阶段所花的时间不够。应该全面考虑这类问题的影响，因为经常要在后期阶段花额外的时间来处理遗漏的需求，解决可能导致质量问题和进度延迟的缺陷。 在可行性分析期间，应该评价开发活动的工作量分配是否充足。在许多项目中，需求和设计活动是被低估的。工作量分配还应该与计划的活动比较，确保当出现多个活动时有充足的资源可用。 评价累计的差异也是重要的。如果实际数据很长一段时间都低于计划数据，那么通常很难修正。应该监控工作量数据的变化率，因为大量的人员不可能在短期内有效地增加。集成和测试期间的超量工作预示着代码的质量问题和可能延期完成的重大缺陷。 5.3.4.2 实现考虑 在整个项目期间应该监控人员配置，并且至少每个月报告一次。项目经理或人事经理通常负责收集和报告。数据一般来自员工的月报。所用的聚集结构是活动。 人员工作量度量可以用RW-CL2-I-MA-C04-人员工作量。 5.3.5 财务性能－获得价值 用来评估获得价值性能信息。这个信息需要是通过将执行工作的预算和实际成本与计划的工作的预算成本进行比较来处理的。 完整的度量构造如下： 信息需要 确定项目是否按时和在成本范围内完成了计划的活动 信息分类 资源与成本 可度量概念 财务性能 指示器 成本和进度性能 分析模型 SPI（进度性能指标）和CPI（成本性能指标）应该同时接近0。负的结果表明项目落后于进度或超出预算成本。正的结果说明项目比进度提前或低于预算成本 决策准则 如果SPI或CPI超出+/-15%，应该进行调查 派生的度量 1、 进度性能指标（SPI） 2、 成本性能指标（CPI） 度量函数 1、 SPI=（BCWP-BCWS）/BCWS 2、 CPI=（BCWP-ACWP）/ACWP 基本度量 1、 本月计划的工作的累计预算成本（BCWS） 2、 本月计划的工作的累计实际成本（ACWP） 3、 本月已完成的工作的累计预算成本（BCWP） 度量方法 1、 将每个月中所有的工作预算相加 2、 将所有的实际月花费相加 3、 将所有的计划完成和该月实际完成的工作包的预算相加 方法类型 1、 客观的 2、 客观的 3、 客观的 刻度 1、 从0到预算限制的整数 2、 从0到无究大的整数 3、 从0到预算限制的整数 刻度的类型 1、 比率 2、 比率 3、 比率 度量单位 1、 美元 2、 美元 3、 美元 相关实体 1、 原始的成本估计报告 2、 定期的成本核算报告 3、 定期的成本核算报告 属性 对于每个工作包/WBS元素： 1、 每个月的预算成本/成本估计 2、 每个月的实际花费 3、 与实际费用相关的预算成本 5.3.5.1 分析指导 大的成本或进度差异应该尽可能早地调查，以便尽快确定必须解决的问题。当评审SPI和CPI度量时，需要标识进度和成本问题的基本原因。进一步的分析揭示了诸如不可行的计划、范围变更或缺乏可用的人员、工具或设施之类的问题。 如果重计划了财务性能基线，那么要记录先前的数据，以便将变更的理由和对早先差异的原因的洞察文档化。 5.3.5.2 实现考虑 度量BCWP（已执行工作的预算成本）有各种方法，包括二进制（一个包要么按其预算的0%计算，要么按100%计算）、里程碑分配和完成百分比（0%到50%到100%）。应该先于项目执行选择和同意该方法。应该使用客观的出口准则。 获得价值应该在整个项目期间得到监控，并且每月至少报告一次。项目或成本核算经理通常负责报告。数据一般通过月核算报告提供。所用的聚集结构一般要么是组件，要么是活动。 财务性能－获得价值度量可以用RW-CL2-I-MA-C05-财务性能-获得价值完成。 5.3.6 功能规模和稳定性 用来评估对需求的变更，以便评价潜在的进度和成本问题。这个信息需要是通过评价已添加、已修改和已删除的需求与基线需求数的比率来处理的。 完整的度量构造如下： 信息需要 评价在增加进度和预算的情况下项目可以处理的需求易变量 信息分类 产品规模和稳定性 可度量概念 功能规模和稳定性 指示器 1、 需求稳定性 2、 按变更类型的需求稳定性 分析模型 在需求评审后有些增长是期望的。少量的需求变更是期望的，而且能够适应 决策准则 如果需求总数的增长超过10%或者在某个月的变更超过当前基线的10%时，就要进行调查 派生的度量 1、 总的计划的需求 2、 需求变更 3、 需求稳定性 度量函数 1、 通过将基线需求相加计算总的计划的需求，并计算已增加的、已修改的和已删除的需求数 2、 通过将已增加的、已修改的和已删除的需求数相加计算需求变更 3、 将需求变更除以基线化的需求 基本度量 1、 基线需求数 2、 已增加的需求数 3、 已修改的需求数 4、 已删除的需求数 度量方法 1、 计算初始基线中的需求数 2、 将所有已批准的变更请求所增加的需求数相加 3、 将所有已批准的变更请求所修改的需求数相加 4、 将所有已批准的变更请求所删除的需求数相加 方法类型 1、 客观的 2、 客观的 3、 客观的 4、 客观的 刻度 1、 从0到无究大的整数 2、 从0到无究大的整数 3、 从0到无究大的整数 4、 从0到无究大的整数 刻度的类型 1、 比率 2、 比率 3、 比率 4、 比率 度量单位 1、 需求 2、 需求 3、 需求 4、 需求 相关实体 1、 需求基线 2、 已批准的变更请求——已增加的需求 3、 已批准的变更请求——已修改的需求 4、 已批准的变更请求——已删除的需求 属性 1、 总的需求 2、 来自变更请求的已增加的需求 3、 来自变更请求的已修改的需求 4、 来自变更请求的已删除的需求 5.3.6.1 分析指导 需求增长和/或需求易变性通常是成本和进度增加的主要指示器。对需求增加和变更的类型和原因应该进行额外的分析。需求变更可以按受影响的领域（如系统接口、用户界面、性能或关键功能）或者原因（如遗漏、不清晰、不完整或不正确）来分类。更多地了解变更有助于项目经理评估变更对成本和进度的影响。 5.3.6.2 实现考虑 需求增长和/或稳定性应该在整个项目期间，需求一经基线化就开始跟踪，因为进行估计和制定计划都是以基线化的需求为基础。收集和报告应该按月进行。自动化包括一个需求管理工具/数据库和一个变更请求系统，对于获得这些度量是非常有帮助的。配置经理、系统工程或需求小组长通常负责需求有关的报告。所用的聚集结构通常是组件。 功能规模和稳定性度量可以用RW-CL2-I-MA-C06-功能规模和稳定性完成。 5.3.7 功能正确性－缺陷 用来评估系统是否准备好进行用户验收测试。在用户验收测试的入口准则中，所有严重度为1的缺陷应该在这个测试开始之前关闭。少量较低严重度的缺陷是允许的。因此，在这个度量中只考虑严重度为1的缺陷。 完整的度量构造如下： 信息需要 通过在产品中的严重度为1的缺陷数来评价产品质量和发布是否准备就绪 信息分类 产品质量 可度量概念 功能正确性 指示器 严重度为1的缺陷的状态——随时间跟踪严重度为1的缺陷数 分析模型 严重度为1的缺陷使产品不可用 决策准则 推迟交付，除非打开的严重度为1的缺陷数为0 派生的度量 每个周期打开的严重度为1的缺陷数 度量函数 对于所有严重度为1的缺陷，从每周期新的累计缺陷数中减去已关闭的累计缺陷数 基本度量 1、 这个周期已报告的新的严重度为1的缺陷数 2、 这个周期已关闭/已解决的严重度为1的缺陷数 度量方法 1、 计算已打开的严重度为1的缺陷 2、 计算这个周期已关闭的严重度为1的缺陷 方法类型 1、 客观的 2、 客观的 刻度 1、 从0到无究大的整数 2、 从0到无究大的整数 刻度的类型 1、 比率 2、 比率 度量单位 1、 缺陷 2、 缺陷 相关实体 软件缺陷报告 属性 缺陷的分类和状态 5.3.7.1 分析指导 打开的缺陷表示剩余的工作（返工），而缺陷趋势有助于深入了解产品成熟度。当打开的缺陷数太多时，除了表明质量问题外，这是一个从与这些打开的缺陷相关的返工导致的后来的预算和工作量超出限度和进度延迟的主要指示器。另外，当分析这些度量时，进展和符合性度量也应该评审，因为进展不足（如缺少测试进展）和跳过测试步骤可能导致打开的缺陷的明显下降趋势。 为了更好地理解一个项目已暴露的缺陷，可以按位置（location）和类型（如逻辑、接口和数据）来执行Pareto缺陷分析。这有助于找出最常见的缺陷原因，而且通过减少或消除将来类似缺陷的出现可以潜在地改进产品质量。 可以用平均每周关闭率和发现率来定量地预测项目是否为发布做好了准备。 5.3.7.2 实现考虑 应该使用一个单一的、公共的缺陷跟踪系统来在整个项目生命周期过程中跟踪缺陷。测试经理、QA经理或软件负责人通常负责缺陷度量。缺陷状态至少按月报告，可能的话，按周报告，特别是在测试阶段。配置管理报告通常包含了缺陷率。所用的聚集结构通常是组件。 功能正确性－缺陷度量可以用RW-CL2-I-MA-C08-严重度为1的缺陷完成。 5.3.8 功能正确性－缺陷密度 通过监督代码审查过程和从审查产生的缺陷率来评价代码质量。每个审查包大约是1000行代码。 完整的度量构造如下： 信息需要 通过监督代码审查过程和从审查产生的缺陷率来评价质量 信息分类 产品质量 可度量概念 功能正确性 指示器 代码审查缺陷密度控制图 分析模型 使用一个控制图来监督缺陷密度并从历史数据计算控制界限。低于或高于通常的缺陷密度可能表明产品质量或过程有问题 决策准则 调查任何其值低于或高于控制界限的失控状况，并采取纠正措施 派生的度量 缺陷密度 度量函数 将发现的缺陷除以代码行 基本度量 1、 实际发现的缺陷数 2、 实际的代码行数 度量方法 1、 计算代码审查期间发现的缺陷 2、 计算已评审的代码行 方法类型 1、 客观的 2、 客观的 刻度 1、 从0到无究大的整数 2、 从0到无究大的整数 刻度的类型 1、 比率 2、 比率 度量单位 1、 缺陷 2、 代码行 相关实体 1、 代码审查缺陷报告 2、 软件规模 属性 1、 缺陷的分类 2、 已评审的工作产品的产品规模 5.3.8.1 分析指导 通过跟踪来自设计和代码审查的缺陷，可以获得产品质量的早期指示器。使用控制图来监督产品质量有助于项目经理监督缺陷排除过程的“稳定性”。当出现“失控”或不稳定条件时，应该加以调查并确定差异的可分配的原因（assignable cause）。如果不处理这些情况，项目就可能继续处于不稳定和不可预测的状况之中，并且最终可能产生比计划更多的缺陷或使用更多的资源。 低缺陷率可能是因为过程没有正确地被执行，缺乏评审或审查准备，或者仅仅高于通常的软件质量则归因于花在审查中的时间过多、使用富有经验的人员或者进行额外培训。较高缺陷率的代码审查表明一次卓有成效的审查过程或严重的质量问题，在这种情况中，代码要进行额外的审查和测试。 5.3.8.2 实现考虑 应该使用来自同行评审、审查和测试的度量来在整个生命周期中跟踪缺陷密度。测试经理、QA经理或软件负责人负责缺陷度量。控制图要在每次审查或测试事件后评审。所用的聚集结构通常是组件。 功能正确性－缺陷密度度量可以用RW-CL2-I-MA-C09-缺陷密度完成。 5.3.9 有效性－响应时间 用于评价响应时间，以便评价系统是否满足规定的响应时间需求。 完整的度量构造如下： 信息需要 通过度量满足系统时间需求的能力来评价软件的质量 信息分类 产品质量 可度量概念 有效性 指示器 响应时间 分析模型 响应时间应该少于要交付的合同需求 决策准则 任何超过合同需求的响应时间应该得到评价，以便加以改进 派生的度量 无（None） 度量函数 无（None） 基本度量 1、 合同需求——10秒 2、 每种功能类型（查询，更新）的实际响应时间 度量方法 1、 标识合同需求 2、 计算每种功能类型（查询，更新）从提交到响应的时间 方法类型 1、 客观的 2、 客观的 刻度 1、 从0到无究大的整数 2、 从0到无究大的整数 刻度的类型 1、 比率 2、 比率 度量单位 1、 秒 2、 秒 相关实体 系统测试报告 属性 响应时间 5.3.9.1 分析指导 当比较不同的系统时，硬件、通信和数据库技术应该是相似的，确保历史数据是可比较的。当结果超出了可接受的范围时，更详细的按组件或事务来分析有助于标识问题。 不应该期望系统之间大的响应时间下降，除非技术或功能有了重大的变更。新的系统的性能可以用模拟和仿真技术来预测。 为响应时间度量选择基于特定准则的功能，如功能相似性、危险程度或使用的频率。另外，要将响应时间数据（平均的、采样的或最坏情况）的格式与计划或目标图做比较。可能影响实际响应时间度量的有效性的因素包括（1）在测试期间不能仿真在目标机上的有效负荷，（2）无法试验有代表性的功能，（3）无法仿真一个预期的可操作性剖析图的典型负荷，和（4）使用一个比可操作性版本小的测试数据库。 5.3.9.2 实现考虑 从设计阶段起，响应时间就应该被跟踪。应该用设计和实际阶段的模拟和仿真数据、集成和测试阶段及操作和维护期间的实际数据来进行跟踪。 测试经理或软件负责人通常负责响应时间分析和报告。数据一般是从测试日志或问题报告系统中获得。所用的聚集结构通常是组件。 有效性－相应时间度量可以用RW-CL2-I-MA-C10-响应时间完成。 5.3.10 过程符合性 按能力成熟度模型集成化系统/软件工程模型（CMMI）评价组织的软件开发能力。这个度量可以帮助评价一个组织的过程改进效果或确定一个组织的当前过程性能。 完整的度量构造如下： 信息需要 评价软件开发过程与标准模型、方针或规程的一致性 信息分类 过程性能 可度量概念 过程符合性 指示器 组织成熟度评定 分析模型 将肯定的响应数与参考模型的准则比较，并分配一个评定等级 决策准则 如果评定等级自最后一次报告以来在下降，则应该进行调查 派生的度量 无（None） 度量函数 无（None） 基本度量 肯定的响应数（positive responses） 度量方法 计算标准化参考模型中每一项的正的响应数 方法类型 客观的（单上的响应是主观的） 刻度 从0到调查问卷总项数的整数 刻度的类型 比率 度量单位 调查问卷项 相关实体 1、 组织软件开发过程的关键实践的文档 2、 参考模型调查问卷 属性 满足的调查问卷项 5.3.10.1 分析指导 整个参考模型评定为管理过程改进提供了有限洞察。维护一个要处理的详细的模型实践列表提供了一个更好的进展指示器。 过程成熟度成绩的可靠性取决于评估过程的严格性。一个高成熟度成绩并不能保证成功的开发。项目约束可以严重影响一个组织实现已定义的过程的能力。 5.3.10.2 实现考虑 应该使用参考模型评价报告的数据来跟踪所有软件开发活动的过程符合性。评估小组组长或过程改进（PI）负责人通常负责数据的收集和报告。无论评估何时进行（一般是每隔6个月到1年），数据总要被收集。所用的聚集结构通常是组织。 过程符合性度量可以用RW-CL2-I-MA-C11-过程符合性完成。 5.3.11 过程有效性 通过比较已达到的生产率与投标率（bid rates）来评价软件开发过程的效果。对于这个项目来讲，只有编码阶段期间的代码生产率被评价。 完整的度量构造如下： 信息需要 评价软件开发过程的有效性 信息分类 过程性能 可度量概念 过程有效性 指示器 项目的平均生产率趋势 分析模型 降低工作中心的生产率趋势要求管理评估 决策准则 三个月生产率的连续下降要求评价项目，确保与组织的已定义过程符合 派生的度量 项目的生产率 度量函数 将项目中产生的代码行除以每周期花在项目中的工作小时 基本度量 1、 （来自合同的）生产率投标率 2、 在一个周期中报告的总的工作小时数 3、 在一个周期中产生的源代码行数 度量方法 1、 计算来自合同的生产率投标率（基于已完成项目的历史数据） 2、 为每个软件产品的累计工作小时数增加一个计时卡（timecard）条目 3、 为每个软件产品计算置于配置控制之下的源代码行数 方法类型 1、 客观的 2、 客观的 3、 客观的 刻度 1、 从0到无穷大的实数 2、 从0到无穷大的实数 3、 从0到无穷大的实数 刻度的类型 1、 比率 2、 比率 3、 比率 度量单位 1、 每个工作小时SLOC数 2、 工作小时数 3、 源代码行数 相关实体 1、 历史的生产率 2、 员工计时卡 3、 配置管理报告 属性 1、 每工作小时的历史SLOC 2、 特定软件产品的劳动工作量计时卡条目（timecard entries of labor effort） 3、 在一个已批准的软件产品基线中的源代码行数 5.3.11.1 分析指导 生产率提供了一个相对于所花工作量而产生的总的工作量的指示。低于期望的生产率可以导致工作量和成本超出范围。学习曲折性（Learning curve）、需求易变性、人员配置变化/流动（turnover）和不可预测的产品复杂性是影响生产率的所有因素。使投标率（bid rate）基于过去的历史项目的性能（类似项目）总是有用的。 5.3.11.2 实现考虑 生产率在整个编码过程中应该加以监控。可以在每个增量式构造结束或为一次临时发布按月加以分析。软件经理通常负责分析和报告生产率。工作量数据通常是从工资记录（payroll records）中收集，而规模数据通常是从配置管理报告中收集。所用的聚集结构对工作量度量来讲通常是活动，而对规模度量来讲则是组件。生产率通常按整个组织等级来分析的（很难在一个详细的工作包等级进行分析）。 过程有效性度量可以用RW-CL2-I-MA-C12-过程有效性完成。 5.3.12 技术适合性 用来评价软件包满足客户期望和需求的能力，并在测试用例中文档化。由于系统已经交付，因此100%的测试用例必须通过。 具体度量构造如下： 信息需要 评价软件包满足客户期望的能力 信息分类 技术有效性 可度量概念 技术适合性 指示器 需求覆盖 分析模型 在测试结束时需求覆盖应该是100% 决策准则 软件不能交付，除非100%的需求按测试用例执行 派生的度量 1、 已通过的百分比 2、 已失败的百分比 3、 已冻结的百分比 4、 未验证的百分比 度量函数 1、 将已通过的测试用例数除以总的测试用例数 2、 将已失败的测试用例数除以总的测试用例数 3、 将已冻结的测试用例数除以总的测试用例数 4、 从总的测试用例数中减去已通过的加已失败的加已冻结的测试用例数，再除以总的测试用例数 基本度量 1、 总的测试用例 2、 已通过的测试用例 3、 已失败的测试用例 4、 已冻结的测试用例 度量方法 1、 计算测试计划中已标识的测试用例数 2、 计算已通过的测试用例数 3、 计算已失败的测试用例数 4、 计算已冻结的测试用例数 方法类型 1、 客观的 2、 客观的 3、 客观的 4、 客观的 刻度 1、 从0到无穷大的整数 2、 从0到无穷大的整数 3、 从0到无穷大的整数 4、 从0到无穷大的整数 刻度的类型 1、 比率 2、 比率 3、 比率 4、 比率 度量单位 1、 测试用例 2、 测试用例 3、 测试用例 4、 测试用例 相关实体 1、 测试计划 2、 测试结果报告 属性 1、 已计划的测试用例 2、 测试用例状态（已通过的，已失败的，已冻结的） 5.3.12.1 分析指导 需求覆盖指示器有助于评价将通过一个或多个专门的技术来处理的功能的总数，如软件包、硬件或其他商用组件。在有些情况下，当问题产生时，可以重新进行分配。与这个度量有关的一个问题是在实现的复杂度、范围和工作量方面同等看待每一个需求。需要进行特定需求的附加分析，以便当计划准备实现的需求或当考虑重分配需求时，确定工作量、成本和进度影响。 5.3.12.2 实现考虑 需求覆盖通常在关键测试活动期间得到监控。可以每月或每周进行分析。测试经理一般负责分析和报告这个信息。数据通常从测试记录或电子表格获得。所用的聚集结构通常是组件。 过程适应性度量可以用RW-CL2-I-MA-C13-技术有效性完成。 5.3.13 客户反馈 用一个已交付的产品的增量式版本评价客户满意程度。要评价高的不满意程度的根本原因，并制定决策来确定是否需要新的产品版本。 具体的度量构造如下： 信息需要 评价当前产品的客户满意程度 信息分类 客户满意程度 可度量概念 客户反馈 指示器 按调查问题的不满意意见 分析模型 必须评价高的不满意度的根本原因 决策准则 任何不满意评定等级超过10%的调查问题都必须调查根本原因并确定是否需要发布新的产品 派生的度量 1、 每个调查问题的总的反应 2、 满意的反应的百分比评定 3、 不满意的反应的百分比评定 度量函数 1、 增加新的客户反应数 2、 将满意的客户反应数除以总的反应数 3、 将不满意的反应数除以总的反应 基本度量 每个产品版本的满意和不满意的客户反应数 度量方法 计算来自客户报告的满意和不满意的评论数 方法类型 主观的 刻度 满意和不满意的评定等级 刻度的类型 标称 度量单位 客户评论数 相关实体 收到来自客户的反馈报告 属性 计算每个调查问题的正反两方面的客户反馈评定数 5.3.13.1 分析指导 在项目的整个生命周期中定期地使用，这个指示器将测量客户满意度的变更。客户可能已经对需求满意，但可能不相信进行中的工作会足以实现这些需求。在调查结果中的变更将及时揭示这类问题，以获得附加的客户反馈来理解和处理他们关注的问题。 如果使用一次调查来处理对一个原型的满意度（如人机接口），那么结果可以帮助确定一个建议的接口是否是一个可行的设计。 在调查指示器不满意且只有一个客户的情况下，客户和出资方代表可以一起讨论不满意的起因。当有多个客户时，有时用中心小组（focus group）来提供额外的数据。 5.3.13.2 实现考虑 设计一个有效的调查工具并在实现一次客户满意调查之前预先调查是重要的。如果工具设计得正确的话，可以在整个项目生命周期中使用调查。 这个度量通常在一个软件产品交付后的操作和维护期间进行收集。这个度量的收集和报告频率一般比多数其他项目来得少（通常是一个季度或半年或与产品发布一起进行），而且数据一般是通过客户评论表格提供。市场经理通常负责报告这个信息。所用的聚集结构通常是已交付的软件组件。 客户反馈度量可以用RW-CL2-I-MA-C14-客户反馈完成。 6 输出和出口准则 6.1 输出 · 度量计划 · 度量构造 · 度量信息模型 · 财务性能-获得价值 · 工作单元进展 · 功能规模和稳定性 · 过程符合性 · 计划的修订数 · 技术适合性 · 客户反馈 · 里程碑完成 · 缺陷密度 · 人员工作量 · 物理规模和稳定性 · 需求易变性 · 严重度为1的缺陷 · 组件进展指示器 6.2 出口准则 · 依照度量计划，度量分析项目信息 · 必要时，已采用集成化分析模型 · 及时与项目相关人员沟通、提出建议 · 已度量和记录了反馈给项目经理 · 高层经理、项目经理和相关人员及时收到有关度量分析的信息