CMMI（Capability
Maturity Model Integration）即能力成熟度模型集成，是上世纪80年代初，美国国防部牵头的政府机构选择项目的外包公司时，为了选出更有能力，更成熟的公司，于是就委托位于位于匹兹堡的卡内基梅隆大学成立软件工程学院来研究，由Watt Humphrey领头，100多位专家在一起通过一段时间的探讨，总结了大概100多条标准，后来再经过总结提炼，这些标准极具代表性，逐渐转变为能力成熟度模型CMM，而CMMI则是对CMM的继承。能力成熟度模型的本质时刻画一个软件公司从不成熟到成熟的路线图，并不是一般人所理解的只是一些标准，很多人会拿敏捷开发和CMMI进行比较，但实际上二者并没有可比较性，一个是开发方法，一个是注重优化改进的模型。它包括连续式和阶段式两种表现形式，所谓连续式可以理解为好与不好，而阶段式理解为做了还是没做，CMMI所做的评估只是过程改进的起点而不是终点，就比如你评估到了5级，并不意味着它就完成了，什么就不去追求了，也并不意味着就比三级四级的公司实际表现就更好，而是到了五级依然该去追求整个过程的改进。它包括五个级别，第一个级别Initial，一般指的是以个人为中心，开发过程通常随意且混乱。第二个级别Managed，这时候项目已经拥有了跟踪，确保整个过程按照方针得到计划与执行。第三个级别Defined，核心是共享，过程得到了清晰的说明与理解，并以标准、规程工具与方法的形式进行描述。第四个级别Quantitatively Managed，主要是量化，第五个级别Optimizing，无止境的在有初步效果的现有体系上的过程改进。这些是对本文要讨论的CMMI的基本介绍。
CMMI进入我国软件领域这些年以来，对我国软件产业的健康发展作出了巨大贡献。但是也出现了一些在实践中被误用和曲解的场景，以及带来了与初衷渐行渐远的效果。首先，CMMI并不是具体的软件开发方法，它应该是去定义一个适应本软件组织的软件过程，并且不断优化的过程，以更符合软件组织的商业目标，CMMI不能被用于检验软件过程优劣，过程改进对不同的企业是不一样的。设立CMMI证书后，一些企业只是单纯的以获得证书为根本目的，以为获得更高级的证书就能获得进入外包市场的国际通行证，但是却忽视了对软件生产过程真正持续的改进。证书挂墙上，体系却被抛弃了，更或者是实施到一定阶段，缺陷依然多，效率依然多，达不到最初想要的效果，还有一种就是急于通过更高等级的评估，也就是单纯的把他们当作过程能力改进的终点，不管它是否适合当前的自身和评估过后的影响。这些都是令人担忧的现象。因此我觉得其中不仅有人们对它曲解和误用，还得考虑当前软件开发的大环境，CMMI模型存在不适合当前软件开发的理由。
首先，目前的软件开发基本CMMI的3级水平就能达到一般的需求，而4级5级的一些要求基于目前的基本实践会让基本的评估变得较为僵硬，CMMI的4级强调的是过程稳定性和项目量化管理，5级强调的是根本原因分析和持续改进，如果企业3级时就有了量化目标，那就意味着做到了部分4级的要求，甚至很多企业很多指标已经做得很好了，就要考虑4，5是否一定有必要，是否真的能实现真正的跟高级的要求，有时候量化不一定能正确的证明你的持续改进，之前所提到的持续改进是需要时间累积的。四级到五级很多留给你去验证的框架，它们基本都是动态的，而动态的往往是最难把握住的，事实上我们大多数达到四级五级的公司，评估过程中所使用的数据往往并不是真实的数据，因为真实的数据无法体现一种动态的关系。
其次，当前的软件开发过程除了强调过程管理的重要性以外，使用的技术，人的因素也有决定性的作用，这也消弱很多CMMI建立的模式的作用。所以好多企业要解决的首先是企业当前实际的瓶颈问题，才能最大限度的提高生产率。有一家专门从事软件外包的公司，通过CMMI的3级，流程定义得很简洁、实用，企业的执行力也很强，但是项目的实际效果却不好。为什么呢？经过仔细审查项目组的需求、设计、测试用例、源代码等文档，发现需求的描述有遗漏，有错误；设计文档没有满足基本的设计原则；测试用例不完备，覆盖率比较低；源代码中需要重构的地方比比皆是。项目组的成员都比较年轻，工程经验大都少于两年，尽管企业也进行了需求工程、设计模式等技术培训，但经验不是靠培训就能解决的。因此，即使有好的流程，仍然有可能开发不出好的软件系统，另外一家公司，没有通过CMMI的评估，公司内有3个部门，其中一个部门积累了一个基于.NET的可复用的MIS软件框架，该框架已由少数精英开发了4年，积累了4年，发布了多个版本。实现一个新需求时，只要定制界面，编写存储过程就可以了。当一个新员工进入该部门后，基于该框架，大概花费1周的时间就可以编写出能够交付给客户执行的代码，该部门的开发效率很高。其实对于该企业来讲，引入CMMI并非当务之急，打破部门之间的壁垒，将该软件框架推广到其他两个部门可能投入、产出比会更高。在一些应用实践中，很明显CMMI一定程度上忽视了人的主观能动性和人在不同状态下工作效率的很大差异，违背了客观事实，导致它并不受到应用实践者的欢迎。
再者，CMMI实践过程中有些量化的具体标准并不清晰，也很难制定出足够有效的量化标准，标准不合适一定程度会拉低开发效率，让开发人员束手束脚，比如开发过程中要求填写大量的文档，然后事实是很少有人通过查找这些文档发现错误。最主要的原因还是在于实践过程和CMMI应用的实际困难。更多是实践有问题，没有建立起度量的标准和完成标准，没有采用合理的构建策略，没有质量保证的手段，没有进行足够的交流，没有足够精确的需求等等。有的企业为了满足评估的需要，做了上百个文档来满足模型的要求，这并不正确。这些文档也许能起到作用，每份文档能起到作用的概率并不高，而完成这大量文档所付出的工作量和成本完全不能匹配它的效果，模型是强调直接证据，但是并非文档越多越好。文档只是用来证明某个实践你做到了，只要达到了这个目的就可以了，而且一个文档可以满足多条实践的要求，可以作为多条实践的证据，这是最经济的做法，只要内容有了，也并非在乎文档的多少与格式。更不利的方面在于CMMI繁琐的文档和会议常常打断开发人员的思路，客观上延长了项目开发的周期，提高了出错量，这对于当今的技术人才支撑的软件开发行业而言，绝对是不可忽视的负面影响。
CMMI初衷所应对的体系结构和目前软件开发中常用的本质上并不相同，CMMI所要求的SEPG所出的规范需要得到软件项目组的认可，规范在执行过程中需要进一步与项目组的实际结合从而进行改进；而SQA人员则是需要监督 软件过程是否按照规范来执行，从而决定是否开出不符合项NCI。另外，系统测试人员也需要具有相当的独立性，不能处于项目开发人员的控制之下。所有这些，在如今的一个以技术作为主导的公司里很难做到，当前软件公司的人员角色很难分清晰。
CMMI只对可以被控制的过程有作用，但是如果过程本身是失控的那也就没有再按照模型进行的必要性了。CMMI是可控制的软件管理过程，它从需求管理到度量分析以及配置管理的过程中都是基于正确的可分析的数据的基础上，而如果这部分数据不能达到想要的效果，你无论如何也没法从CMMI中收获想要的效果。CMMI的实际应用效果也没想象中的那么好，除了以上提到的认证背后产生的不正确的引导和不良的行业风气外，还关键在于将抽象转化为具体的难度，CMMI的定位是精细化管理，需要过程交付，量化数据来支持，如果将它变相的变成依赖人员的检查，势必会导致CMMI流于形式，而这是一些怪相产生的关键原因。甚至有人拿它去和敏捷开发相比较，但是二者并无可比较之处，CMMI刻画了软件团队从不成熟到成熟的每个阶段的特征，它是一种路线图，而敏捷是实际的一种开发模型。
总的来说，CMMI确实是软件工程领域少见的出色工作，对软件开发工作也有着正确的引领作用，但是并不完全适合当代快速发展的软件开发行业。
课堂笔记整理（4.25-4.26）
课程名称：
CMMI（Capability
Maturity Model Integration，能力成熟度模型集成）
推荐书目：《人月神话》，《人件》（老师上课的时候经常引用其中的话）
上课风格（个人观点）：经常会有一些比较开放的思考性问题，个人觉得其实也没有绝对的正确答案，主要是体验一种思考的过程并获取一些启发，有些观点也不是很赞同。还会穿插一些其它学科的知识，让我感到自身知识是多么的匮乏…
相关背景：
上世纪80年代初，美国国防部等政府机构在将一些项目外包时，发现选择承包的公司是一件很复杂的事情，所以就希望弄一个评价标准。于是就委托位于匹兹堡的卡内基梅隆大学（CMU，学校的相关专业很厉害），其成立了软件工程学院（SEI）来进行研究。领头的是Watt Humphrey（从IBM辞职而来，具有很丰富的专业经验），其聚集了不少专家进行研究探讨。总结了大概一百多条标准，开始的时候是做了一个调查问卷，后来逐渐转变为CMM（能力成熟度模型）。而CMMI算是对于CMM的继承。需要注意的是，CMMI的构建Humphrey并没有在其中，据老师说因为他意识到即便有这么个玩意儿也不能从根本上解决遇到的问题，所以其将研究精力转向了其它方面。具体相关的如果大家感兴趣的可以去搜索些深入阅读材料。
课堂构架：
老师上课的思路感觉还是蛮清晰的，我大概说下一个大框架。
一个模型
两种表现形式
三种应用领域
四种类型
五个级别
一个模型：就是指能力成熟度模型，老师说他觉得这是软件工程领域很少见的做的相当完美的一项研究。（还记得背景中提到的Humphrey拉了一帮人一起探讨列条目么？这列出来的一百多条内容里，在日后的这么些年里被实践证明仅有十几条是他们并未想到的。）其本质是刻画一个软件公司从不成熟到成熟的路线图。（而不是一般人所认为的CMMI就是一堆材料）
在这里老师提出了几个问题来帮助认知
我就直接写结论了…
1 CMMI是一个不需要裁减的模型，其本身是完整的。
2敏捷开发和CMMI并非是对立面关系。敏捷指的是一种开发方法，而CMMI是一种模型。
两种表现形式：即连续式和阶段式
连续式是反应一个软件公司的能力水平，阶段式则是反应其成熟度水平。
这里老师也做了一些具体的说明，所谓连续式可以理解为做的好与不好，而阶段式则可以理解为做了还是没做。
其中阶段式所反应的成熟度水平拥有5个级别的划分，而可以把连续式看作是第六个级别。这里老师表达了自己的观点，他觉得这些东西不能太过于绝对化，比如Google公司，它是没有CMMI级别的，但谁都知道这是一家好公司。而一个只做2级的公司有时候要好于3级的，可以理解为是它的性价比比较低，说明是脚踏实地做事的。（这里没有必要太过钻牛角尖，主要是想传达一个思想，CMMI说到底也只是一个相对的评判标准，不可以说的太绝对。就好像评价一个人，不是用好和坏这么简单就可以定义的。）
还有一点老师想阐述的是这种评估是过程改进的起点，而不是终点。不是说公司评到了5级就好像任务完成，什么都不去追求了。这种评估只是一种辅助手段，最终目的不在于此。
三种应用领域：
开发（CMMI for Development,CMMI-DEV）
服务（CMMI for Service,CMMI-SVC）
采购(CMMI for Acquisition,CMMI-ACQ)
这三个领域共享16个核心过程域，同时每个领域自己特有的一些过程域。
在这里老师还谈了谈所谓管理，如何才算管理呢？首先就必须要有一个目标，如果没有目标，就不会出现偏差。因为没有和实际的一个参照物。而管理就是对这个目标的跟进和对目标的补救。
对于过程域，或者说很多的联系，是一种相关性的，而不是因果关系。就是说这些的联系不是上下级或者太过于紧密的关系。
四种类型：
对于这些过程域要进行分类
分为项目管理、过程管理、工程类、支持类
单个过程域属于唯一的一个类型，比如不会出现一个过程域既是项目管理的又是过程管理的。
这里有个题外内容：老师推荐看一看Google编码规范和代码评审的相关博文。这个和考试的关系肯定是没什么的，老师也强调了一点，就是希望通过上课学到一些东西，哪怕是听说几个新鲜的名词，反正是应该有所收获的，而不是以对付考试为目的。
五个级别：
这个好像就是CMMI评审的那5个级别了，即阶段式所反应的成熟度水平。
需要注意的是老师说这里的5个级别和CMM中的是有所区别的，在以后自己阅读一些相关材料的时候要注意这一点，以免晕掉…
第一个级别：原始级（所有的公司都默认是这个级别）Initial
特点：个人英雄主义，一般团队里有个Superstar，他会左右项目的进展甚至是成功还是失败。开发过程通常随意且混乱。
第二个级别：已管理Managed
特点：这时候项目已经拥有了跟踪，确保整个过程按照方针得到计划与执行。
第三个级别：已定义Defined
特点：核心是共享，过程得到了清晰的说明与理解，并以标准、规程工具与方法的形式进行描述。
第四个级别：已量化的管理Quantitatively Managed
特点：就是量化…老师在这里谈的挺多，主要是因为现实和理想之间存在差距，导致矛盾的存在。说白一些，就是这个量化到底是不是好呢？很难说也很难做到一种完美的量化方法。
第五个级别：优化中Optimizing
特点：从英文表述可以看出，上面几个都是ed形式，而这个是ing，即为无止境的。
这里老师说了一个观点，就是所有的4级、5级的公司基本都是做的数据，再直白点就是造假。因为真实的数据无法体现一种变化关系，但要评级必须…咳咳，就是这样，大家应该都懂的…但是这并非是一味的好或者坏，要辩证看待。比如量化这个东西，它不能完全没有也不能太死板，就是没有一个完美的标准，看个人意识了。基本老师就这么个意思，所以还需要继续研究和探索，大家也不能妄自菲薄，认为前途很黑暗。
这里老师还阐述了一下软件工程与传统行业的差异表现在哪里，最核心的就是传统行业生产每件东西都是一样的，是重复性的。而软件不一样，每一件都是新的。所以说软件开发是个很困难很复杂的事情，所以我们都很不容易~~
这就是一个大概的体系架构，希望大家可以比较清晰些，不会太晕菜，具体的东西再看看那些PDF。老师说有几个比较重要的东西，一个是过程域的结构，具体就是CMMI Slides这个PDF文档中的Process Area Components这张图，大家仔细看看。另一个是老师在黑板上画的一张表格。
接下来老师就是具体讲述表格中的每个过程域了，目前讲了的有PP、PMC、SAM（这个没有讲，老师说如果有时间再讲）、CM、MA、PPQA、RD、TS、PI
我个人觉得没有必要太过于扣那些细节，除非要去实践的时候，不然开始就这么干的话没有一些毅力基本会晕菜…老师在介绍这些具体过程域的时候也是以一种探讨的方式，而不是单纯的讲述概念。
比如PP这个过程域，就是项目计划，这里谈到了估算问题，老师其实没有过多说什么具体的估算方法，毕竟时间也不允许。但老师表达了一个想法，估算的具体方法不是最重要的，而是在于让所有的团队里的人相信这个具体的方案是可行的。
又比如PMC这个过程域，就是项目监控。项目监控是必须的，也是有价值的，但出现偏差时，不能鲁莽地去补救，因为导致偏差的原因有很多，要具体去分析。
课上老师还介绍很多，但都比较琐碎。
比如老师说了一个词语：技术负债，他希望我们能够自己去搜索一下这个概念并且有所收获。
比如谈到配置管理的时候，老师说一般有3部分，工作库（基本的东西都可以包含其中）、配置库（稳定版本）这里的东西是不允许随意变更的，但不是不可以变更，需要有一套流程。还有就是产品库。说实话，这里我不是很懂…如果有人能阐述清楚的话，就适当修改一下哈~老师还说代码进入配置库的的节点时在单元测试结束。
比如老师还谈到了语言的问题，bug和defect翻译成中文都是缺陷，但其实在英文中这两个是有区别的，bug是可预知结果的，而defect则是不可预知的错误。
比如老师还说软件工程往往是一种权衡，而不是一种科学。
比如老师还谈论了测试这个职位，他的观点是测试是编码规范的执行者，但产品质量的保障其实并不等于测试的职责。测试在整个循环改进中是个重要角色，但他不是万能的。
比如老师还说客户需求和产品需求是两个不同的概念，客户需求是用户所需要的使用价值，是用户面临的问题。而产品需求则是根据客户需求所产生的解决方案，乍一看有点晕，仔细想想区别还是蛮明显的哈。老师还说和用户最好只讨论具体问题而不涉及系统，因为当你给用户建立了系统的概念以后，也许需求就需要全部改，也就是大侠重新来过……
比如老师还说有时候太多名词并不是一件好事情，因为软件开发本身已足够复杂，再弄一堆复杂的东西会让人疯掉的…
比如老师还说一个缺陷在开发过程中存在的时间越长，解决的代价越大，且增长不是线性的，有可能是指数级的。
还有很多很多，就不赘述了。
而我个人的感受是老师在课堂上阐述的最多的是一种辩证的观念，就以CMMI为例，它本身就个完美的模型，而每一个过程域所阐述的则是最佳方案（理想方案），但实际操作起来确实是很难达到的。比如老师说评审消除缺陷的平均代价是最低的，大家也知道，但是却很少有人能严格地执行评审制度。我们更多的是寻找一种平衡，一种自己和团队认可的东西。
最后总结一下：软件开发很复杂，大家活的很不容易，多看些书接受点新思想多一点思考不一定立马有用但一定是有益的，矛盾是没法消除的，而考试却是不会很难的，就这样。