CMMI

简介
　　CMMI 的全称为：Capability Maturity Model Integration，即能力成熟度模型集成。
　　CMMI家族包括CMMI for Development, CMMI for Service和CMMI for Acquisition三个套装产品。

CMMI的基本思想
　　1、解决软件项目过程改进难度增大问题
　　2、实现软件工程的并行与多学科组合
　　3、实现过程改进的最佳效益

等级
1． 初始级
　　软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。
2． 已管理级
　　建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
3． 已定义级
　　已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。
4． 量化管理级
　　分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。
5． 优化管理级
　　过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。
　　每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性：
　　每个等级都有几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。

　　能力度等级：属于连续式表述，共有六个能力度等级(0~5)，每个能力度等级对应到一个一般目标，以及一组一般执行方法和特定方法。
　　0　不完整级
　　1　执行级
　　2　管理级
　　3　定义级
　　4　量化管理级
　　5　最佳化级

原则
（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提供了阶段式和连续式两种表示方法，但是这两种表示法在逻辑上是等价的。我们熟悉的SW-CMM软件能力成熟模型就是是阶段式的模型，SE-CMM系统工程模型是连续式模型，而IPD-CMM集成产品开发模型结合了阶段式和连续式两者的特点。
　　阶段式方法将模型表一系列"成熟度等级"阶段，每个阶段都有一组KPA指出一个组织应集中于何处以改善其组织过程，每个KPA用满足其目标的方法来描述，过程改进通过在一个特定的成熟度等级中满足所有KPA的目标而实现的。
　　连续式模型没有像阶段式那样的分散阶段，模型的KPA中的方法是当KPA的外部形式，并可应用于所有的KAP中，通过实现公用方法来改进过程。它不专门指出目标，而是强调方法。组织可以根据自身情况适当裁剪连续模型并以确定的KPA为改进目标。
　　两种表示法的差异反应了为每个能力和成熟度等级描述过程而使用的方法，他们虽然描述的机制可能不同，但是两种表示方法通过采用公用的目标和方法作为需要的和期望的模型元素，而达到了相同的改善目的。
　　现在CMMI面临的一个挑战就是创建一个单一的模型，可以从连续和阶段两个角度进行观察，包含相同的过程改进基本信息；处理相同范围的一个CMMI过程能够产生相同的结论。统一的CMMI（U-CMMI）是指产生一个只有公用方法和支持他们的KPA组成的模型。当按一种概念性的可伸展的方式编写，并产生了用于定义组织的特定目标过程模版，定义的模版构件将定义一个模型以适用于任何工程或其他方面。

与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级里单独提出了一个独立的关键过程域叫做风险管理。

人员素质
　　1、明白什么是有价值的积累，先是对你个人，然后才是顺便帮公司做了积累。
　　2、深入一线，发现她们并忠实地记录她们。CMMI里的SP、GP，只是帮助你，提醒你在哪个环节，哪些东西可能是有价值了。你去收集一下，别视而不见了。因为还有一个企业和你个人的角度不同，立场不同的问题。例如，REQM里收集需求，对个人技术方面的积累虽然不多，但对企业是至关重要的，一次需求变更，没详细写清楚，忘记了到客户那里去签字落实，可能就会给企业造成很大的损失。做为一个合格的EPG，是需要有这份责任和义务把每个环节都做到最好，这是职业道德所在。同时也是对自我延伸的一个好机会，学会一些和人的沟通，倾听，把专业的东西以平易的方式表达。这些也都算是EPG额外的收获。
　　通常情况下，为了按时按量完成项目，一线的骨干，对写日报、周报、文档都很不屑。EPG也很迁就，事后再补，这也不失为一个提高效率的好办法。但过去一个月半年了，我们正常人的记忆都能想象，很难记住细节。无非就是敷衍。这也在情理之中。你总不能让一个明天就要交东西的小组，今天晚上在通宵努力解决BUG的同时，还写什么报告，这也不尽人情。但作为EPG不能只把眼光集中在这妇人之心上。要想的更远。为什么会把项目推到这么晚，BUG还没解决完?难道要永远这样下去吗?项目中是有很多不可预测的因素，甚至是开发人员常说的"手气问题"，"人品问题"。但这些是需要控制的，也是通过经验可以控制的，所谓艺高人胆大。艺的高低，就是经验的积累决定的。
　　那怎么解决这种两难的问题呢?逼着技术骨干写心水，人家没时间也的确压力很大。不写，公司又得不到有效积累，积累的都是垃圾流水。有个公司的办法和经验到可以借鉴一下：
　　公司内部搞了个BBS，把不同类型的工作分成不同的组，有纯技术的，JAVA组，C++组等，也有PPT组，甚至动画组，界面组。大家把自己平时的工作积累FTP上去，甚至制作方法，遇到问题和解决方法的文档都丢上去，开始怎么想，用了多少套方案，最后选择了什么。自我感觉如何。把这些心路历程都写成文档。丢到阳光下，大家评论。用点击率和"顶"的人数来说明谁写的是心水，谁在写垃圾。大家都是一个公司的，很容易实名。直接纳入考核机制中。做为一线人员，大家也有动力来写，自己的聪明才智有了展现的平台，虚荣心和荷包都得到了相应的满足。何乐而不为呢?
　　EPG适时的评估大家的成果，并把他们分到项目里。帮助项目总结，甚至在平时遇到问题时，直接帮助技术人员做必要记录。项目进度松时，再督促项目人员完善内容。以达到对个人和公司积累的最大化。
　　EPG应该明白学习和积累是个终身的过程，对公司如此，对个人也是如此。CMMI是个辅助，辅助我们对公司做积累，也帮助我们个人做必要的积累。公司需要逐步走向更高的管理水平，发展平台。

转载声明： 本文转自 http://baike.baidu.com/view/23524.htm#5 （百度百科）