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

银行阶段缺陷清除率指南文档信息：版本：V1.0.0类别：指南 密级：内部状态：非受控 修订记录：日期版本修订描述作者修订内容：版本修订内容V0.1.0根据内部评审意见对指南进行了修改V1.0.0对文档内的内容及相关文档之间的内容进行一致性、完整性的检查和修改；对文档参照命名规范和模板要求进行规范性方面的检查和修改目录1. 引言11.1. 目的11.2. 预期读者11.3. 术语表11.4. 参考资料12. 阶段缺陷清除率（DRE）模型基本数学定义13. 阶段缺陷清除率（DRE）应用示例21. 引言1.1. 目的本文档目的是为理解阶段缺陷清除率的数学定义及计算提供指引。1.2. 预期读者1、软件开发中心及总行相关部门领导和主管2、EPG全体成员3、项目组全体成员1.3. 术语表无1.4. 参考资料无2. 阶段缺陷清除率（DRE）模型基本数学定义缺陷注入活动（或阶段）活动1活动2活动3活动i活动m合计缺陷清除活动活动1D11D*1活动2D12D22D*2活动3D13D23D33D*3 D*j-1活动jD1jD2jDijD*j 活动nD1nD2nDinDmnD*n合计D1*D2*D3*Di*Dm*Dmn计算阶段缺陷清除率（Phase DRE）的步骤：l 考察开发过程中哪些活动会为产品注入缺陷l 考察开发过程中哪些活动会从产品中清除缺陷一般的，注入缺陷的活动执行结束后，会相应地发起缺陷清除活动。如果活动与生命周期阶段一致，可以认为是阶段的缺陷注入和清除。当考察阶段缺陷注入和清除率时，需要注意一个阶段可能包含多个缺陷注入活动和多个缺陷清除活动。l 执行完缺陷清除活动j之后，分析发现的缺陷，按照这些缺陷的注入原因分别统计缺陷数，并填入上表中相应的位置如上表：清除活动j一共发现了D*j个缺陷，注入活动1到i分别注入了D1j、D2j、Dij个缺陷。l 项目执行完成时，注入和清除活动都被执行，上表就被填写完毕l 可计算缺陷清除活动j的清除率：解释：分子很显然，是这个清除活动j发现的缺陷总数分母实际上是在进入清除活动j的入口处产品中还遗留的缺陷数，它是：l 清除活动j之前执行的所有注入活动注入的缺陷总数l 清除活动j之前执行的所有清除活动发现的缺陷总数两者之间的差值。注意：理论上，产品中的缺陷个数是无法得知的，因此缺陷清除率模型有个假设前提：l 忽略产品中那些没有被发现的缺陷3. 阶段缺陷清除率（DRE）应用示例假定一个项目有4个主要的活动能够注入缺陷，分别是：l 需求定义l 概要设计l 详细设计l 编码项目生命周期也有同名的4个阶段。同时，开发过程有6个主要的活动能够清除缺陷，分别是：l 需求评审（需求定义之后、概要设计之前）l 概要设计评审（概要设计之后、详细设计之前）l 详细设计评审（详细设计之后、编码之前）l 单元测试（编码之后）l 代码评审（编码之后）l 系统测试（编码之后）并且项目在交付后进行缺陷对应期间也记录、统计了交付后发现的缺陷。项目执行完毕后统计到的缺陷数按照注入和清除活动划分，得下表：缺陷注入活动（或阶段）需求定义概要设计详细设计编码合计缺陷清除活动需求评审3535概要设计评审46468详细设计评审61282100单元测试1025256124415代码评审0458168230系统测试12188679195交付后缺陷对应26182248合计691295003931091于是：详细设计评审的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+500+393）-（35+68+100） * 100% = 73%当然，单独考察一个活动的缺陷清除率也可以。还可以计算某个缺陷清除活动之前所有清除活动总的缺陷清除率，例如：交付前所