CMMI3级过程改进案例分析报告
基于CMMI模型的过程改进
基于CMMI 模型的过程改进收稿日期：2018-03-14基金项目：本文受到北京市委组织部优秀人才项目（项目号：2012D005017000004）和北京建筑大学校教研项目（基于案例驱动的软件工程教学方法研究）的资助作者简介：赵海龙（1976-），男（汉族），河北邯郸人，讲师，博士，研究方向：软件工程、模式识别与图像处理。
一、引言众所周知，一个企业或项目的成功离不开过程、人员和技术，过程作为粘合剂把人员和技术紧密地联系在一起，产品的质量在很大程度上取决于用以开发和维护该产品的过程的质量。
本文第二部分介绍了过程改进的基本概念和实施过程改进常用的几种方法；第三部分对能力成熟度集成模型（Capability Maturity Model Integration ，CMMI ）做了说明；第四部分对CMMI 中的一些概念和术语进行较详细的解释。
二、过程改进的概念及方法按照IEEE 的定义，过程是指为了达到给定目标而执行的一系列步骤。
过程改进是指过程的拥有者为了使组织达到新的目标而采取的一系列的活动，这些活动包括对组织内部的现存过程进行标识、分析和改进。
组织进行过程改进的目标通常是提高质量、提高生产率以及降低生产/开发成本等。
常见的过程改进方法有以下几类。
1.业务流程重组。
业务流程重组（Business Process Reengineering ，简称BPR ）强调以业务流程为改造对象和中心、以关心客户的需求和满意度为目标、对现有的业务流程进行根本的再思考和彻底的再设计，利用先进的制造技术、信息技术以及现代的管理手段，最大限度地实现技术上的功能集成和管理上的职能集成，以打破传统的职能型组织结构，建立全新的过程型组织结构，从而实现企业经营在成本、质量、服务和速度等方面的巨大改善。
2.基准化分析法。
基准化分析法（Benchmarking ），也称标杆分析法，就是将本企业各项活动与从事该项活动最佳者进行比较，从而提出行动方法，以弥补自身的不足。
一个虚构的CMM改进实例
一个虚构的CMM改进实例某系统集成企业（简称A公司），在电信计费/业务支撑行业小有名气，业务开展得相当成功，但是在进一步发展的过程中，遇到了以下几个问题：1.公司目前在独立开发和维护多个功能大体相似，却又有相当差别的系统版本，这些版本之间的关系“剪不断，理还乱”，公司试图引用一些业界标准的系统架构，比如J2EE，试图实现部分软件重用。
但是却发现情况并不能够得到多少改善。
2.公司常年有大批的开发人员被派驻到客户方，导致了高昂的人力资源成本。
这些开发人员难以管理，对公司的认同感差。
3.公司制定了一定的项目管理规范，但是在推行过程中却不尽如人意。
项目不断延期，事故不断。
4.公司没有正规的培训体系，软件技术人员在需求，分析，设计和测试的技能不足。
鉴于现在行业软件的严峻形势，A公司要求改变这一现状，加强管理，提高效率，减少派驻在客户方的人数。
A 公司和小有名气的C咨询公司签订了合同，要求C帮助A 公司完成这项变革。
C公司的张顾问具体负责这个项目。
根据自身丰富的经验，张顾问立刻意识到：1.这是一个管理和技术相互缠绕的问题，必须结合两方面的手段，综合进行解决。
2.A公司意识到这个问题其实不是一天两天了，以前也曾经想了很多解决方案，但是为什么这些方案会失败？查找以前这些努力的历史，将有助于问题的解决。
3.任何一项变革，必须获得公司高层的明确和实质性的支持否则难以成功。
根据自身的经验，张顾问拟定了一个工作规划：1.推动客户方成立一个“行动小组”并获得高层的明确授权。
2.在“行动小组”的主持下，了解客户方曾经进行这方面版本规范化的努力的历史以及失败的原因。
3.和客户方共同分析A公司的电信业务系统的架构。
4.在客户方展开访谈，了解项目管理和质量管理的现状。
5.在了解现状的基础上，对客户的现状进行诊断，对用户高层和C公司进行报告。
“联合行动小组”很快成立起来了，小组由精干的人员组成，在张顾问的特别要求下，小组的成员不仅仅来自于管理部门，也增加了来自于项目管理部，技术开发部，和特地从现场工程部门抽调出来的人员。
基于CMMI软件过程改进
基于CMMI的软件过程改进
3.6 持续的过程改进
当体系在公司内部推广并通过认证后，并不代表过程改进工 作结束，只是表明企业目前已取得了阶段性成果，还需要不 断深化，总结经验。要将过程改进工作持续推进，还要做好 以下工作： 一是持续完善更新资产库，制订持续改善计划和方案； 二是对过程管理体系规范进行定期修订，确保对项目有较强 的适应性； 三是用工具完成对开发流程的支撑；最后要大力推进质量目管理工作
软件项目的测试工作 管理测试合作团队 软件项目过程的质量保证工作 软件项目产品的质量保证工作 组织软件过程管理体系及相关专题的培训 工作
Page 9
基于CMMI的软件过程改进
3.3 建立CMMI过程改进与管理体系
结合实际项目特征，通过对CMMI标准的培训后，研究CMMI模型 要求，指导CMMI各个过程域如何落地形成规范体系。
文化建设，使过程改进工作落到实处。
Page 15
Page 8
基于CMMI的软件过程改进
软件过程管理体系的建设、执行及持续改进涉及到的角色和职责如下
部门/职能组名称
MSG
工作职责
设定过程改进目标 提供过程改进资源 审核过程文件 监督过程改进进度与质量
界定过程改进项目 建立过程改进计划 整合相关过程 审查过程文件与工具并实现推展的承诺
EPG
开发组
为软件过程从不成熟到成熟、不完善到完善勾画了一个阶段 图，从而清晰的甄别出不同软件企业，不同软件过程的成熟 能力，CMMI为软件企业的过程改进带来了深远的影响。
Page 2
基于CMMI的软件过程改进
基于CMMI的软件过程改进的方法主要有以下几个方面： 在组织准 备上，在资金支持且具有管理职责的人员负责 CMMI实施和改善软件过程的基础上，还须成立软件工程 过 程指导组(SEPG )，主要编写或修改必要的过程改进文 档以 及文档执行；成立软件质量管理组，测试和分析项 目进展情 况，反馈项目过程状态 ，审计指定的软件工作产品以检验其 遵从性；成立软件配置的管理组 ，编写或修改必要的软件配 置管理文档并执行。
CMMI3级过程改进案例分析
CMMI3级过程改进案例分析CMMI（Capability Maturity Model Integration）是一个美国软件工程协会（SEI）开发的过程改进模型，旨在帮助组织提高其软件和系统工程能力。
CMMI模型以五个不同的成熟度级别来评估组织的过程改进成熟度，从级别1（初始级）到级别5（优化级）。
本文将分析一个CMMI级别3的过程改进案例，该案例涉及一个虚拟软件开发公司的项目管理流程。
该软件开发公司在过去的几年里迅速扩张，面临着越来越多的项目和客户需求。
然而，由于流程不规范和管理混乱，公司经常面临项目延期、质量问题和客户不满的情况。
因此，公司决定进行CMMI级别3的过程改进，以确保项目按时交付、质量得以保证并提高客户满意度。
在开始过程改进之前，公司进行了一次自我评估，识别了以下问题：1.项目管理流程不规范：项目经理在不同项目之间使用不同的流程和模板，导致难以复用经验和最佳实践。
2.文档管理混乱：公司缺乏一套标准的项目文档模板和版本控制机制，导致难以跟踪和管理项目文档。
3.报告和沟通不及时：在项目中，上级经理和客户之间的沟通和报告不及时，导致无法及时响应变更请求或解决问题。
为解决以上问题，公司采取了以下步骤：1.确立项目管理过程框架：公司制定了一套标准的项目管理过程框架，包括项目启动、规划、执行、监控和收尾等不同阶段的流程和活动。
这一框架通过模板和指南的形式被推广给所有项目经理和团队成员。
2.建立文档管理系统：为了解决文档管理混乱的问题，公司引入了一套文档管理系统，用于统一管理项目文档和版本控制。
所有项目相关的文档都必须通过该系统进行创建、审批和存储，以确保文档的完整性和一致性。
3.实施定期报告和沟通机制：为了加强项目监控和沟通，公司建立了定期报告和沟通机制。
项目经理需要定期向上级经理和客户提交进展报告，并参加定期的项目评审会议，以及时解决问题和调整项目计划。
经过一段时间的过程改进实施后，公司取得了以下成果：1.项目交付时间得到了明显的改善：通过建立标准的项目管理过程框架，项目经理能够更好地规划项目，并及时解决问题，从而大大减少了项目延期的可能性。
CMMI_3级软件过程改进方法与规范
内容提要软件过程改进是目前IT 企业研发管理的重点与难点。
为了提高软件过程能力，企业首先要研制软件过程规范，这是有一定难度并且费时费力的工作。
本文论述的是一套通用的CMMI 3级软件过程改进方法与规范，称为“精简并行过程”（SPP）。
SPP 2.0共有19个关键过程域，分为项目管理过程、技术开发过程和支撑过程三大类：✧项目管理过程有7个关键过程域，分别为立项管理、结项管理、项目计划、项目跟踪、风险管理、外包管理和需求管理。
✧技术开发过程有8个关键过程域，分别为需求开发、技术预研、系统设计、实现与测试、系统测试、用户验收、产品维护和技术评审。
✧支撑过程有4个关键过程域，分别为配置管理、质量保证、采购管理和培训管理。
SPP 2.0文档总数约500余页，包含了众多的过程规范和模板。
采用SPP，用户可以在最短的时间内建立适合于本企业的软件过程规范，大大降低用户研制规范的代价和风险。
一、背景介绍在国内，绝大多数大中型IT企业几乎都面临着“研发管理混乱”的难题。
“研发管理混乱”必将导致“产品质量低下”、“进度延误”、“费用超支”等问题。
IT企业谋求发展，研发管理必须规范化，这是大中型IT企业的迫切需求。
软件过程改进（Software Process Improvement, SPI）是目前国内大中型IT企业研发管理的重点与难点。
CMM（Capability Maturity Model）是用于衡量软件过程能力的事实上的标准，同时也是目前软件过程改进最好的参考标准。
CMM是由美国卡内基-梅隆大学（Carnegie-Mellon）软件工程研究所（Software Engineering Institute, SEI）研制的，其发展简史如下：✧CMM 1.0于1991年制定。
✧CMM 1.1于1993发布，该版本应用最广泛。
✧CMM 2.0草案于1997年制定（未广泛应用）。
✧到2000年，CMM演化成为CMMI（Capability Maturity Model Integration），CMM2.0成为CMMI 1.0的主要组成部分。
CMMI3过程改进分析报告
CMMI3过程改进分析报告第一篇：CMMI3 过程改进分析报告过程改进分析报告XXXXX是一家以软件研发和解决方案销售的信息技术有限公司，公司以互联网技术和基于组件的软件开发技术为核心，为客户提供定制软件开发及维护服务。
公司组建了EPG过程改进小组、品质保证组，并正式启动了基于CMMI的软件过程改进进程。
EPG过程改进小组对公司软件开发过程与公司运营过程的分析和探讨，制定了一套适合于公司实际的组织标准过程定义。
组织标准过程定义选定项目中进行了样本试验，在包括研创中心内推广，取得了一定的成效。
公司按照CMMI3的标准对过程改进管理、并与外部咨询机构签订咨询合同聘请资深咨询顾问通过深入了解公司的过程改进目标及现状，帮助EPG过程改进小组制定相应的实施计划，跟进实施计划及现状提供相应的培训，并在定义或改进过程时提供有力的支持。
在CMMI过程改进之前需求频繁变更没有得到及时的记录，也缺乏对需求变更的分析和管理，导致项目的返工率增加，以至延误项目的进度并造成成本的增加，测试人员不能得到最新的完整的需求，因而造成测试的遗漏，最终引起提交给客户的产品品质低下测试缺陷不是总得到记录（特别是单体测试时的缺陷），导致缺陷遗漏和缺陷数据不准确。
功能方面的测试点覆盖不全面，造成测试遗漏，提交给客户后被发现，质量低下客户投诉高、返工率高无法提高生产率，从而导致项目成本不断上升。
公司成立EPG过程改进小组，通过收集外部咨询机构人员、内部评审人员、QA和项目组成员的建议，制定了需求管理、品质管理、项目管理等改进计划：1、需求管理EPG过程改进小组制定了需求变更管理过程，在过程中要求使用表格来管理所有的需求变更，包括变更的内容、时间、原因、提出者、状态。
使用Q&A来记录与客户的交互信息，这些Q&A都得到了统一的保存。
负责需求的人员在每次变更时要召集所有项目的相关人员，对其进行分析以确定其影响程度和范围，对于超过组织定义的阈值的大变更只有在评审通过后，才可以被纳入系统，对于小变更也要得到记录，整个过程得到QA人员的监察和审核以确保过程得到严格的实施。
CMMI3级评估工作的总结
2.度量的部分最重要，度量的目标、内容一定要由组织级来定，而且要先定。
说到度量实在是惭愧啊，我被安排一直做PP、PMC、RSKM部分，这部分文档和模版我觉得做的不错，可是当我写试点项目文档时我才发现，天啊，这需要度量的内容怎么同数据统计的表格内容不对应呢？我需要查阅每个数据统计表格，拿张纸把每张表格的需要统计的几行记下来，在考虑哪天与哪天有对应关系，再分别做加、减法，天，我要晕，faint。根据我的聪明才智我发现既然我做项目级度量都这么困难，数据项都对应不上，那组织级好像没要求我们提供什么数据统计内容，组织级做度量的时候岂不更是无从下手吗？很不幸，我的感觉被证明It's true，真是做到度量才知道后悔啊，没办法，谁叫我们最开始的时候没有意识到要先确定度量目标呢？
2.在写文档前，应该知道CMMI都规定了哪些部分是一定要有的，哪些部分可以弱化，哪些部分可以没有。
我觉得做任何事情都要有目标，而且目标要切合实际。以CMMI过程改进来说，如果我们的目的就是过CMMI，就是为了CMMI而CMMI的话，那我们在写过程文档的时候就可以弱化能弱化的，删掉可以没有的，只保留必需要有的部分。否则，我们就应该参照企业现有的模式去认真的理顺项目各阶段工作，优化各阶段工作，提出按照企业现有的模式能够做出的CMMI过程文档和模版，最后，提出组织的过程改进建议，这个建议可以是企业结构的调整等（但通常企业结构的调整是很难的事情）。只有这样，CMMI的过程改进工作才能够顺利的开展并走向正规。
浅析CMMI-DEV,V1.3在二、三级过程域的变化
浅析CMMI-DEV,V1.3在二、三级过程域的变化摘要：本文介绍了CMMI-DEV,V1.3模型总体的变化并重点比较了V1.3与V1.2两个版本模型在二、三级过程域上的变化，为希望了解CMMI-DEV模型变化或者正在根据CMMI-DEV，V1.2进行过程改进的人士提供参考。
关键词：CMMI-DEV V1.3，过程域变化1 前言自从1994年SEI正式发布软件CMM以来，相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。
2000年，为了解决组织因为同时采用多种模型带来混乱等情况，SEI发布了CMMI模型。
之后模型不断的改进发展，大量组织从2006年开始使用CMMI-DEV V1.2模型进行过程改进，而在使用该模型时，使用者也发现模型存在着高成熟度描述不明确、某些细节不符合组织需要等问题。
SEI从2008年开始策划编写CMMI-DEV V1.3，经过三年的时间，在2010年11月发布了最新的模型。
模型的更新中除了明确了高成熟度要求外，还包含了二、三级过程域的修改，为CMMI模型的使用者提供了更清晰、更新的指导。
本文的目的是介绍二、三级过程域的变化，为熟悉CMMI模型、基于CMMI-DEV V1.2模型制定组织开发过程的人员提供参考。
2 模型变化综述CMMI-DEV V1.2版之前，各过程域能能力等级分为0至5共六级，通过评价是否满足通用目标4（GG4）及通用目标5（GG5）判断各过程域是否到达高成熟度。
在本次V1.3版本更新中，SEI将GG4及GG5从模型中去除，通过判断各过程域是否达到能力等级三（Capability Level3）以确定组织成熟度等级是否达到成熟度四级或五级（Maturity Level 4 and 5）。
除此以外，模型对GP2.6和GP3.2进行了修改。
GP2.6从原来的“管理配置项”变为“控制工作产品”，以免模型使用者误以为该实践要求使用配置管理工具管理所有选定的工作产品，关于模型对于“配置项”的描述变化，请见后文的配置管理过程域。
CMMI3_OPF_P0002_组织过程改进过程
密级：组织过程改进过程目录1.目的/方针 (1)2.范围 (1)3.术语 (1)4.角色与职责 (1)5.入口准则 (1)6.输入 (1)7.流程图 (2)8.主要活动 (3)8.1.识别过程改进 (3)8.2.过程改进策划 (4)8.3.过程改进实施 (5)8.4.评估组织过程 (5)9.出口准则 (6)10.引用文档 (6)11.使用模板 (6)1.目的/方针组织过程改进（(Organization Process Focus, OPF）的目的在于掌握组织的过程状态，识别过程改进机会，策划和实施本组织的过程改进活动。
EPG应遵循本过程识别整个组织的过程改进机会，以及策划和实施过程改进活动。
2.范围适用于组织的过程改进。
3.术语4.角色与职责5.入口准则●无6.输入●过程改进信息本过程包括2个规程：1、EPG章程2、管理评审规程8.主要活动组织根据《EPG章程》组建EPG并实施EPG的管理。
EPG负责组织的过程改进工作，包括识别过程改进、过程改进策划、过程改进实施、评估组织过程等活动。
8.1.识别过程改进●EPG通过各种渠道和方式收集改进信息，收集的渠道和方式有：✧营造一个激励持续改进的氛围与环境，收集和分析来自员工等相关方的合理化建议，识别改进机会；✧组织过程的改进目标；✧过程评估的结果；✧通过常规性内部审核、管理评审和各种持续的差距分析活动，不断发现组织过程的薄弱环节；✧通过测量和分析，找出顾客的不满意、产品未满足要求、过程不稳定等事项，分析识别改进机会；✧从监控组织和项目的过程活动的中得出的经验教训中分析识别改进机会；✧通过QA工程师，在日常工作中发现不符合或潜在不符合的事实，分析识别改进机会；✧其它渠道收集的改进信息。
收集的改进信息记录在《改进信息跟踪表》。
●EPG每月对收集的信息进行综合分析，识别组织过程的薄弱环节，确定改进的时机和改进的方式。
过程改进活动有两种方式：日常改进活动和周期性的过程改进活动。
SW—CMMI3及在企业中的实施
成 立项 目管 理 部 、 质量 保 障部 两 个 部 门 ： 企业 的软 件 过 程 的持 续 改 进 。 成 立 过程 改 进 工 作 指 导 委 员 会， 员 包 括 副 总经 理 、 个 相 成 各 在项 目实 施 初期 ． 现 的过 程 定 义 文档 问题 比较 多 ． 要 是 发 主 关 部 门经 理 ： 主要 职能 是 制 订 实施 Ｃ Ｉ进 行 软 件 过 程 改 进 的 文档 和 实 际 情 况 的一 些 差 距 ， 过 Ｅ Ｇ 的不 断修 改 文 档 、 目 ＭＭ 、 通 Ｐ 项 战略 方 向 和计 划 ， 提供 资 源 和指 导实 施 ： 试 点 和 推 广 。 步 解决 问题 。 善 了 企业 的标 准 软件 过程 。 逐 完 成 立 过 程 改 进 工 作 工 程 过程 组 （ Ｐ 。 Ｅ Ｇ） 以项 目管 理 部 为主 。 ６７阶段 ６ 预 评 估 （ 时一 周 ） ． ： 历 同 时抽 调 部 分 其 它 部 门 人 员 兼 职 ．主 要 职 能 是 具 体 负 责 Ｃ ＭＭＩ 通 过 预 评 估 来 判 定 企 业 是 否 准 备 充 分 可 以 进 行 正 式 的 软件 过 程 改进 的实 施 ： Ｓ Ａ Ｐ 评 估 。 时对 企 业 的能 力 成 熟 度 进 行初 步 了解 ． 别 明 Ｃ ＭＩ 同 识
软 件 过 程 能力 是 软 件 过 程 本 身具 有 的按 预 定 计 划 生 产 产 品 的 固 有能力。
２４组 织 的成 熟 度 ． 表 示 一 组过 程 的 综 合 能力 。 对 一 组 过程 ． 映一 组过 程 的 针 反 特征。
cmmi,3级软件过程改进方法与规范
竭诚为您提供优质文档/双击可除cmmi,3级软件过程改进方法与规范篇一：cmmi过程改进的两种方法1、2、cmmi过程改进的两种方法阶段表示为过程改进提供了一个预定义的路线图，即从成熟等级1到成熟度等级5逐渐增加，要达到一成熟度等级，必须满足该等级（及其以下等级）上所有的过程域的目标连续表示支持单个过程域的改进，可理解为一个过程域接着一个过程域实施改进。
在每个过程域上能力等级0到能力等级5逐级增加3、cmmi的全称，软件能力成熟度模型。
4、过程的作用过程是决定产品成本、进度和质量的主要因素5、过程改进的生命周期模型-ideal模型5、cmmi过程改进流程6、过程改进的目的7、过程改进的好处8、过程改进的原则篇二：cmmi3级软件过程第18章质量保证第18章质量保证质量保证（qualityassurance，qa）的目的是提供一种有效的人员组织形式和管理方法，通过客观地检查和监控“过程质量”与“产品质量”，从而实现持续地改进质量。
质量保证是一种有计划的、贯穿于整个产品生命周期的质量管理方法。
质量保证过程域是spp模型的重要组成部分。
本规范阐述了质量保证过程域的3各主要规程：☆制定质量保证计划[spp-pRoc-qa-planning]。
☆过程与产品质量检查[spp-pRoc-qa-ppqc]。
☆问题跟踪与质量改进[spp-pRoc-qa-tRacking]。
上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内it企业的软件研发项目。
建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。
18.1介绍过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”，而“差的过程”将产生“差的产品”。
人们销售的是产品而不是过程，用户关心的是最终产品的质量，而开发者（团队）既要关心过程质量又要关心“产品质量”。
软件过程改进实践与案例
软件过程改进实践与案例在软件开发领域，软件过程改进是一个持续不断的过程。
它旨在提高软件开发过程的质量和效率，减少项目失败率，实现可持续发展。
本文将通过实例，介绍软件过程改进的实践方法，以期能够为软件开发人员提供一些有用的经验和思路。
一、软件过程改进的重要性过去，软件开发是一个相对较为薄弱的环节。
开发人员按照自己的经验和想法编写代码，缺乏持续和完整的开发流程管理。
导致软件项目常常出现字母代码、功能不完整、进度滞后等问题，直至项目终止。
随着时间的推移，越来越多的企业和团队开始重视软件开发质量，提高软件开发整体流程。
软件过程改进是一个持续不断的过程，通过该过程，可以有效提高软件开发的流程，减少出错率和工作时间。
简单地说，软件过程改进就是将软件开发流程标准化和细致化，这样可以准确地实现项目计划，提高软件开发质量和效率，减少错误率。
二、软件过程改进实践方法为了实现软件过程改进，我们需要根据软件开发流程的特点，采取相应的实践方法。
2.1、定制化实践方法不同软件开发过程有不同的特点和需求，因此需要根据实际情况进行定制化。
软件开发团队需要了解项目的特点和需求，科学地制定出软件过程改进计划。
该计划应包括：1）定位：明确软件过程改进的目标和计划，建立团队合作意识，为后续的具体实践铺平道路。
2）分析：了解团队的优势和不足，把握软件开发过程中出现的问题，建立软件过程改进的具体方案。
3）实施：根据制定的计划，开展软件过程改进实践工作，持续不断地推进团队的软件开发水平。
4）检测：通过实践方法对软件开发过程进行检测，并反思，为提高软件开发流程提供数据支持。
2.2、流程改进方法流程改进方法是一种系统化的方法，为软件过程改进提供支持。
它以“产品需求、开发、测试、维护”等流程为基础，重点考虑以下问题：1）流程编排：完善流程，科学地选择环节顺序和安排，合理分配任务，加强沟通和协作。
2）流程设计：实际开发中，我们应该把流程设计过程中的每个细节都考虑到，如需求分析、设计、开发、测试等方面。
CMMI文件-过程改进计划)
过程改进计划更改控制页目录1总论 (1)1.1概述 (1)1.2参考 (1)1.3定义和缩写 (1)2实施概要 (2)2.1发起人 (2)2.2改进范围 (2)2.2.1组织范围 (2)2.2.2模型范围 (2)2.3改进组织 (3)2.3.1管理指导组 (4)2.3.1.1角色 (4)2.3.1.2工作职责 (4)2.3.1.3成员构成 (4)2.3.1.4活动 (4)2.3.2质量管理部 (5)2.3.2.1角色与职责 (5)2.3.2.2活动 (5)2.3.3工程过程组 (5)2.3.3.1角色 (5)2.3.3.2工作职责 (5)2.3.3.3成员构成 (6)2.3.3.4活动 (6)2.3.4SPI推进组 (7)2.3.4.1职责 (7)2.3.4.2成员构成 (7)2.3.4.3活动 (7)2.3.5技术管理委员会 (7)2.3.5.1职责 (7)2.3.5.2成员构成 (8)2.3.6变更控制委员会 (8)2.3.6.1职责 (8)2.3.6.2成员构成 (8)2.3.7咨询公司 (8)2.3.7.1角色与职责 (8)2.3.7.2活动 (9)3诊断概述 (10)4SPI生命周期 (10)4.1准备和差距分析 (10)4.2CMMI L4过程域培训和专题培训 (12)4.3过程规范制订咨询指导 (13)4.4过程试运行咨询指导 (14)4.5CMMI L4SCAMPI预评估 (16)4.6CMMI L4SCAMPI正式评估 (19)5过程改进规划 (20)6假设和风险 (21)6.1假设 (21)6.2发起人地位和承诺 (22)6.3沟通 (22)6.4风险 (22)7过程文档化标准 (23)7.1制定过程手册 (23)7.2过程描述 (24)8过程改进的资源 (24)9过程改进状态和监管 (25)9.1MSG定期会议 (25)9.2EPG定期会议 (25)9.3度量 (26)1总论1.1概述本文描述了XXX科技有限公司，过程改进活动所采取的战略和战术的作业计划。
(完整版)CMMI过程改进计划
武汉中地数码科技有限公司过程改进计划Version x.x文档名称：ZD-CMMI-Templates-过程改进计划-YYYYMMDD.doc武汉中地数码科技有限公司版权所有不得复制过程改进计划修订历史记录序号日期版本号修改说明修改人评审人批准人1.2014-4-15 0.1 初次撰写李叶繁王洪涛2.2014-4-30 1.0 CMMI3级改进计划定稿王洪涛EPG 周顺平3.2014-7-2 2.0 按公司实际情况，参考咨询师过程改进实施计划调整结束日期至2015年3月王洪涛EPG 周顺平4. 5. 6. 7. 8. 9.目录1. 引言 (1)1.1 文档目的 (1)1.2 改进背景与总体目标 (1)1.3 工作原则 (1)1.4 术语及定义 (2)1.5 参考文献 (2)2. 改进目标 (2)2.1 现状及问题分析 (2)2.2 商业目标 (3)2.3 近期目标 (3)2.4 中长期目标 (4)3 改进机构与职责 (5)3.1 组织机构及范围 (5)3.2 高层管理指导委员会（MSG） (5)3.2.1 最高管理者 (5)3.2.2 管理者代表 (6)3.2.3 高层委员会 (6)3.3 工程过程组（EPG） (6)3.3.1 EPG Leader（EPG组长） (6)3.3.2 EPG成员 (7)3.4 过程改进顾问 (7)3.4.1 外部顾问 (7)3.4.2 内部顾问 (7)3.5 过程改进项目QA (7)3.6 工作组（Working Group） (8)3.6.1 试点项目项目经理 (8)3.6.2 配置管理员（CMO） (8)3.6.3 培训专员（OT） (9)3.7 沟通协调组 (9)4 进度计划 (9)5 成功标准及资源需求 (9)5.1 成功标准 (9)5.2 资源需求 (10)6 沟通计划 (10)6.1 工作例会 (10)6.2 工作报告 (10)6.3 工作审计 (10)7 假设与风险管理 (11)7.1 取得成功的条件假设 (11)7.2 阻碍项目成员的风险因素 (11)8 附录 (11)过程改进计划1. 引言1.1 文档目的【阐明编写计划的目的】本计划介绍了为提高武汉中地数码科技有限公司（以下简称“中地公司”）过程能力，而发起的过程改进活动，描述了管理该计划的基本架构，并定义了中地公司过程改进的方法、活动，是中地公司过程改进的指导蓝图。
基于CMMI的中小型软件企业过程改进问题研究
基于CMMI的中小型软件企业过程改进问题研究摘要：对中小软件企业进行了界定，指出CMMI模型应用于中小软件企业的局限性。
基于瀑布模型，采用SPP方法对CMMI 3模型进行了精简，对模型中过程域的流程进行了说明，精简后的模型适合于中小型软件企业。
关键词：中小软件企业；CMMI；过程改进本文采用的是CMMI-DEV1.2版本,共分为4类过程域:过程管理、项目管理、工程类和支持类。
每类过程域又分为基本过程域和高级过程域。
实施CMMI的好处很多，如规范软件开发过程，改进软件开发过程，有效控制项目进度、成本，减少软件缺陷等。
但对中小型软件企业来说，CMMI在实施过程中也有其局限性：①中小软件企业成员往往身兼多职,很难有专人进行质量保证(QA)工作；人员流动快，很难形成专职的过程改进团队；②资源缺乏，难以实现CMMI规定的那么多关键过程域，且没有实施指南；③CMMI主要考虑实施过程的完整性，而中小企业则主要关注快速反应能力和沟通能力，关注重点有所不同。
2构建中小型软件企业的过程改进模型2.1采用的基本理论基于瀑布模型，采用精简并行过程（SPP，Simplified Parallel Process），对CMMI 2级和3级的过程域进行“精简”，提出适合于中小企业的过程改进模型。
2.1.1瀑布模型瀑布模型是一种线性的开发模型，其基本思想是按工序将问题简化,将软件生命周期划分为制定计划、需求分析、软件设计、编程、测试和运行维护6个基本活动。
本文选择用瀑布模型进行研究，一方面是因为瀑布模型是目前软件行业最熟悉且熟练运用的周期模型，很多其他模型也是在此基础上发展起来的。
其次，大多数软件项目采用线性开发方法，中小企业尤其如此。
另一方面，项目管理过程与研发过程均可以按照瀑布模型划分阶段。
2.1.2CMMI 2和CMMI 3的关键过程域对于国内中小软件企业来说，能够达到2级或3级已经比较困难，故无需讨论更高级别的过程域。
CMMI-3集成测试报告-例子
某某区电子政务系统集成测试分析报告第一章简述1.1 测试内容某某区电子政务系统分外部门户网站、办公业务门户和办公OA系统三大组成部分。
对该三大组成部分分别作如下测试。
极限测试：由每个模块使用大致对应数目的虚拟用户逐渐按比例加压，记录能正常工作的情况下的最大用户。
响应时间测试：测试实时页面和含有控件的页面响应时间。
实时页面的响应时间不超过3秒，有控件加载的页面的响应时间不超过7秒。
运行环境测试：测试该系统在需求规格说明书所明确的软硬件环境下能否正常运行。
1.2 测试环境●服务器一台：曙光天阔S240-Xp4Cpu 2.0g hz X 4内存 2.0g硬盘80g操作系统：应用服务器：数据库服务器：JA V A环境JRE1.5_04或以上版本●客户端4-5台：兼容机Cpu 1.8g hz内存512M硬盘40g操作系统WINDOWS2000网页浏览器 IE6.0或以上版本●测试模拟和测试监控测序loadrunner 8.01.3 测试进度安排测试环境的搭建●测试环境的搭建：半天，选择一台服务器，4-5台客户端，如果操作系统不一致的必须从新安装，服务器上安装某某区电子政务系统，所有客户端安装LoadRunner8,安装类型选择Standalone Installation，安装方式选择Custom Installation。
以服务器系统能访问，客户端LoadRunner能运行为标准判断该阶段是否完成。
●外部门户网站模块的测试：2天，进行脚本录制，及修改测试脚本。
提取部分打开实时页面和含有控件页面的步骤包含入事务，实时页面事务标注为index_rlt_ 序号,含有控件页面事务标注为index_ctrl_序号, 所有脚本一起进行极限测试。
●内网站模块的测试：2天，进行脚本录制，及修改测试脚本。
提取部分打开实时页面和含有控件页面的步骤包含入事务，实时页面事务标注为index_rlt_ 序号,含有控件页面事务标注为index_ctrl_序号。
CMMI3_实践篇解读
predictable
Software quality management Quantitative process management
Defined (3)
standard & consistent
Peer reviews Intergroup coordination Software product engineering Integrated software management Training program Organization process definition Organization process focus
项目管理—启动
项目里程碑
阶段 开始时间 内部测试（SIT） 2012年7月2日 产物 1、测试案例（集成、冒烟、系统） 2、集成测试报告 完成程序代码 3、测试案例评审报告 的集成测试系 2012年7月19日 4、系统问题单记录 统测试，并通 5、系统测试报告 过测试评审 6、冒烟测试报告 结束时间 目标
诊断当前过程并识别要解决的问题
——确定评估的正式性
A级：正式的，报告给SEI，最高层支持，来自组织的全力参与
B级：不是很正式，不向SEI报告，中等级别支持，要求组织的 参与要少一些。
C级：更非正式一些，不向SEI报告，支持可能在单元或小组的
一层，参与可限于SEPG或其他。
Part1 计划过程改进 诊断当前过程并识别要解决的问题 ——选择评估方法
培训内容
1、计划过程改进 2、SCAMPI评估方法介绍 3、CMM和CMMI的比对 4、在过程改进中成功
Improving the model
Optimizing (5)
CMMI3级过程改进案例分析
0403
0405
0407
0409
0501
0504
0505
0507
0507
0508
0509
0511
0601
0603
0605
0606
-40.00%
-60.00%
-80.00%
-100.00% 时间
过程推广
从图中可以看出，过程推广后由于项目使用了发布的估算方法进行估算和计划工作量，计划与实际 的工作量的偏差值逐渐地趋向于组织定义的阈值(-10--- 10%)。过程推广前项目的工作量偏差值在 -80%--- 80%之间振荡，过程推广后项目的工期偏差值在-30--- 20%之间震荡。
-40%--- 80%之间振荡，过程推广后项目的工期偏差值在-10--- 20%之间震荡。
16
CMMI3级过程改进案例分析报告
CMMI过程改进的成果和收益(项目管理二)
误差率
100.00%
案例分析－－工作量差距
80.00%
60.00%
40.00%
20.00%
0.00% 0402
-20.00%
0403
14
CMMI3级过程改进案例分析报告
CMMI过程改进的成果和收益(品质管理)
案例分析－－缺陷率（每千行）
12.00
10.00
8.00
6.00
cutover缺陷率
4.00
2004年数据无法采集
2.00
过程推广
0.00
04年2月 04年6月 04年10月 05年5月 05年7月
05年9月 05年11月 05年11月 06年3月 06年4月 06年5月
80.00%
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
-40.00%
-60.00%
-80.00%
-100.00%
时间
过程推广 从图中可以看出，过程推广后由于项目使用了发布的估算方法进行估算和计划工作量， 从图中可以看出，过程推广后由于项目使用了发布的估算方法进行估算和计划工作量，计划与实 际的工作量的偏差值逐渐地趋向于组织定义的阈值( 10--- 10%)。 际的工作量的偏差值逐渐地趋向于组织定义的阈值(-10--- 10%)。过程推广前项目的工作量偏差值在 80%--- 80%之间振荡 过程推广后项目的工期偏差值在-30--- 20%之间震荡 之间振荡， 之间震荡。 -80%--- 80%之间振荡，过程推广后项目的工期偏差值在-30--- 20%之间震荡。 17
8
CMMI3级过程改进案例分析报告
CMMI过程改进之前存在的问题(品质管理 品质管理) 品质管理
1. 测试缺陷不是总得到记录（特别是单体测试时的缺 陷），导致缺陷遗漏和缺陷数据不准确。 2. 功能方面的测试点覆盖不全面，造成测试遗漏，提交 给客户后被发现
9
CMMI3级过程改进案例分析报告
CMMI过程改进之前存在的问题(项目管理 项目管理) 项目管理
14
CMMI3级过程改进案例分析报告
CMMI过程改进的成果和收益(品质管理 品质管理) 品质管理
案例分析－－缺陷率（每千行）
12.00
10.00
8.00
6.00
cutover缺陷率
4.00
2004年数据无法采集
2.00
过程推广
0.00 04年2月 04年6月 04年10月 05年5月 05年7月 05年9月 05年11月 05年11月 06年3月 06年4月 06年5月
21
CMMI3级过程改进案例分析报告
谢谢!
22
组织介绍
1. 北京利众得应用技术有限公司的前身为北京一希望信息技术有 限公司 2. 北京一希望成立于2002年，除北京以外还在上海和大连设有分 公司 3. 2006年2月因为股权变更而正式更名为北京利众得应用技术有 限公司 4. 公司以互联网技术和基于组件的软件开发(CBSD)技术为核心， 为客户提供定制软件开发及维护服务 5. 公司自主产品cLearning学习管理系统软件V1.0获得北京科委 颁发的软件产品登记证书
10
CMMI3级过程改进案例分析报告
CMMI过程改进实施方案(需求管理 需求管理) 需求管理
1. 制定了需求变更管理过程，在过程中要求使用表格来管理所有 的需求变更，包括变更的内容、时间、原因、提出者、状态 2. 使用Q&A来记录与客户的交互信息，这些Q&A都得到了统一的保 存。负责需求的人员在每次变更时要召集所有项目的相关人员， 对其进行分析以确定其影响程度和范围，对于超过组织定义的 阈值的大变更只有在评审通过后，才可以被纳入系统，对于小 变更也要得到记录 3. 整个过程得到QA人员的监察和审核以确保过程得到严格的实施
19
CMMI3级过程改进案例分析报告
经验教训
1. CMO定期发布“新闻快递”，可以使得组织内的所有人员关 注、了解并积极地参与到过程改进工作中去 2. 邀请项目经理加入到EPG的工作中，既能够为过程改进提供 有实际效益的改进建议，又能够在日后项目实施时快速地理 解并有效地执行过程 3. 尽早地借助外部力量（如咨询公司、培训机构等）为我们的 过程改进工作提供支持和提出有益的建议 4. 过程改进是全员参与的活动，任何一个环节都不可或缺
CMMI3级过程改进案例分析报告
CMMI过程改进的成果和收益(项目管理三)
通过以下方式使得项目的可视性增强，上级管理者能够 及时了解项目的执行状况，并对项目中存在的问题及时地进 行协调解决，极大地降低了项目的风险： A. 成立了项目管理委员会,每周对项目进行评审，并参与项 目的阶段评审 B. 项目经理每周的项目周报 C. QA人员每周的QA周报
20
CMMI3级过程改进案例分析报告
下一步工作
过程改进工作将持续进行下去： 过程修订： 1. 过程修订：使过程的描述更加生动、更易于理解和执
行
工具开发： 2. 工具开发：流程自动化，降低项目管理和开发的工作
量
过程实施： 3. 过程实施：加强培训和指导，同时加强QA的监察和审
核的力度
评估： 4. 评估：按计划继续向更高一级的目标而努力
11
CMMI3级过程改进案例分析报告
CMMI过程改进实施方案(品质管理 品质管理) 品质管理
1. 使用“Bugzilla”和“缺陷列表”记录缺陷数据以减 少缺陷遗漏，使用“项目度量数据”对缺陷进行分析， 在测试结束时对缺陷的准确率进行评审。QA人员也要 严格监察此活动 2. 改进评审方法，使用同级互查的方式，并在评审中使 用“评审检查表”，尽早发现问题 3. 建立测试用例和需求之间的追溯关系，确保所有的需 求都被相应的测试用例所覆盖，并加强对测试用例的 同级互查以确保充分的测试覆盖率
因为在过程推广之前，没能采集到缺陷数和代码行数，从过程推广后采集的数据可以看出， 因为在过程推广之前，没能采集到缺陷数和代码行数，从过程推广后采集的数据可以看出， 提交给客 户后产品的缺陷率在过程改进中逐渐地降低，基本趋向于组织定义的阈值：每千行代码3个缺陷。 户后产品的缺陷率在过程改进中逐渐地降低，基本趋向于组织定义的阈值：每千行代码3个缺陷。 15
-80.00%
时间
过程推广
从图中可以看出，过程推广后由于项目使用了发布的估算方法进行估算和计划工期， 从图中可以看出，过程推广后由于项目使用了发布的估算方法进行估算和计划工期，计划与实 际的工期的偏差值逐渐地趋向于组织定义的阈值( 10--- 10%)。过程推广前项目的工期偏差值在际的工期的偏差值逐渐地趋向于组织定义的阈值(-10--- 10%)。过程推广前项目的工期偏差值在40%--- 80%之间振荡 过程推广后项目的工期偏差值在-10--- 20%之间震荡 之间振荡， 之间震荡。 40%--- 80%之间振荡，过程推广后项目的工期偏差值在-10--- 20%之间震荡。 16
18
CMMI3级过程改进案例分析报告
CMMI过程改进的成果和收益
(其它：度量数据的积累) 其它：度量数据的积累 其它 1. 随着过程改进进程的不断深入，我们获取了一系列的 项目和组织度量数据,如:工期的估计和实际数据,工作 量的估计和实际数据以及它们的偏差、缺陷率、生产 率等等。 2. 通过对收集的数据进行分析，以帮助判断组织运营和 项目开发能力达到了怎样的水平 3. 也为以后的项目提供了足够的参考数据，有利于项目 的有序执行
CMMI3级过程改进案例分析报告
CMMI过程改进的成果和收益(项目管理二)
案例分析－－工作量差距
100.00%
80.00%
60.00%
40.00%
20.00%
误差率
0.00% 0402 -20.00% 0403 0403 0405 0407 0409 0501 0504 0505 0507 0507 0508 0509 0511 0601 0603 0605 0606
3
CMMI3级过程改进案例分析报告
过程改进进程图示
4
CMMI3级过程改进案例分析报告
过程改进简介(一)
1. 2004年初组建了能力管理委员会、项目管理委员会、工程 过程组、品质保证组，并正式启动了基于CMMI的软件过程 改进进程 2. 能力管理委员会和工程过程组致力于对公司软件开发过程 与公司运营过程的分析和探讨，制定了一套适合于公司实 际的组织标准过程定义 3. 项目管理委员会和品质保证组致力于项目实施中过程的推 广和把握 4. 组织标准过程定义于2005年1月在选定项目中进行了样本试 验,于2005年6月在包括北京、上海、大连三地的全公司范 围内推广，取得了一定的成效
6
CMMI3级过程改进案例分析报告
过程改进简介(三)
7. 2005年7月到2006年3月间,公司进行了三次预评估，根 据预评估结果对过程进行修订和推广，进一步提高公 司整体的软件开发能力 8. 改进过程中，公司员工总数为116人，先后参加CMMI预 评估和正式评估的项目总数为13个，参加最终评估的 项目为4个，参加最终评估面谈的员工总数为33人 9. 2006 年4 月，公司进行了SCAMPI CLASS A评估，评估 的结果展示了CMMI 3级的能力水平
7
CMMI3级过程改进案例分析报告
CMMI过程改进之前存在的问题(需求管理 需求管理) 需求管理
1. 需求频繁变更，没有得到及时的记录，也缺乏对需求 变更的分析和管理，导致项目的返工率增加， 以至延 误项目的进度并造成成本的增加 2. 测试人员不能得到最新的完整的需求，因而造成测试 的遗漏，最终引起提交给客户的产品品质低下
CMMI3级过程改进 CMMI3级过程改进
案例分析报告
1
CMMI3级过程改进案例分析报告
目录 1. 组织介绍 2. 过程改进简介 3. CMMI过程改进之前存在的问题 4. CMMI过程改进的实施方案 5. CMMI过程改进的成果和收益 6. 经验教训 7. 下一步工作
2
CMMI3级过程改进案例分析报告
CMMI3级过程改进案例分析报告
CMMI过程改进的成果和收益(项目管理一)
100.00%
案例分析－－工期误差率
80.00%
60.00%
40.00%
误差率
20.00%
0.00% 0402 -20.00% 0407 0501 0502 0507 0509 0510 0601 0604
-40.00%
-60.00%
5
CMMI3级过程改进案例分析报告
过程改进简介(二)
5. 2005年5月与循序咨询签订CMMI咨询合同，标志着公司 开始借助外部力量进一步完善我们的过程改进工作， 并设定了通过CMMI3级评估的阶段目标 6. 循序的资深咨询顾问通过深入了解公司的过程改进目 标及现状，帮助制定相应的实施计划，根据实施计划 及现状提供相应的培训，ቤተ መጻሕፍቲ ባይዱ在定义或改进过程时提供 有力的支持