CMMI管理指南阶段缺陷清除率指南.docVIP

银行 阶段缺陷清除率指南 文档信息： 版本：V1.0.0 类别：指南 密级：内部 状态：非受控 修订记录： 日期 版本 修订描述 作者 修订内容： 版本 修订内容 V0.1.0 根据内部评审意见对指南进行了修改 V1.0.0 对文档内的内容及相关文档之间的内容进行一致性、完整性的检查和修改；对文档参照命名规范和模板要求进行规范性方面的检查和修改 目录 1. 引言 1 1.1. 目的 1 1.2. 预期读者 1 1.3. 术语表 1 1.4. 参考资料 1 2. 阶段缺陷清除率（DRE）模型基本数学定义 1 3. 阶段缺陷清除率（DRE）应用示例 2 引言 目的 本文档目的是为理解阶段缺陷清除率的数学定义及计算提供指引。 预期读者 1、软件开发中心及总行相关部门领导和主管 2、EPG全体成员 3、项目组全体成员 术语表 无 参考资料 无 阶段缺陷清除率（DRE）模型基本数学定义 缺陷注入活动（或阶段） 活动1 活动2 活动3 … 活动i … 活动m 合计 缺陷清除活动 活动1 D11 D*1 活动2 D12 D22 D*2 活动3 D13 D23 D33 D*3 … … D*j-1 活动j D1j D2j Dij D*j … … 活动n D1n D2n Din Dmn D*n 合计 D1* D2* D3* Di* Dm* Dmn 计算阶段缺陷清除率（Phase DRE）的步骤： 考察开发过程中哪些活动会为产品注入缺陷 考察开发过程中哪些活动会从产品中清除缺陷 一般的，注入缺陷的活动执行结束后，会相应地发起缺陷清除活动。如果活动与生命周期阶段一致，可以认为是阶段的缺陷注入和清除。 当考察阶段缺陷注入和清除率时，需要注意一个阶段可能包含多个缺陷注入活动和多个缺陷清除活动。 执行完缺陷清除活动j之后，分析发现的缺陷，按照这些缺陷的注入原因分别统计缺陷数，并填入上表中相应的位置 如上表：清除活动j一共发现了D*j个缺陷，注入活动1到i分别注入了D1j、D2j、…Dij个缺陷。 项目执行完成时，注入和清除活动都被执行，上表就被填写完毕 可计算缺陷清除活动j的清除率： 解释： 分子很显然，是这个清除活动j发现的缺陷总数 分母实际上是在进入清除活动j的入口处产品中还遗留的缺陷数，它是： 清除活动j之前执行的所有注入活动注入的缺陷总数 清除活动j之前执行的所有清除活动发现的缺陷总数 两者之间的差值。 注意： 理论上，产品中的缺陷个数是无法得知的，因此缺陷清除率模型有个假设前提： 忽略产品中那些没有被发现的缺陷 阶段缺陷清除率（DRE）应用示例 假定一个项目有4个主要的活动能够注入缺陷，分别是： 需求定义 概要设计 详细设计 编码 项目生命周期也有同名的4个阶段。 同时，开发过程有6个主要的活动能够清除缺陷，分别是： 需求评审（需求定义之后、概要设计之前） 概要设计评审（概要设计之后、详细设计之前） 详细设计评审（详细设计之后、编码之前） 单元测试（编码之后） 代码评审（编码之后） 系统测试（编码之后） 并且项目在交付后进行缺陷对应期间也记录、统计了交付后发现的缺陷。 项目执行完毕后统计到的缺陷数按照注入和清除活动划分，得下表： 缺陷注入活动（或阶段） 需求定义 概要设计 详细设计 编码 合计 缺陷清除活动 需求评审 35 35 概要设计评审 4 64 68 详细设计评审 6 12 82 100 单元测试 10 25 256 124 415 代码评审 0 4 58 168 230 系统测试 12 18 86 79 195 交付后缺陷对应 2 6 18 22 48 合计 69 129 500 393 1091 于是： 详细设计评审的DRE = 100 / [（69+129+500）-（35+68）] * 100% = 17% 系统测试的DRE = 195 / [（69+129+500+393）-（35+68+100+415+230）] * 100% = 80% 考察编码阶段的缺陷清除率时，这个阶段包含了两个缺陷清除活动：单元测试和代码评审。于是，单独考察其中一个活动的缺陷清除率就意义不大了，因为我们认为只要两个活动合起来能够尽可能多的清除缺陷就可以了，单一活动清除率的高低并不重要。因此将单元测试和代码评审合起来作为对编码阶段结束的一个检查点，那么编码阶段的缺陷清除率应该是： （415+230）/[（69+129