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从原来的“管理配置项”变为“控制工作产品”，以免模型使用者误以为该实践要求使用配置管理工具管理所有选定的工作产品，关于模型对于“配置项”的描述变化，请见后文的配置管理过程域。
- 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. 循序的资深咨询顾问通过深入了解公司的过程改进目 标及现状，帮助制定相应的实施计划，根据实施计划 及现状提供相应的培训，ቤተ መጻሕፍቲ ባይዱ在定义或改进过程时提供 有力的支持