CMMI的组织结构
CMMI的组织结构一般在最高领导之下设立EPG（Engineering Process Group, 工程过程组）、QA（Quality Assurance, 质量保证组）、EG（Engineering Group, 工程组），这三个组的构成就好像是立法、监督和执法的制衡体系，体现了西方的法治观念。EPG源于SEPG（Software Engineering Process Group, 软件工程过程组），本是组织中专职推进CMM的职能单位，随着CMM发展到CMMI，内容更加广泛，EPG的职能就是组织的过程改进。
CMMI的两种实施方法
CMMI有两种不同的实施方法，不同的实施方法，其级别表示不同的内容。CMMI的一实施方法为连续式，主要是衡量一个企业的项目能力。企业在接受评估时可以选择自己希望评估的项目来进行评估。因为是企业自己挑选项目，其评估通过的可能性就较大一点。但是，它反映的内容也比较窄一点。它仅仅表示企业在该项目或类似项目的实施能力达到了某一等级。而另一种实施方法为阶段性。它主要是衡量一个企业的成熟度，亦即是企业在项目实施上的综合实力。企业在进行评估时，一定要由评估师来挑选企业内部的任何项目，甚至于任何项目的任何部分。一般地讲，一个企业要想在阶段性评估中得到三级，其企业内部的大部分项目要达到三级，小部分项目可以在二级，但绝不能够有一级。阶段性实施方法的难度要大一些。我们熟悉的SW-CMM软件能力成熟模型就是是阶段式的模型，SE-CMM系统工程模型是连续式模型，而IPD-CMM集成产品开发模型结合了阶段式和连续式两者的特点。
虽然，CMMI的表述方式不同，但其实质内容是完全一样的。是同一种方法的两种不同的表述方式。企业在准备评估时要做的准备工作也是完全一样的。这些工作对企业的管理上的帮助也是一样的。因此，不管企业需要做什么样的评估，企业所获取的实惠应该是差别不大。具体要做连续性评估，还是做阶段性评估则要看企业对等级评估证书的具体要求。
实施流程
阶段1：CMMI项目启动会
明确企业实施CMMI的商业目标，建立CMMI项目实施的沟通机制。
阶段2：CMMI基础培训和过程改进小组（EPG）组建
进行CMMI基础概念讲解，指导企业建立核心的过程改进小组。
阶段3：诊断
充分了解企业研发过程现状，识别企业现有软件过程与企业现阶段理应达到的的CMMI成熟度级别的差距，提交诊断报告，进行过程改进的策划。
阶段4：过程域培训和文件定义
结合企业过程现状进行CMMI过程域培训，通过举例、案例分析等方式，让企业的EPG掌握过程文件定义技巧，结合企业实际情况有针对性的定义组织的研发过程，并确定过程产出物（如：需求报告）
阶段5：项目试点
选择代表公司核心业务的项目或者典型项目进行试点，通过试点来完善过程文件，从而为企业全面推广过程文件打下基础。
阶段6：组织推广
全员参与全面导入与执行CMMI。
阶段7：预评估
验证组织推广的结果，识别企业尚存缺陷并制定再次改善方案，准备充分，以便企业能够更好进行正式SCAMPI 评估。
阶段8：SCAMPI正式评估
由SEI授权的主任评估师领导，采用SCAMPI ( Standard CMMI Appraisal Method for Process Improvement)评估方法，对企业的能力成熟度进行正式的评估，颁发证书，通过SEI网站向全球发布企业信息。
实施CMMI易犯的8个错误[1]
自从CMMI被引进国内以后，越来越多的企业实施了CMMI。但是真正取得良好收益的企业不多见。亚远景科技总结了几十个CMMI案例后，发现了实施CMMI过程中容易犯的8个错误。如果企业能过有效规避这些错误，就能够顺利实施CMMI，并取得良好效果。
1、企业高层不重视
这是最重要的一点。公司高层领导对CMMI实施不够重视，没有提供足够的资源，同时监督参与不够，就会直接影响实施的效果。如果缺少了企业高层的支持，体系的推广是很困难的的，所以必须使高层充分认识实施CMMI对企业长
期发展的的重要性。
2、人员素质不够
关键过程改进实施人员例如EPG组长，CM和PPQA人员在管理经验及技术实力上不足以担负其职责，没有足够的软件工程背景，在组织中亦无足够的能力获得足够的威信，则可能导致项目人员不理解不支持过程改进工作，其结果将直接导致实施项目失败，或者在评估时暴露太多严重问题，从而决定性的影响整个评估工作。必须选择那些有经验、有能力、有威望的员工参与的实施过程中来，充分发挥他们在企业里的正面影响力。
3、依赖顾问的文档
EPG成员过于依赖顾问提供的参考文档，对CMMI的模型学习不够，没有花必要的时间构造企业自己的过程文件，使过程文件的不能很好地适应企业的实际情况。必须提高EPG对参与CMMI实施工作价值的认识，培养EPG的工作技能。只有真正理解了模型才能根据实际进行裁剪，才能不机械照搬CMMI条文或其他企业的标准过程。
4、没有循序渐进
过程改进不是推倒重来，而是应该在企业原来的基础上发现不足，循序渐进。员工学习新的知识，企业建立新的体系都需要时间，拔苗助长是不切实际的。过程改进不是只为了取得证书，企业应当制定长期的过程改进计划，一步步不断完善自己的研发体系。
5、员工有抵触情绪
员工对实施CMMI的目的没有认同，新流程实施与原有开发习惯不同，开发人员有抵触，认为新增加的过程文件和模板没有实际作用。必须加强培训，使员工了解CMMI能够带来的好处；同时设计合理有效的过程文件和模版，减少形式主义的没有用处的工作；建立过程改进激励机制，使员工乐于参与过程改进。
6、CMMI实施计划变动
由于市场压力和项目交货期的压力，CMMI实施计划不能保证，工作被推迟或者减少。企业领导和全体相关人员必须充分认识这一风险，通过CMMI的项目管理，合理计划、分配和使用资源。选择咨询管理成熟的公司，提前安排和计划工作资源。
7、没有过程改进定期汇报机制
如果组织内部未建立过程改进定期汇报机制，关注过程改进、实施及过程表现情况，那么首先不能满足模型本身的要求，同时也会给组织人员造成管理层不重视，进而对组织过程改进漠不关心的现象。
8、工具的使用
有的公司全凭手工来做，在不熟悉过程和模板的情况，导致增加很多工作量。也有的公司大量使用工具，但是在使用之前未给项目组做充分的培训，导致项目快结束了，项目组还在修正或者弥补项目因为不能正确使用工具所产生的问题或者困难。
CMMI的五个台阶
台阶一：CMMI一级，完成级。在完成级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。
台阶二：CMMI二级，管理级。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列的管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。
台阶三：CMMI三级，定义级。在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化。这样，企业不仅能够在同类的项目上生到成功的实施，在不同类的项目上一样能够得到成功的实施。科学的管理成为企业的一种文化，企业的组织财富。
台阶四：CMMI四级，量化管理级。在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。对管理流程要做到量化与数字化。通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。
台阶五：CMMI五级，优化级。在优化级水平上，企业的项目管理达到了最高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程，运用新技术，实现流程的优化。
由上述的五个台阶我们可以看出，每一个台阶都是上面一阶台阶的基石。要上高层台阶必须首先踏上较低一层台阶。企业在实施CMMI的时候，路要一步一步地走。一般地讲，应该先从二级入手。在管理上下功夫。争取最终实现
CMMI的第五级。
等级
1．初始级
软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。
2．可重复级
建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
3．已定义级
已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。
4．量化管理级
分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。
5．优化管理级
过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。
每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性：
每个等级都有几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。
评估方法
自1991年起，CMM出现了很多模型，覆盖了各种各样的专业领域。其中著名的模型有系统工程·软件工程·软件采购·集成产品和流程开发等。然而当企业想要在组织内不同专业领域的流程改进，这些针对不同专业领域的模型在架构·内容和方法上的不同限制了组织成功实施改进的能力。此外，将这样模型在组织内部集成也提高了培训·认证和改进的费用。一套包括多个专业领域的模型加上整合的培训和认证支持将解决这些问题。
CMMI(Capability maturity model integration)是为了合并三个模型到一个框架中
Capability Maturity Model for Software (SW-CMM) v2.0 draft C,
Electronic Industries Alliance Interim Standard (EIA/IS) 731
Integrated Product Development Capability Maturity Model (IPD-CMM) v0.98
正如其他CMM模型，CMMI提供了流程改进的指导，而不是流程或流程的描述。组织使用的实际流程取决于很多因素，包括应用领域·组织框架和规模。CMMI将许多经过验证的方法加入架构中，来帮组组织评价成熟度·某个软件流程的能力度，并且建立改进的优先顺序和实施改进。
从CMMI框架可以产生不同的CMMI模型，因此必须首先确定那种模型最适合企业流程改进的需要。
阶段式描述or 连续式描述
系统工程or 软件工程or 两者皆有
使用连续式描述可以根据企业需要选择流程改进顺序，降低企业风险，这给通过ISO做流程改进提供了一个方便的比较。使用能力度(Capability)来衡量。
阶段式描述提供了已经过验证的流程改进顺序，方便从CMM移植过来。使用成熟度(Maturity)来衡量流程改进。
系统工程包括整个系统的开发，可能包括软件也可能不包括。
软件工程用于软件系统的开发，主要集中在使用系统的·科学的·量化的方法来开发·运行·维护软件。
与CMM差别
CMMI 模型的前身是SW-CMM 和SE-CMM，前者就是我们指的CMM。CMMI与SW-CMM的主要区别就是覆盖了许多领域；到目前为止包括四个下面领域：
（1）、软件工程（SW-CMM）
软件工程的对象是软件系统的开发活动，要求实现软件开发、运行、维护活动系统化、制度化、量化。
（2）、系统工程（SE-CMM）
系统工程的对象是全套系统的开发活动，可能包括也可能不包括软件。系统工程的核心是将客户的需求、期望和约束条件转化为产品解决方案，并对解决方案的实现提供全程的支持。
（3）、集成的产品和过程开发（IPPD-CMM）
集成的产品和过程开发是指在产品生命周期中，通过所有相关人员的通力合作，采用系统化的进程来更好地满足客户的需求、期望和要求。如果项目或企业选择IPPD进程，则需要选用模型中所有与IPPD相关的实践。
（4）、采购（SS-CMM）
采购的内容适用于那些供应商的行为对项目的成功与否起到关键作用的项目。主要内容包括：识别并评价产品的潜在来源、确定需要采购的产品的目标供应商、监控并分析供应商的实施过程、评价供应商提供的工作产品以及对供应协议很供应关系进行适当的调整。
在以上模块中，企业可以选择软件工程，或系统工程，也可以都选择。集成的产品和过程开发和采购主要是配合软件工程和系统工程的内容使用。例如，纯软件企业可以选择CMMI中的软件工程的内容；设备制造企业可以选择系统工程和采购；集成的企业可以选择软件工程、系统工程和集成的产品和过程开发。CMMI中的大部分内容是适用各不同领域的，但是实施中会有显著的差别，因此模型中提供了"不同领域应用详解"。
CMM的基于活动的度量方法和瀑布过程的有次序的、基于活动的管理规范有非常密切的联系，更适合瀑布型的开发过程。而CMMI相对CMM更一步支持迭代开发过程和经济动机推动组织采用基于结果的方法：开发业务案例、构想和原型方案；细化后纳入基线结构、可用发布，最后定为现场版本的发布。虽然CMMI保留了基于活动的方法，它的确集成了软件产业内很多现代的最好的实践，因此它很大程度上淡化了和瀑布思想的联系。
在CMMI 模型中在保留了CMM阶段式模式的基础上，出现了连续式模型，这样可以帮助一个组织以及这个组织的客户更加客观和全面的了解它的过程成熟度。同时，连续模型的采用可以给一个组织在进行过程改进的时候带来更大的自主性，不用再象CMM 中一样，受到等级的严格限制。这种改进的好处是灵活性和客观性强，弱点在于由于缺乏指导，一个组织可能缺乏对关键过程域之间依赖关系的正确理解而片面的实施过程，造成一些过程成为空中楼阁，缺少其他过程的支撑。两种表现方式（连续的和阶段的）从他们所涵盖的过程区域上来说并没有不同，不同的是过程区域的组织方式以及对成熟度（能力）级别的判断方式。
CMMI 模型中比CMM 进一步强化了对需求的重视。在CMM 中，关于需求只有需求管理这一个关键过程域，也就是说，强调对有质量的需求进行管理，而如何获取需求则没有提出明确的要求。在CMMI的阶段模型中，3 级有一个独立的关键过程域叫做需求开发，提出了对如何获取优秀的需求的要求和方法。CMMI 模型对工程活动进行了一定的强化。在CMM中，只有3级中的软件产品工程和同行评审两个关键过程域是与工程过程密切相关的，而在CMMI 中，则将需求开发，验证，确认，技术解决方案，产品集成这些工程过程活动都作为单独的关键过程域进行了要求，从而在实践上提出了对工程的更高要求和更具体的指导。CMMI中还强调了风险管理。不像在CMM 中把风险的管理分散在项目计划和项目跟踪与监控中进行要求，CMMI3级里单独提出了一个独立的关键过程域叫做风险管理。
实施
现在很多企业因某种原因想做CMMI了，大体做法
1、决定实施CMMI
2、EPG接受培训，理解CMMI
3、EPG根据自己理解的CMMI和实际情况开发一大堆漂漂亮亮的过程文档、流程图、表格、模板、检查单、作业指南。
4、大家边听着EPG的解释(包括培训、答疑)，边执行这些过程标准，然后审计(内、外)
将目前的最佳实践记录下来、写下来、文档化下来。
很多新的EPG在做了一段时间后无奈的发现自己居然沦落成了一个过程标准解说员、甚至文档管理员。自己工作大部分时间是面对文档，或者督促别人写文档
EPG最主要的工作应该深入到研发第一线，帮助研发人员解决研发过程中面临的最严重的实际问题(当然是解决方案要上升到过程高度，而不应是单个问题或个人)，甚至哪怕是一些不严重但以你的项目经验知道该如何解决的问题上。总体说来就是掌握项目进展中的任何细微的技术难点要点，并主动记录下来。
为什么这么说呢?CMMI实施的主要宗旨就是以每个项目为采集数据的源头，达到企业整体效益提升和资源重用。真正有价值的东西，是需要一线人员在实际工作中遇到问题，解决问题，并总结问题，不是一个一线工作的流水帐。就象一份研发人员的日报。写了上午做什么，下午做什么。这对企业的积累有什么用处呢?他工作过程中，遇到什么问题，他是怎么解决的，走过什么弯路，实验过几种方法，失败了，失败的原因是什么，最后选择了什么方法，可能不是最好的，但完成了任务，达到了效率和资源分配的平衡。这些东西才可能是未来类似项目中，遇到类似问题时，可能有参考价值的。通常也是EPG个人职业生涯的技术积累。只有公司里每个员工，把自己认为最有价值的积累贡献出来。才可能达到公司有价值的积累。而决不是形式上写的上午下午每个小时的流水帐。
人员素质
1、明白什么是有价值的积累，先是对你个人，然后才是顺便帮公司做了积累。
2、深入一线，发现她们并忠实地记录她们。CMMI里的SP、GP，只是帮助你，提醒你在哪个环节，哪些东西可能是有价值了。你去收集一下，别视而不见了。因为还有一个企业和你个人的角度不同，立场不同的问题。例如，REQM 里收集需求，对个人技术方面的积累虽然不多，但对企业是至关重要的，一次需求变更，没详细写清楚，忘记了到客户那里去签字落实，可能就会给企业造成很大的损失。做为一个合格的EPG，是需要有这份责任和义务把每个环节都做到最好，这是职业道德所在。同时也是对自我延伸的一个好机会，学会一些和人的沟通，倾听，把专业的东西以平易的方式表达。这些也都算是EPG额外的收获。
通常情况下，为了按时按量完成项目，一线的骨干，对写日报、周报、文档都很不屑。EPG也很迁就，事后再补，这也不失为一个提高效率的好办法。但过去一个月半年了，我们正常人的记忆都能想象，很难记住细节。无非就是敷衍。这也在情理之中。你总不能让一个明天就要交东西的小组，今天晚上在通宵努力解决BUG的同时，还写什么报告，这也不尽人情。但作为EPG不能只把眼光集中在这妇人之心上。要想的更远。为什么会把项目推到这么晚，BUG还没解决完?难道要永远这样下去吗?项目中是有很多不可预测的因素，甚至是开发人员常说的"手气问题"，"人品问题"。但这些是需要控制的，也是通过经验可以控制的，所谓艺高人胆大。艺的高低，就是经验的积累决定的。
那怎么解决这种两难的问题呢?逼着技术骨干写心水，人家没时间也的确压力很大。不写，公司又得不到有效积累，积累的都是垃圾流水。有个公司的办法和经验到可以借鉴一下：
公司内部搞了个BBS，把不同类型的工作分成不同的组，有纯技术的，JA V A组，C++组等，也有PPT组，甚至动画组，界面组。大家把自己平时的工作积累FTP上去，甚至制作方法，遇到问题和解决方法的文档都丢上去，开始怎么想，用了多少套方案，最后选择了什么。自我感觉如何。把这些心路历程都写成文档。丢到阳光下，大家评论。用点击率和"顶"的人数来说明谁写的是心水，谁在写垃圾。大家都是一个公司的，很容易实名。直接纳入考核机制中。做为一线人员，大家也有动力来写，自己的聪明才智有了展现的平台，虚荣心和荷包都得到了相应的满足。何乐而不为呢?
EPG适时的评估大家的成果，并把他们分到项目里。帮助项目总结，甚至在平时遇到问题时，直接帮助技术人员做必要记录。项目进度松时，再督促项目人员完善内容。以达到对个人和公司积累的最大化。
EPG应该明白学习和积累是个终身的过程，对公司如此，对个人也是如此。CMMI是个辅助，辅助我们对公司做积累，也帮助我们个人做必要的积累。公司需要逐步走向更高的管理水平，发展平台。
CMMI的基本思想
1、解决软件项目过程改进难度增大问题
2、实现软件工程的并行与多学科组合
3、实现过程改进的最佳效益
原则
（1）、强调高层管理者的支持。过程改进往往也是由高层管理者认识和提出的，大力度的、一致的支持是过程改进的关键。
（2）、仔细确定改进目标，首先应该对给定时间内的所能完成的改进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看到对组织的效益。
（3）、选择最佳实践，应该基于组织现有的软件活动和过程财富，参考其他标准模型，取其精华去其糟粕，得到新的实践活动模型。
（4）、过程改进要与组织的商务目标一致，与发展战略紧密结合。
目标
（1）、为提高组织过程和管理产品开发、发布和维护能力提供保障。
（2）、帮助组织客观评价自身能力成熟度和过程域能力，为过程改进建立优先级以及执行过程改进。
方法
（1）、决定哪个CMMI模型等级最适合组织过程改进需要。
（2）、选择模型的表示法是连续式还是阶段式。
（3）、决定组织需要用到的模型中的知识领域。
（4）、类似CMM提出的过程改进6步，集成化过程改进分成：开始集成过程改进,建造集成改善平台，集成传统过程，启动新过程，进行改进评估。
内容
CMMI内容分为“Required”（必需的）、“Expected”（期望的）、“Informative”（提供信息的）三个级别，来衡量模
型包括的质量重要性和作用。最重要的是"要求"级别，是模型和过程改进的基础。第二级别"期望"在过程改进中起到主要作用，但是某些情况不是必须的可能不会出现在成功的组织模型中。"提供的信息"构成了模型的主要部分，为过程改进提供了有用的指导，在许多情况下他们对"必需"和"期望"的构件做了进一步说明。
"必需"的模型构件是目标，代表了过程改进想要达到的最终状态，它的实现表示了项目和过程控制已经达到了某种水平。当一个目标对应一个关键过程域，就称为"特定目标"；对应整个关键过程域就称为"公用目标"。整个CMMI 模型包括了54个特定目标，每个关键过程域都对应了一到四个特定目标。每个目标的描述都是非常简捷的，为了充分理解要求的目标就是扩展"期望"的构件。
"期望"的构件是方法，代表了达到目标的实践手段和补充认识。每个方法都能映射到一个目标上，当一个方法对一个目标是唯一就是"特定方法"；而能适用于所有目标时就是"公用方法"。CMMI模型包括了186个特定方法，每个目标有两到七个方法对应。
CMMI包括了10种"提供的信息"：目的，概括和总结了关键过程域的特定目标；介绍说明，介绍关键过程域的范围、性质和实际方法和影响等特征；引用，关键过程域之间的指向是通过引用；名字，表示了关键过程域的构件；方法和目标关系，关键过程域中方法映射到目标的关系表；注释，注释关键过程域的其他模型构件的信息来源；典型工作产品集，定义关键过程域中执行方法时候产生的工作产品；子方法，通过方法活动的分解和详细描述；学科扩充，CMMI对应学科是独立的，这里提供了对应特定学科的扩展；公用方法的详细描述，关键过程域中公用方法应用实践的详细描述。
CMMI提供了阶段式和连续式两种表示方法，但是这两种表示法在逻辑上是等价的。阶段式方法将模型表示威一系列"成熟度等级"阶段，每个阶段都有一组KPA指出一个组织应集中于何处以改善其组织过程，每个KPA用满足其目标的方法来描述，过程改进通过在一个特定的成熟度等级中满足所有KPA的目标而实现的。
连续式模型没有像阶段式那样的分散阶段，模型的KPA中的方法是当KPA的外部形式，并可应用于所有的KPA 中，通过实现公用方法来改进过程。它不专门指出目标，而是强调方法。组织可以根据自身情况适当裁剪连续模型并以确定的KPA为改进目标。
两种表示法的差异反应了为每个能力和成熟度等级描述过程而使用的方法，他们虽然描述的机制可能不同，但是两种表示方法通过采用公用的目标和方法作为"必需"的和"期望"的模型元素，而达到了相同的改善目的。
现在CMMI面临的一个挑战就是创建一个单一的模型，可以从连续和阶段两个角度进行观察，包含相同的过程改进基本信息；处理相同范围的一个CMMI过程能够产生相同的结论。统一的CMMI（U-CMMI）是指产生一个只有公用方法和支持他们的KPA组成的模型。当按一种概念性的可伸展的方式编写，并产生了用于定义组织的特定目标过程模版，定义的模版构件将定义一个模型以适用于任何工程或其他方面。
评估
预备工作
评估实践证明：在进行CMMI评估之前，制定一个正确的评估计划并将其文档化，确保有一个富有经验的、受过培训且具有适当资格的小组能被用来评估，为执行评估过程做准备，是十分必要的。
我们所说的文档化CMMI评估计划的结果，包括：要求，协定，估价，风险，剪裁方法，以及与评估相关的实际考虑（例如：日程安排，后勤，组织的背景信息）。此外，还应当获取并记录发起方对于CMMI评估计划的正式批准。在制定评估计划之前，应对CMMI评估输入中反映出来的协议文档化，该协议将有助于CMMI评估目标和关键评估计划参数的共同理解。在对驱动计划过程的关键参数达成共同理解的基础上，CMMI评估发起方和SCAMPI主任评估师应就评估计划达成一致；发起者和评估小组领导应就已计划的评估中技术和非技术细节达成一致。这个计划在执行其他的计划和准备阶段活动中需要进一步细化。
而通过CMMI评估小组的准备工作，将产生一支富有经验的、受过培训的且定位准确的小组准备执行CMMI评估任务。该小组的成员都应当获得了完成他们各自的任务所必备的知识，或者他们之前所拥有的知识被证实足以完成相关任务。评估小组领导者已经给每一个人提供了为完成他们各自的任务所需的对技能进行实践的机会，或者证实这些技能在过去已经得到了示范。小组成员相互了解，同时开始计划他们如何协调一致的工作。还应该做到：准备好的小组是为评估目标而服务的，小组的成员已提供培训且培训结果被记录，在必要的时候，对他们所做的因知识或技能不足的补救工作已经完成。我们认为，无论CMMI评估小组领导者是从头培训一支全新的评估小组，还是通过从富有经验的小组成员中选择来组建一个小组，确保他们与CMMI评估小组领导者能组成一个成功的集体是其责任。此外，在对CMMI评估进行的预备工作的过程中，我们还应当对模型剪裁的原则有所了解：
1.在某些应用中，计划模板和例行的程序能够根据评估的需要进行调整，这和当地的过程所有权一样，有助于交流；
2.一个结构化的计划工艺组有利于只有有限的评估经验的组织，这样一个工艺就像缓和策略样，对于发现风险是一个很有价值的机会；
3.案例研究材料提供了各种各样的选择来扩充小组培训内容以增强那些更需要培训的重点；
4.富有经验的评估小组领导者在没有案例分析的情况下，同样可以管理和模拟评估行为；
5.在小组所有已获得培训成员的集合中，对小组的建立工作进行管理以确保其团队凝聚力是十分重要的，因此，很多的小组建立练习是可以利用的，小组的规模、技能、组成部分都是本方法的裁剪内容；
6.所采用工具可以包括评估计划模板，样例，和计划模板中嵌入式的程序上的帮助，此外，为了估计评估约束的影响，估算工作表和方法也是很有用处的。
总之，CMMI评估是一个十分复杂的过程，更由于其具有的不确定性，在评估的实践中，一定要做到有备无患。真理来自于实践，我们相信，随着越来越多的软件组织着手CMMI评估，越来越多的成功经验将为我们所利用和借鉴。
研发过程如何进行裁剪
一、企业在应用过程裁剪时的常见问题
不论企业实施了ISO9001、CMMI、六西格玛，或是其它任何类型的质量管理体系，通常都会形成完整的公司级标准过程体系。但当项目经理需要在项目中使用这个已定义好的过程体系文件时，面对厚厚的过程文件往往无从下手，心中也充满疑虑：
1. 我的项目开发周期只有3个月，团队4、5个人，难道要完全按照公司定义的标准过程执行吗？如果必须执行所有的过程和子过程，生成所有要求的技术和管理文档，那项目的开发周期恐怕不是3个月，而是4、5个月了。那我的项目还能成功吗？
2. 我听说过“裁剪”这个词，不过到底是“裁剪”还是“裁减”，我还没有弄明白。即便弄明白了应该是“裁剪”，是Tailoring，而非“裁减”，可具体该怎么操作？我可以随心所欲将自己认为不必要的或者很费时费事的过程裁剪掉吗？
3. 如果公司有QA，也有《裁剪指南》，那就好办了，我可以在QA的帮助下使用《裁剪指南》裁剪得到项目的过程，执行就是了。但如果公司没有QA的角色，我就只能自己进行裁剪了。可是，裁减的结果需要有人批准吗？
在这里，我们假定完整的公司级标准过程体系是包括了企业的方针、过程、指南、模板和表单等一整套的体系。那么，项目经理该如何是好？
二、过程裁剪的目的和作用
建立裁剪指南的目的是用来指导项目对组织标准过程（Organizational Standard Process, OSP）进行裁剪，以形成符合项目特点的项目定义过程（Process Defined Process, PDP）。
组织标准过程是在企业的层面上描述的，它包括了开发一个完整产品/项目的全过程，以及相应的支撑过程，它是一个企业运作的过程的全集。因此，每个特定的项目都可能无法直接使用组织标准过程。比如，组织标准过程描述了开发一个系统级产品的完整过程，开发过程中包括了软件、硬件、结构、工业设计等开发过程。而某个特定项目仅仅包括纯软件的开发工作，在这种情况下，该项目无法也不应该盲目遵照执行完整的过程。或者，某个特定项目，项目的成功标准是按时交付，而客户要求的项目交付期特别短。为了达成这个目标，项目也不得不对过程进行裁剪以满足客户的需要。裁剪指南就是来帮助项目裁剪组织标准过程，以形成项目定义过程，使用项目定义过程来管理项目，实现项目的目标。
裁剪指南能确保所有项目在定义项目特定的工程活动、需求开发和管理、计划、监控、测量分析、配置管理、质量保证过程时有一个共同基础。裁剪指南主要可在以下方面指导项目：
1. 选择适当的生命周期（是组织标准过程中的一部分），由于各种生命周期模型在软件工程领域已经有深入的研究，业界对于瀑布模型、迭代模型、增量模型、螺旋模型的使用场合等也基本达成了共识。因此，项目只需要将项目的实际特点与生命周期模型的应用场合相匹配，选择合适的生命周期类型即可。
2. 剪裁组织标准过程和所选择的软件生命周期，使之符合项目的具体特点。
三、如何进行过程裁剪
1. 裁剪的原则
本文中多次提到“项目特点”一词，项目特点包括了：①项目规模，如大、中、小等，通常可以使用功能点（Function Point）或KLOC（千行代码）、单板数等单位进行度量；②项目类型，如开发、维护、功能增强等；③项目技术复杂度；④项目周期；⑤产品种类等要素。项目特点是裁剪依据和出发点。裁剪指南应包括以下的内容：
（1）. 明确可裁剪的对象。可裁剪对象确定了裁剪的范围，可裁剪对象不仅限于过程元素和活动，还包括标准、方法和工具、输出的工作产品及模板等。
（2）. 确定裁剪所考虑的要素。对于某个裁剪对象，其范围、频度、正式度等都是裁剪要素。如，对于已有类似开发经验的项目，可以适当减少过程培训、业务培训等活动；对于开发周期较短的项目，可以适当合并一些评审活动，如概要设计和详细设计评审合并进行。
项目在进行裁剪时，由于裁剪指南很难枚举所有的裁剪情况，因此有时还是需要项目经理和QA依据经验进行判断和决定，这时，最根本的依据就是项目的质量要求和对风险的考虑。首先要分析如果一旦裁剪掉某些活动，是否会给项目带来风险，带来多大的风险，以及是否影响项目质量目标的达成。然后综合考虑后才能决定是否裁剪，如何裁剪。另一方面，企业建立标准过程的目的不是为了“为了规范而规范”，而是为了提高过程和技术的重用。
因此，如果项目在裁剪时有很大的灵活度，每个项目定义的过程都很随意或者项目过程之间相似的内容很少，那么重用的目的就很难实现了。所以，规范度和灵活度是项目裁剪时需要平衡的另外两个要素。
概括之，过程裁剪的原则是：质量与风险并重，规范与灵活的平衡。
2. 裁剪的过程
裁剪过程有这样一些主要活动：
（1）. 根据组织标准过程和裁剪指南，进行过程裁剪，以符合项目特征。项目经理在QA的协助下完成该项工作。
（2）. 记录裁剪的理由，将裁剪的结果整理成项目定义过程文档。
（3）. EPG（工程过程组）审核裁剪理由和项目定义过程，并批准。审核的检查点主要包括：是否与组织标准过程一致，是否符合本项目的特点，是否记录了充分的裁剪理由。如果审核不通过，则重新进行过程裁剪，或进行修改。
（4）. 使用项目定义过程就是要基于项目定义过程制定项目计划，根据计划监控项目的实施。
3. 应避免的误区
(1) “裁剪”而非“裁减”
常常见到企业的过程体系中赫然存在一份《裁减指南》，员工也往往认为裁剪就是大刀阔斧地“减少”完整的过程要求。如果项目时间紧、缺乏资源，就可以这么做。这是一个认识的误区。
所谓“裁剪”就是量体裁衣，根据项目特点量身定做最适合项目的过程，以期项目用最经济的过程实现质量目标。对于一个开发周期超过1年的系统级产品的开发，公司定义的四大决策评审点：概念决策、计划决策、可获得性决策和生命周期决策，以及六大技术评审点，技术评审1至6，可能“一个都不能少”。而对于一个快速定制开发的项目而言，很可能只需要将概念和计划决策合并为一个决策评审点，某些技术评审点也可以合并。
(2) 直接用项目定义过程来管理项目
有些项目经理认为裁剪得到了项目定义过程，然后就可以开始项目的具体工作了。但项目定义过程并非项目计划，更不能替代项目计划。项目经理应基于项目定义过程制定项目的WBS（工作分解结构），以WBS为基础进行工作量、规模和进度估算，制定项目进度表和完整的项目计划。后续工作要以项目计划为基础监控项目的实施。
在过程中，项目还要记录、收集和分析实施中的度量数据，用于监控项目。一些常见的问题、风险和经验教训总结更应该提升到组织层面进行统一管理和协调。从而不断改进组织标准过程，形成闭环。
(3) 不允许裁剪过程，或者裁剪有很大的灵活度
有些企业在刚刚建立过程体系时，由于很难立即制定一份完善的裁剪指南，所以干脆一刀切，不允许裁剪过程。但这样硬性规定的结果是一些维护型、功能增强型的项目要么就是在搞不清状况的情况下照着完整的过程执行，生成很多文档，也延误了开发周期，降低了效率；要么干脆拒绝执行过程，仍然按照过去的工作方式开发。显然，这就违背了建立过程体系的初衷。
另一个极端是企业允许过程裁剪有很大的灵活度，却没有设定一些原则。这样的结果往往是项目随心所欲地裁剪过程，最终项目形成的过程资产的可重用性非常低。
针对规范性和灵活度的平衡，很多企业倡导“先僵化，后优化”的原则，在过程建立的初期尽量削足适履，等到积累了一些经验后再优化过程，形成更易操作的裁剪指南。
《CMMI 基础知识培训和OSSP体系文件培训》试题及答案 姓名：分数： 一．单项选择题（30’） 1.CMMI模型中，必需的（required）组件是__B_；期望（expected）组件是_A _;提供 信息的（informative）组件是__C___ A 实践B目标C典型工作产品与子实践等信息D以上都不是 2.CMMI-DEV阶段式表达方式中，成熟度等级4级包括__A_两个PA；成熟度等级5包 括__B_两个PA A.QPM OPP B OID CAR C QPM OID D OPP CAR 3.张三是某项目经理，项目实施后期，项目组需要与用户确定项目初步验收方案，为 保证该性能得到验证，项目组经研究给出一个完整的测试方案（用例），并得到用户认可。项目组所做的工作与CMMI模型_C___过程域有关： A:PI B:VER C：VAL D：TS 4.项目成功三要素（C） A：能力的员工，好的领导和适当的开发技术 B：有能力的员工，工资高和适当的开发技术 C：有能力的员工，优良的过程和适当的开发技术 5.产品的质量B A：设计出来的 B: 通过实现产品的过程来实现的 C：生产出来的 D：检验出来的 6.CMMI中强调的制度化是（C） A:SG和SP B: GG和GP C: PA 之间的关联 二．判断题目(20’) 1.CMMI是过程模型，不是过程描述文件(T) 2.CMMI中VER和VAL区别是，前者保证产品做的对，或者保证做对的产品(F) 3.对于一个产品而言，只有一个配置基线(F) 4．项目开发每个阶段都要正式评审(F) 5．项目计划中就要定义项目的生命周期(F) 三．简答题(50’) 1.请描述CMMI的几种表示方法，他们之间的区别与联系是什么？ 阶段式和连续式 阶段式：通过达到相应的目标表示完成相应的阶段 连续式: 在连续式模型中没有专门陈述目标，而是更加强调实践。
CMMI基础知识 一、CMMI简介 CMMI (Capability Maturity Model Integration* 能力成熟度模型集成)是用于产品开发(或服务)的过程改进成熟度模型。CMMI的最佳实践覆盖了产品构思、交付和维护的整个生命周期。 CMMI源自于CMM。1984年美国国防部为了降低采购风险，委托卡耐基一梅隆大学软件工程研究院(SEI)制定了软件过程改进、评估模型，也称为SEI SW- CMM。该模型于1991年正式推出，迅速得到广大软件企业及其顾客的认可。 经过不断研究，相继推出了其他领域的CMM模型，比如： (1 ) SE-CMM (System Engineering CMM): 系统 11 程CMM (2 ) SA-CMM (Software Acquisition CMM): 软件采购CMM (3 ) IPT-CMM (Integrated Product Team CMM): 集成产品群组CMM (4) P-CMM (People CMM):人力资源能力成熟度模型 之后将各种CMM模型进行整合，形成了CMMIo 2002年CMMI1. 1版本正式发布， 并立即被广泛采用，2006年8月，面向开发的CMMI (CMMI-DEV 1.2)版本正式发布。LI前正在使用的就是这个版本。下面讲的CMMI是指CMMI-DEV1. 2,针对软件方面的。 通过上面的介绍，可以清楚地知道CMMI这儿个字母的含义， CM:能力成熟度。不同的成熟度对应不同的等级，一共有五个等级； M :模型。CMMI提供一个标准的模型，企业的软件能力成熟度是否达到对应的级别，要和这个模型进行比较。 I :集成。将各个不同领域的CMM进行抽象整合。也就是说CMMI不仅适合于软件 领域，同样适合于其他领域。 二、CMMI的五个等级 CMMI的阶段式表示法将成熟度划分为5个等级。除了初始级以外，每个成熟度等级都有若干个过程域，如下表所示。由于成熟度等级是循序渐进的，如果想达到某个成熟度等级，例如CN1MI 3级，除了满足CMMI 3级本身11过程域之外，还要满足CMMI 2级的7个过程域，依此类推。
CMMI基础知识培训 ? 初始级已管理级?已定义级 ?定量管理级 ?优化级 ?初始级?已管理级 ?已定义级?已定量管理级赛柏科技
内容提要 ?软件组织为何要引入CMMI？?CMMI模型简介 ?实施CMMI的流程
各行各业都依赖软件 ?任何业务都要依赖软件（以美国空军为例，1960年软件只支持飞行员8%的功能，1982年为45%，2000年为80%） ?任何软件生产都发生过以质量不高、进度拖延、成本超支为特征的软件危机，进行过程改进，可以避免危机 ?在20世纪70年代末，美国国防部主持的三次分析得到了几乎相同的结论：软件危机的70%的原因是管理问题，30%的原因是技术问题，只有进行过程改进，才能避免危机 ?各行各业都要靠软件制胜，改进软件需要从改进过程入手，这种理念的转变是软件工程近30年来的重大成果 Source: Winning with Software: An Executive Strategy, Watts Humphrey, December, 2001.
什么是CMMI？ CMMI的全称是 Capability Maturity Model Integration，即 能力成熟度模型集成，它 提供了一套过程改进的完 善架构及评估标准。
CMMI 业界公认的能力提升模型 ?CMMI 是由美国国防部资助,美国卡内基-梅隆大学软件工程研究所（SEI）创立并发布的过程改进模型. –软件过程改进方面得到国际认可 –她是一个如何做好软件的最佳实践的集合 –已经得到全球实践证明，我们不必怀疑她的先进性 –如果我们没有做好，那不是CMMI的问题，而是我们的理解与执行的问题
CMMI能力成熟度模型基本知识 CMMI 的全称为：Capability Maturity Model Integration，即能力成熟度模型。 CMMI家族包括CMMI for Development, CMMI for Service和CMMI for Acquisition三个套装产品。 CMMI的五个台阶（五个等级）： 台阶一：CMMI一级，完成级。在完成级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。 台阶二：CMMI二级，管理级。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列的管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。 台阶三：CMMI三级，定义级。在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化这样，企业不仅能够在同类的项目上生到成功的实施，在不同类的项目上一样能够得到成功的实施。科学的管理成为企业的一种文化，企业的组织财富。 台阶四：CMMI四级，量化管理级。在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。对管理流程要做到量化与数字化。通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。 台阶五：CMMI五级，优化级。在优化级水平上，企业的项目管理达到了最高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程，运用新技术，实现流程的优化。 由上述的五个台阶我们可以看出，每一个台阶都是上面一阶台阶的基石。要上高层台阶必须首先踏上较低一层台阶。企业在实施CMMI的时候，路要一步一步地走。一般地讲，应该先从二级入手。在管理上下功夫。争取最终实现CMMI的第五级。 CMMI有专业的认证，获得CMMI3认证，就是能力成熟度达到了台阶3，通过相应的CMMI3级能力评估后，就能获得3级的证书。
一、基础信息介绍： 1.1 CMMI――Capability Maturity Model Integration(集成能力成熟度模 型)； 1.2 CMMI是由卡耐基梅隆大学软件工程学院（SEI）制定的； 1.3 CMMI集成了四个知识领域的应用： l Software Engineering (软件工程)、 l System Engineering (系统工程)、 l Integrated Product and Process Development （集成的产品与过程开发）、 l Supplier Sourcing (外包开发) Newegg引入CMMI主要使用在两个知识领域：Software Engineering (软件工程) 和System Engineering (系统工程) 1.4 CMMI模型在表现方式上分为2种：分阶段表述和连续性表述，我们通 常所说的CMMI的等级是指在分阶段表述下的成熟度等级（ML）。 二、CMMI构成介绍： 2.1 CMMI模型组建图 2.2 专有名词介绍： l 成熟度等级（Maturity Level, ML）：在CMMI分阶段表述中一组经过定义的渐进式过程改善指标，达到每一个成熟度等级则 代表组织过程的某重要部分有稳固的基础，一共分为五级。
l 过程域(Process Area, PA)：是一组同属某过程领域而彼此相关的执行方法，当共同执行这些方法时，可以达成一组目标，而 这些目标对该领域的重大改善是重要的。 l 特定目标(Specific Goal, SG)：适用于单一的过程域，并强调其独有的特征，此特征用来说明必须要执行什么以满足过程域。 l 特定实践(Specific Practice, SP)：是一种活动，它对达成相关的特定目标是重要的，特定执行方法说明一组活动，这组活 动被期望可某过程域的特定目标。 l 一般目标(Generic Goal, GG):是指该目标可用于多个过程域，分阶段表述的每个过程域只有一个一般目标。达成某过程域的 一般目标，代表该过程域相关过程的计划和实施获得控制和改善； 也象征这些过程是有效的、可重复的以及可持续的。 l 一般实践(Generic Practice, GP):提供制度化的方法，以确保过程域的相关过程是有效的、可重复的以及可持续的。 共通特性（Common Features）：各过程域的一般实践，以共通特性来分成不同的类别。共通特性是不被评级的模型组件，它们只是用来表示一般实践的一种编组方式。共通特性分为： Commitment to Perform（CO）执行承诺 Ability to Perform（AB）执行能力 Directing Implementation（DI）督导实施 Verfying Implementation（VE）验证实施 三、重要概念介绍 3.1成熟度等级介绍： 成熟度等级在2级以上（包括2级）才需要进行评估。对每个等级进行评估时，需要保证满足该级别和该级别以下级别的所有要求，例如对ML3级进行评估时，需要组织同时满足2级7个PA的要求和3级14个PA的要求.