【转】实用软件度量-CMMI专题培训

一、概述
度量的目的：

•  理解——获得对过程、产品、资源等的理解;是评估、预测和改进活动的基础。定量的理解才是对事物本质的了解,真正“心中有数”
  

•  预测——通过建立预测模型,进行估算和计划。 历史数据能够帮助我们预测和计划

•  评估——产品的质量、过程改进的效果等。对趋势的分析可以使我们找到问题出在哪里

•  改进——根据得到的量化信息,确定潜在的改进机会。度量本身不会改进过程;但它为我们提供了对计划、控制、管理和改进的可视性

度量是有成本的

• 度量是项目管理的重要手段，但度量是需要成本的

• 度量的成本（数据收集和分析）

     --小于项目总成本的3%

• 管理成本通常估计为项目的总成本的10-15%

GQM方法-—一种确定（选择）度量的途径

• GQM(Goal-Question-Metric)
• GQM的主要步骤：

– 确定度量的目标
– 提出能够满足目标的问题
– 确定回答问题所需要的度量
GQM法举例
目标：改进项目计划
-问题1 项目进度是否发生了偏差？
  度量:里程碑实际到达时间
      任务包完成的数量
– 问题2 项目工作量是否发生了偏差?
  度量:各种工作量
GQM方法的优点：

• 易于操作
• GQM便于识别所需的度量
• 便于确定收集数据的用途
• 使我们明确所收集的数据应该如何分析、解释

实施软件度量的前提条件：

• 管理者支持
• 全体员工的参与
• 统一的定义
• 有效的度量过程(制定好的度量规程和度量计划)
• 实用的度量工具

二、选择度量
2.1 在process area（PA)中requirment management(RA)度量需求
来判断管理分配到的需求活动的状态
• 度量的例子有:
  – 需求的状态
  – 需求的修改
  – 累计对分配到的需求的变更的数目,它包括如下几方面修改的
    总数:提出的修改,未处理的或处理后尚未解决的修改,赞同的修改以及合并到系统基线中的修改。
2.2 PA PP中的度量需求（program Planning)
• 度量的例子有:
  – 估计过程需要历史项目度量数据:软件规模、工作量、进度(里程碑、任务进展)、成本、资源、风险
  – 与其计划相比,在软件项目计划活动中工作的完成情况、花费的工作量以及支出的费用
2.3 PA PMC中的度量需求(Project Monitoring and control)
根据度量结果与计划相比较,实施项目监控,并用于判断软件跟
 踪和监控活动的状态
• 度量的例子有:
  – 软件规模、工作量、进度(里程碑、任务进展)、成本、资源、风险
  – 在进行跟踪和监控的活动中所花费的工作量和其它资源
  – 对软件开发计划的修改活动,它包括对软件工作产品规模的估计、对软件成本的估计、对关键计算机资源的估计以及对进度等的修改
2.4 PA SAM中的度量问题
度量的目的是为了判断供应商合同管理活动进行的状态
• 度量的例子有:
  – 与其计划相比,管理供应商合同活动的成本
  – 与其计划相比,分包产品实际交付的日期
  – 与其计划相比,主承包商交付到分包商的实际日期
2.5 PA PPQA中的度量需求
度量的目的是为了判断SQA活动的成本和进度状态
• 度量的例子有:
  – 与其计划相比,SQA活动完成的里程碑数
  – 在SQA活动中完成的工作,花费的工作量及支出的费用
  – 与其计划相比,产品审查和活动评审的次数
2.6 PA CM中的度量需求
度量的目的是为了判断SCM活动的状态
• 度量的例子有:
  – 处理的修改请求的数目
  – 与其计划相比,SCM活动完成的里程碑数
  – 与其计划相比,在SCM活动中完成的工作,花费的工作量及支
    出的费用
2.6.1 按进度追踪进展
• 定期度量活动和里程碑的实际完成情况
• 按项目计划中文档化的进度比较活动(阶段跨越的时间和里程
 碑到达时间)的实际完成情况
