质量体系解读之度量与分析
金融SQA毛曦
说起项目过程中的度量与分析，也许很多同事都认可这一过程的重要性，但真正在项目过程中开展度量分析活动，却少之又少。
项目经理往往受限于项目进度、工作精力和能力局限，无法在项目过程中开展行之有效地度量与分析。
本文根据质量体系中的《度量与分析规程》，以及《度量使用指南》，结合项目实际，采用Q&A形式，对度量与分析进行简明扼要的解读说明。
Q1：度量分析目的何在，项目中有哪些人参与？
A1：度量分析的目的是开发和维持一个用于支持项目信息需要的度量能力。
在项目过程中，一般来说，PM或QA负责项目数据的整体的度量和分析工作，项目组成员参与提供度量数据活动。
Q2：度量和分析整体实践流程是怎样的？
A2：度量和分析整体实践流程有如下流程：
●确立度量目的
●详细说明度量方法
●详细说明数据采集和存储规程
●详细说明分析规程
●采集度量数据
●分析度量数据
●存储数据和结果
●交流结果
Q3：通常有哪些使用度量的例子？
A3：项目过程中，常见的的使用度量的例子有以下几种：
●挣值(EV)
●进度性能指标(SPI)
●缺陷密度
●同行评审覆盖率
●测试或验证的覆盖率
●可靠性度量,比如平均故障间隔时间
●质量度量,比如严重缺陷数/总缺陷数
Q4：各过程域（PA）中度量的具体行为有哪些
A4：除去项目过程中常用的度量示例外，建议PM需要了解CMMI-DEV中，各PA的度量具体行为。
●RM（Requirements Management，需求管理）
增加、删除、修改的需求数
需求易变性=（增加的+删除的+修改的）需求数/原有需求数
某个需求变更引起的工作量
●PP（Project Planning，项目策划）
制定项目计划所花的工作量
项目计划的修订次数
每次修订计划时的成本、进度和工作量与原计划的差异
●PMC（Project Monitoring and Control，项目监控）
打开和关闭的纠正行动数
项目里程碑日期
要执行的评审次数及类型
评审进度
●PPQA（Process and Product Quality Assurance，过程及产品质量保证）
计划的和实际执行的客观过程评价偏差
计划的和实际执行的客观工作产品评价偏差
●CM（Configuration Management，配置管理）
配置项的变更次数
配置审计次数
●MA（Measurement and Analysis，度量分析）
使用进展和性能度量的项目百分比
已处理的度量目的的百分比
Q5：SEI建议的度量元有哪些？
A5：SEI，也即Software Engineering Institute（软件工程研究院），为卡耐基.梅隆大学的软件工程研究院，CMMI各相关模型均为SEI指导建立，SEI提出如下建议的度量元，以供度量分析时参考。
●进度性能（里程碑性能，工作单元进展）
●成本性能（实际与计划的对照，不一致情况）
●工作量性能（实际与计划的对照，不一致情况）
●需求管理（增加的、删除的、修改的、需求易变性）
●程序规模（源码行数、页数、实际与计划的对照）
●测试性能（需要的测试、通过的测试）
●缺陷数据状态（未解决问题、解决完成问题、缺陷密度、缺陷来源）
●过程性能（完成的任务、行动项数）
●计算机资源利用率（内存占有量、CPU占有量）
●管理计划项目过程的性能（对照实际进展作估计、重计划、项目总结数据）
Q6：项目度量分析实例
A6：在《度量使用指南》中，提供了大量的度量使用的实例，对项目的度量与分析提供了可操作性较强的实例说明和分析，PM应尽量多阅读《度量使用指南》，使度量分析能在项目中发挥真正的作用。
下面摘录3个实例。
●实例1需求状态分析
图1：需求状态分析-设计进展
分析说明：
每里程碑或项目结束时，PM 依据需求跟踪矩阵中记录的需求变更数据分析项目需求实施状态的变化
情况，结果记录在里程碑总结和项目总结报告中，并提交给管理者、QAL、CML、测试负责人及其他项目组成员进行评审。
分析过程中主要考虑的问题是：
⏹项目需求的实施（包括设计、编码和测试）进展是否正常？
⏹哪些需求实施比较困难，影响进度？
如上图所示，两条蓝色的曲线按照时间以累计的形式表明了计划的已设计需求数量，红色的曲线表明了累计实际的已设计需求的数量。
很明显，相对于计划1 来讲，设计的进度严重拖期，因而调整并产生了计划2。
但是计划2 的可行要求项目在后几个月中提高设计的完成率，需结合项目实际情况加以评估。
更进一步，分析具体哪个需求严重地影响了设计的进展，而且人员能力、经验水平和需求质量状况等因素都可能影响设计的进行。
要根据分析的结果有针对性地采取相应的措施。
同理，也可以对编码和测试活动的进展进行同样的分析。
●实例2软件缺陷状态分析
图2：BUG 趋势图
分析说明：
软件缺陷是指软件产品预期属性的偏离现象，在本文中软件缺陷是指在软件开发过程引入的，软件工作产品本身的缺陷（通常称为软件BUG，以下简称为BUG）。
在测试类项目或测试活动中对软件缺陷数据进行收集和分析的目的是：了解软件缺陷的数量、修正进展、分布情况等软件质量状况，以便考察测试计划的合理性，进而在必要时及时地调整测试计划、测试策略和测试重点；同时可根据对软件质量状况的分析确定产品是否满足交付的条件，根据对软件缺陷发现趋势和修正趋势的分析，预测软件产品可交付日期。
每周、每里程碑或项目总结时，PM/测试负责人依据Bugbase/Buglist 跟踪项目当前缺陷实际发现和消除情况，包括发现的缺陷总数、需解决的和已解决的缺陷总数，比较需解决的缺陷数与已解决的缺陷数之间的差异，分析结果记录在项目周报、里程碑总结和项目总结中，并与管理者、QAL、CML、测试
负责人及其他项目组成员进行及时沟通。
分析过程中主要考虑的问题有：
⏹与缺陷发现进展相比，缺陷修正的进展是否过慢？
⏹测试什么时候可以完成？产品何时可以提交？
如上图所示，红色曲线代表累计已发现的缺陷数，棕色曲线代表累计需解决的缺陷数，蓝色曲线代表累计已解决的缺陷数。
图中显示的趋势表明缺陷解决的进展和发现的进展比较正常。
如果缺陷解决和发现数量的偏离趋势逐渐变大时，说明开发活动进展比测试活动进展慢，项目应分析原因并采取相应的措施以控制这种偏离趋势。
如果累计需要解决的缺陷和已经解决的缺陷数量差逐渐在减少并趋为零，则说明产品可以要提交了。
●实例3测试缺陷状态分析-未对应完的BUG 数
图3：未对应完的 BUG 数
分析说明：
每周、每里程碑或项目总结时，PM/测试负责人依据Bugbase/Buglist 跟踪项目当前未对应的BUG 情况，结果记录在项目周报、里程碑总结和项目总结中，并与管理者、QAL、CML、测试负责人及其他项目组成员进行沟通。
分析过程中主要考虑的问题有：
⏹是不是有很多长时间未解决的缺陷？
⏹这些缺陷的处理是否需要协调额外的资源？
⏹什么原因导致了未对应缺陷大量积累的现状？
如上图所示，很明显相对一周内未对应的缺陷数量来讲，延期一周以上未对应的缺陷比较多，项目需要分析具体原因并采取相应的措施重点解决这些缺陷。