CMMI管理指南阶段缺陷清除率指南
CMMI度量的一些关键指标
CMMI度量的一些关键指标
CMMI度量的一些关键指标
1.进度方面
实际进度的计划进度的偏差情况
返工时间占项目总时间的比例情况
2.工作量
实际工作量和计划工作量的偏差
三级增加对好质量成本和坏质量成本相关工作量的度量(COGQ,COPQ)
对项目返工，评审，测试和处理变更工作量的分别度量
3.成本
计划成本和实际成本的偏差
三级强调了成本和进度的性能指示器(挣值分析)
4.软件质量保证
不合格项的信息
SQA具体的审核信息
5.Review的结果
Review的活动项的状态
6.问题报告
问题项的具体状态(打开,处理,关闭)
问题的原因的分析，对问题的分类的统计
问题的平均处理周期度量
7.同行评审和缺陷
同行评审的缺陷的打开和关闭的情况统计
缺陷密度
缺陷移除率和缺陷泄漏率
同行评审的效率，评审速率的度量
同行评审的覆盖率
8.需求的度量
需求的规模的情况
需求的稳定度或需求的变更率
需求变更的不同类型的分布情况
需求变更处理的效率和周期度量
9.测试过程
测试的生产率的度量
测试规模的度量
生命周期不同阶段发现缺陷的数量分布，泄漏情况测试BUG的密度
缺陷率
10.产生的文档
文档的分类
文档的页数
各阶段产生的文档数。
CMMI5文档之缺陷管理规程
缺陷管理规程文档编号：FHI_CMMI_VER _PRD_BUGM文档信息：缺陷管理规程文档名称：缺陷管理规程文档类别：CMMI规程密级：内部秘密版本信息：1.1建立日期：2016-1-5创建人：EPG批准人：李庆林批准日期：2016.2.25存放位置：集成公司组织资产库/组织标准过程编辑软件：Microsoft Office 2003 中文版文档修订记录目录1、简介 (4)1.1 文档目的 (4)1.2 适用范围 (4)1.3 术语表 (4)1.4 参考资料 (4)2、项目缺陷预测 (5)2.1概述 (5)2.2入口准则 (5)2.3参与人员 (5)2.4预测方法 (5)2.4.1类似项目的质量目标预测 (5)2.4.2新项目的质量目标预测 (5)2.4.2里程碑阶段的缺陷级别预测 (5)3、项目缺陷跟踪 (6)3.1项目缺陷跟踪概述 (6)3.2实际缺陷数据的记录 (6)3.3缺陷解决 (6)3.4缺陷跟踪 (6)3.5产生实际缺陷数据 (7)4、缺陷分析 (7)4.1质量目标分析 (7)4.2测试用例分析 (7)5、附录 (7)5.1缺陷类型 (7)5.2缺陷严重程度 (8)1、简介软件缺陷是指那些使软件的行为方式与需求或客户要求不一致的东西。
软件产品质量的特性在实践中体现在缺陷上，缺陷管理的目标是提交缺陷尽量少的软件。
如何计划和管理质量控制活动，作为质量特性的缺陷管理非常重要，它包括缺陷的估计、缺陷数据的采集、跟踪与分析。
1.1文档目的本规程的目的是为了定义缺陷估计的内容和方法，缺陷跟踪过程以及缺陷分析内容和方法。
1.2适用范围本文档适用于公司的所有软件项目。
1.3术语表●项目规模：代码行、功能点或工作量（人时），本规程指工作量。
●缺陷注入率：单位规模（人时）的缺陷数。
●里程碑阶段缺陷级别：里程碑阶段（需求、设计、编码、单元测试、集成测试、系统测试和验收测试阶段）的缺陷占总缺陷数的百分比。
缺陷管理指南CMMI项目管理模板
缺陷管理指南文件状态：[√] 草稿[ ] 正式发布[ ] 正在修改文件标识：当前版本：作者：完成日期：文件修改版本控制更新状态: 用字母表示。
C——创建，A——增加，M——修改，D——删除1、目的与范围1.1目的编写此文档目的是想通过此文档让项目组成员了解此缺陷管理工具的使用规范，项目组内成员必须遵循此规范。
1.2范围与读者本文档只限于本项目组成员和与本项目组相关的公司内部人员，除以上人员外的其他员工不得拷贝。
2、操作流程第一步：输入url地址http://192.168.7.30/butterfly，进入页面后，输入用户名和密码，登录到butterfly缺陷管理系统中。
如图：第二步：提交缺陷（一般由测试人员提交缺陷）。
进入系统后，选择具体的项目，提交缺陷，如下图所示：上图中的红色字体为必填项。
测试人员填写完缺陷，提交后，此BUG流转到开发负责人，由开发负责人对此缺陷进行分配，此时缺陷的状态位“待分配”第三步：任务分配开发负责人登录到butterfly缺陷系统中，对任务进行分配，分配给开发人员进行修改。
如下图所示：开发负责人登录缺陷系统，点击上图的“分配”链接，对此缺陷进行分配，分配给开发人员进行修改。
第三步：开发人员收到修改BUG的任务。
开发人员登录系统，收到有待修改的BUG，根据BUG描述，开发人员修改源代码。
修改完成后，提交该缺陷任务到发布人员那里，开发人员提交任务时写明发布的内容，以便发布人员进行正确发布。
如图：第四步：待发布，发布人员进行发布第五步：待验证，测试人员对缺陷进行验证。
BUG修改完成后，点验证通过（待外部发布），否则点验证不通过。
外部发布后，此BUG关闭，验证不通过后，此BUG返回到“待修改”状态。
cmmi项目策划阶段实施指南
cmmi项目策划阶段实施指南English VersionCMMI Project Planning Stage Implementation GuideThe Project Planning stage is a critical phase in the CMMI (Capability Maturity Model Integration) process. It sets the foundation for the entire project by defining the scope, objectives, resources, and schedule. In this article, we will provide a step-by-step guide on how to effectively implement the Project Planning stage in a CMMI-compliant project.1. Define the Project Scope:The first step in the Project Planning stage is to clearly define the scope of the project. This includes identifying the goals, requirements, constraints, and assumptions of the project. It is important to involve all stakeholders in this process to ensure alignment and agreement on the project scope.2. Establish Project Objectives:Once the project scope is defined, the next step is to establish the project objectives. These objectives should be specific, measurable, achievable, relevant, and time-bound (SMART). They should align with the overall goals of the organization and provide a clear direction for the project team.3. Allocate Resources:After defining the scope and objectives, the next step is to allocate resources for the project. This includes identifying the necessary human resources, equipment, facilities, and budget required to successfully complete the project. It is important to ensure that resources are allocated efficiently and effectively to avoid any delays or cost overruns.4. Develop the Project Schedule:Once the resources are allocated, the project schedule should be developed. This involves creating a timeline that outlines the tasks, milestones, and deadlines for the project. The schedule should be realistic and achievable, taking into account any dependencies or constraints that may impact the project timeline.5. Monitor and Control the Project:Throughout the Project Planning stage, it is important to monitor and control the project progress. This involves tracking key performance indicators (KPIs), identifying any deviations from the plan, and taking corrective actions as needed. Regular communication and reporting are essential to ensure that the project stays on track.By following these steps, project managers can effectively implement the Project Planning stage in a CMMI-compliant project. This will help ensure that the project is delivered on time, within budget, and meets the quality standards set by the organization.中文翻译：CMMI项目策划阶段实施指南项目策划阶段是CMMI（能力成熟度模型集成）过程中的关键阶段。
CMMI评估流程
CMMI评估流程CMMI评估流程是一种用于评估和改进组织软件开辟和管理过程的方法。
CMMI（Capability Maturity Model Integration，能力成熟度模型集成）是由美国软件工程协会（SEI）开辟的一种模型，旨在匡助组织提高其软件开辟和管理能力。
CMMI评估流程通常包括以下几个阶段：1. 筹备阶段：在这个阶段，评估团队需要采集组织的相关信息，包括组织结构、项目管理方法、软件开辟过程等。
评估团队还需要与组织内部的相关人员进行沟通，了解他们对于软件开辟和管理的看法和需求。
2. 评估计划阶段：在这个阶段，评估团队需要制定详细的评估计划。
评估计划应包括评估的目标、范围、时间表、评估方法和评估准则等。
评估团队还需要与组织内部的相关人员共同确定评估的重点和关注点。
3. 数据采集阶段：在这个阶段，评估团队需要采集组织的相关数据，包括项目文档、过程描述、度量数据等。
评估团队可以通过文件审查、访谈、观察等方法来采集数据。
评估团队还可以使用一些工具来匡助他们采集和分析数据。
4. 数据分析阶段：在这个阶段，评估团队需要对采集到的数据进行分析。
评估团队可以使用一些统计方法和工具来分析数据，以了解组织的软件开辟和管理过程的优势和不足之处。
评估团队还可以与组织内部的相关人员进行讨论，以进一步了解数据的暗地里含义。
5. 结果报告阶段：在这个阶段，评估团队需要编写评估报告。
评估报告应包括评估的结果、发现的问题、建议的改进措施等。
评估报告应以清晰、简洁的方式呈现，以便组织内部的相关人员能够理解和接受评估的结果和建议。
6. 改进实施阶段：在这个阶段，评估团队需要与组织内部的相关人员合作，共同制定和实施改进措施。
改进措施可以包括制定新的软件开辟和管理过程、培训组织内部的人员、引入新的工具和技术等。
评估团队还可以匡助组织建立一套有效的度量和监控机制，以确保改进措施的有效性和持续改进。
总之，CMMI评估流程是一个系统化的方法，旨在匡助组织提高其软件开辟和管理能力。
CMMI评估流程
CMMI评估流程CMMI评估流程是一种用于评估和改进组织软件开发和服务管理过程能力的方法。
CMMI（Capability Maturity Model Integration）是一种国际公认的软件过程改进模型，它提供了一套全面的最佳实践指南，帮助组织提高软件开发和服务管理的质量和效率。
CMMI评估流程通常由以下几个步骤组成：1. 准备阶段：在准备阶段，评估团队需要与组织的管理层和项目团队进行沟通，明确评估的目标和范围。
评估团队还需要收集相关的文档和数据，以便在评估过程中进行分析和判断。
2. 评估计划制定：在评估计划制定阶段，评估团队需要制定评估的详细计划，包括评估的时间安排、评估的具体内容和方法、评估所需的资源等。
评估计划应该充分考虑组织的特定需求和约束。
3. 文档和数据准备：在文档和数据准备阶段，评估团队需要收集和准备评估所需的文档和数据。
这些文档和数据可以包括组织的政策和程序文件、项目计划和进展报告、项目文档和代码等。
评估团队还需要对这些文档和数据进行分析，以便在评估过程中进行评估和判断。
4. 现场评估：在现场评估阶段，评估团队需要实地访问组织的项目现场，与项目团队进行面谈和观察，了解组织的软件开发和服务管理过程的实际情况。
评估团队还可以进行抽样调查和检查，以验证组织的过程是否符合CMMI的要求。
5. 结果分析和报告编写：在结果分析和报告编写阶段，评估团队需要对评估的结果进行分析和判断。
评估团队可以使用CMMI评估模型的指南和标准，对组织的软件开发和服务管理过程进行评估和定级。
评估团队还需要编写评估报告，将评估的结果和建议提交给组织的管理层和项目团队。
6. 改进计划制定：在改进计划制定阶段，评估团队需要与组织的管理层和项目团队一起制定改进计划，以提高组织的软件开发和服务管理过程能力。
改进计划应该包括具体的行动计划、资源需求和时间安排等。
7. 改进实施和跟踪：在改进实施和跟踪阶段，组织需要按照改进计划的要求，实施相应的改进措施。
CMMI-过程裁剪准则和指南
过程裁剪准则和指南广东×××监控技术股份有限公司修订历史记录目录1目的 (4)2名词术语 (4)3裁剪原则 (4)4裁剪流程 (4)5裁剪依据、要素和尺度 (5)6裁剪方法 (6)7裁剪指南 (6)7.1裁剪过程 (6)7.1.1 删减过程 (6)7.1.2 合并过程 (6)7.1.3 增加过程 (6)7.2裁剪活动 (7)7.2.1 删减活动 (7)7.2.2 裁剪活动频度 (7)7.2.3 裁剪活动正式度 (7)7.3裁剪方法和工具 (7)7.4裁剪度量 (7)7.5裁剪评审及会议 (7)7.6裁剪模板 (7)1目的公司的标准软件过程（OSSP）是在考虑了公司软件项目开发的共性特点，并遵照CMMI过程改进模型的基础上形成的，具有一定的共性，但每个软件项目却因为自身的特点而具有个性的特征。
编制《过程裁剪准则和指南》的目的就是指导软件项目组根据自身特点裁剪公司的标准软件过程，以形成项目定义过程（PDP）。
2名词术语2.1OSSP（Organizational Standard Software Process）:：组织标准软件过程。
组织级的、考虑了所有项目特征的标准软件过程，包括软件项目生命周期及其裁剪指南。
2.2 PDP（Project Defined Process）：项目定义过程，是从组织标准过程集合裁剪出的针对项目自身特点的过程。
2.3 EPG (Engineering Process Group)：工程过程组，负责公司内部的过程定义、维护和改进的专家组。
3裁剪原则项目裁剪组织标准软件过程的一般原则：➢如果顾客对过程提出要求，则必须遵循；➢遵循OSSP中的各个过程中提出的裁剪指南；➢过程裁剪后不得降低工程师的生产率；➢裁剪后应保证产品的质量；➢裁剪后不得降低对工作进展的可视性（跟踪）；➢裁剪后不会对产品增加不必要的管理和控制；➢裁剪后的活动能有足够的人力支持；➢在成本核算上，裁剪后的活动是有效的，经费能足以支持；➢裁剪过程必须可控；➢裁剪结果需得到一致的认可。
软件测试-软件缺陷管理指南
缺陷管理指南修订历史记录1.0目的通过建立物理配置库的设立，规范各配置库目录的设立原则，确保配置库的统一与规范，确保项目产品得到有效的管理与运用，提高资源的共享与利用。
缺陷管理的最终目标是最大限度地减少缺陷的出现率，从而提高软件产品的质量。
细分为：1）从缺陷发生到结束的全生命周期进行跟踪管理，尽可能发现所有的缺陷，确保每个被发现的缺陷都能够被解决；2）收集缺陷数据并根据缺陷趋势图识别测试过程的阶段；可以通过缺陷趋势图来确定测试过程是否结束；3）在已收集到的缺陷数据的基础上进行统计分析。
总结缺陷出现的原因、类型和规律，采取相应措施避免该类型缺陷再次出现，并在开发过程的早期阶段予以确定，起到缺陷预防的作用，并作为组织的过程财富。
本指南规定了缺陷管理流程以及缺陷统计分析要求，项目组必须严格遵循本规程要求保证在较短的时间内高效率地解决所有缺陷，缩短软件开发测试进程，提高软件质量，减少开发和维护成本。
2.0参考文件无3.0定义无4.0职责5.0资历及培训无6.0入口6.1 入口准则缺陷发生时6.2 输入无7.0 主要活动7.1定义缺陷定义缺陷的要素，如下表（其中*为必选项）：严重程度：优先级：Bug类型：如何发现：解决方案：7.2缺陷管理流程7.2.1基于bugfree的缺陷管理流程：●缺陷的提交发现的缺陷均提交给相关开发人员，如果不明确提交给谁则统一提交给项目经理，缺陷的状态为：Active。
提交缺陷必须填写：缺陷的描述、优先级、严重程度、缺陷的状态、发现缺陷的阶段等信息。
这些信息由提交缺陷的人负责填写。
●缺陷的分配对于有异议的缺陷有项目组指定人员对缺陷评审，决定缺陷计划解决的版本、时间和负责人员。
对于指派给项目经理的缺陷由项目经理确认指派给何人。
分配缺陷后的状态为：Active缺陷分配必须修改：指派人、评审信息（可选）。
这些信息由缺陷的分配人负责填写。
评审信息在“注释”中描述。
●缺陷的解决缺陷由指定的开发人员解决后，填写缺陷修改完成时间和缺陷处理结果描述.解决后的缺陷的状态为：Resolved解决缺陷必须修改：解决方案、解决人、解决缺陷的版本、解决的分析、解决方案。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
C M M I管理指南阶段缺
陷清除率指南
集团文件发布号：（9816-UATWW-MWUB-WUNN-INNUL-DQQTY-
银行
阶段缺陷清除率指南文档信息：
版本：V1.0.0
类别：指南
密级：内部
状态：非受控
修订记录：
修订内容：
目录
1. 引言 (1)
.目的 (1)
.预期读者 (1)
.术语表 (1)
.参考资料 (1)
2. 阶段缺陷清除率（DRE）模型基本数学定义 (1)
3. 阶段缺陷清除率（DRE）应用示例 (2)
1.引言
1.1.目的
本文档目的是为理解阶段缺陷清除率的数学定义及计算提供指引。
1.2.预期读者
1、软件开发中心及总行相关部门领导和主管
2、EPG全体成员
3、项目组全体成员
1.3.术语表
无
1.4.参考资料
无
2.阶段缺陷清除率（DRE）模型基本数学定义
计算阶段缺陷清除率（Phase DRE ）的步骤：
考察开发过程中哪些活动会为产品注入缺陷
考察开发过程中哪些活动会从产品中清除缺陷
1 2 3 i m
缺陷
清除
活动
活动1 D 11
D *1
活动2 D 12 D 22
D *2
活动3 D 13 D 23 D 33
D *3
… …
D *j-1
活动j D 1j D 2j
D ij
D *j
… …
活动n D 1n D 2n D in
D mn D *n
合计 D 1* D 2* D 3* D i*
D m* D mn
一般的，注入缺陷的活动执行结束后，会相应地发起缺陷清除活动。
如果活动与生命周期阶段一致，可以认为是阶段的缺陷注入和清除。
当考察阶段缺陷注入和清除率时，需要注意一个阶段可能包含多个缺陷注入活动和多个缺陷清除活动。
执行完缺陷清除活动j之后，分析发现的缺陷，按照这些缺陷的注入原因分别统计缺陷数，并填入上表中相应的位置
如上表：清除活动j一共发现了D
*j
个缺陷，注入活动1到i分别
注入了D
1j 、D
2j
、…D
ij
个缺陷。
项目执行完成时，注入和清除活动都被执行，上表就被填写完毕
可计算缺陷清除活动j的清除率：
解释：
分子很显然，是这个清除活动j发现的缺陷总数
分母实际上是在进入清除活动j的入口处产品中还遗留的缺陷数，它是：
清除活动j之前执行的所有注入活动注入的缺陷总数
清除活动j之前执行的所有清除活动发现的缺陷总数
两者之间的差值。
注意：
理论上，产品中的缺陷个数是无法得知的，因此缺陷清除率模型有个假设前提：
忽略产品中那些没有被发现的缺陷
3.阶段缺陷清除率（DRE）应用示例
假定一个项目有4个主要的活动能够注入缺陷，分别是：
需求定义
概要设计
详细设计
编码
项目生命周期也有同名的4个阶段。
同时，开发过程有6个主要的活动能够清除缺陷，分别是：
需求评审（需求定义之后、概要设计之前）
概要设计评审（概要设计之后、详细设计之前）
详细设计评审（详细设计之后、编码之前）
单元测试（编码之后）
代码评审（编码之后）
系统测试（编码之后）
并且项目在交付后进行缺陷对应期间也记录、统计了交付后发现的缺陷。
项目执行完毕后统计到的缺陷数按照注入和清除活动划分，得下表：
缺陷注入活动（或阶段）
需求定义概要设
计
详细设计编码合计
缺陷清除活动需求评审3535概要设计评审46468详细设计评审61282100单元测试1025256124415
于是：
详细设计评审的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%当然，单独考察一个活动的缺陷清除率也可以。
还可以计算某个缺陷清除活动之前所有清除活动总的缺陷清除率，例如：
交付前所有缺陷清除活动总的DRE：（1091 – 48）/1091 * 100% = %
系统测试前所有缺陷清除活动总的DRE：（）/1091 * 100% = %。