• 标识进度计划的严重偏离(根据阈值)
• 相对偏离(相对于本阶段)与绝对偏离
• 对关键路径上的活动和非关键路径上的活动,要按不同的阈值
 进行控制
2.6.2 追踪成本和工作量、人数
• 定期度量实际工作量和所花的成本及分配的人员
• 与项目计划中记录的估计和预算比较实际的工作量、成本、人
 员配置
• 标识与项目计划中的预算的严重偏离
2.6.3 跟踪工作产品和任务的属性
• 工作产品和任务的属性包括规模、复杂度、权重等
• 跟踪内容包括:
  – 定期度量工作产品和任务的实际属性,如规模或复杂度 (和对
    属性的变更)
  – 将工作产品和任务的属性的实际值(和对属性的变更)与项目
    计划中记录的估计值进行比较
  – 标识与项目计划中的估计的严重偏离


2.6.4 跟踪需求状态
• 一个需求经提出、评审、设计、编码实现和测试,它的状态将发生变化。可以将需求分被建议、被拒绝、被批准、被实现、被验证、被废除、被交付等状态
  – 被建议:该需求已被有权提出需求的人建议
  – 被拒绝:该需求被建议后,评审未通过
  – 被批准:该需求已被分析,估计了其成本和对项目其他部分的影响,而且通过评审
  – 被实现:已实现需求的设计、编码和单元测试
  – 被验证:使用所选择的方法(如测试)已验证了实现的需求,该需求现在被认为完成
  – 被废除:被批准的需求已从基线中废除,但记录了原因说明和做出废除决定的人员
  – 被交付:需求已通过客户的验收。
2.6.4.1对需求状态的追踪


2.6.4.2对需求变更的分析
• 增加、修改或删除需求时,要进行影响分析:
  – 对开发进度的影响
  – 对发布进度的影响
  – 对人员安排的影响
  – 对成本的影响
  – 对现有约定(Commitment)的影响
  – 变更引起的风险分析
  – 对其他相关的工作产品的影响
 
• 总的需求数=(基线需求数+增加的需求数-删除的需求数)
• 需求变更数=(增加的需求数+删除的需求数+修改的需求数)
• 需求稳定性=(需求变更数/基线需求数)

2.6.5 跟踪缺陷数据——缺陷跟踪表（bug库也可以）
缺陷的度量(一)
• 缺陷按注入阶段的分布
• 缺陷按发现阶段的分布
• 缺陷按类型的分布
• 缺陷按严重程度的分布
• 缺陷按模块的分布
• 缺陷密度 = 缺陷数 / 实际规模
• 残余数:进入该阶段时已有的缺陷数
• 注入数:在该阶段注入的缺陷数
• 清除数:在该阶段清除的缺陷数
• 剩余数:在该阶段剩余的缺陷数
• 注入率:在该阶段中每KLOC或每功能点注入的缺陷数
• 过程阶段的清除率:清除数/(残余数+注入数)
• 总效率:总清除数/总注入数
• 审查缺陷:由审查发现的缺陷数
• 开发缺陷:由审查发现的缺陷数 + 由测试发现的缺陷数
2.6.6 SEI建议的最小度量元集
• 进度性能 (里程碑,不一致情况)
• 费用性能 (实际的与计划的对照,不一致情况)
• 工作量性能 (实际的与计划的对照,分配情况)
• 需求管理 (总数,增长,追踪性)
• 程序规模 (源码行,页数 - 实际的与计划的对照)
• 测试性能 (需要的测试, 通过的测试)(功能、语句、分支、路径覆盖率)
• 缺陷数据状态 (未解决和解决的问题,缺陷密度,缺陷来源)
• 过程性能 (完成的任务,行动项数)
• 计算机资源利用率 (内存占有量,CPU占有量等)
• 管理计划项目过程的性能(对照实际进展作估计,重计划,项目总结数
 据)