各位朋友：
大家久等了。
在12月初我们为大家提供了FIDIC国际工程项目管理实务英语教材，不知各位是否收到。这里提醒大家可以直接在手机端访问www.fidic.cn下载文件，学习、交流。
言归正传，这次我们讨论的话题是CMMI，即能力成熟度模型集成。中文翻译听起来有些拗口，不必担心，我们结合项目管理来为大家介绍一下有关知识。
CMMI全称是Capability Maturity Model Integration，即能力成熟度模型集成（也有称为：软件能力成熟度集成模型），是美国国防部的一个设想，1994年由美国国防部（United States Department of Defense）与卡内基-梅隆大学（Carnegie-Mellon University）下的软件工程研究中心（Software Engineering Institute，SEISM）以及美国国防工业协会（National Defense Industrial Association）共同开发和研制的，他们计划把现在所有现存实施的与即将被发展出来的各种能力成熟度模型，集成到一个框架中去，申请此认证的前提条件是该企业具有有效的软件企业认定证书。
其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架。因而能够从总体上改进组织的质量和效率。CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。
CMMI自出道以来，它所达到的目标就没有变过，第一个是质量，第二个是时间表，第三就是要用最低的成本。不过特别强调的是，CMMI不是传统的、仅局限于软件开发的生命周期，它应该被运用于更广泛的一个范畴——工程设计的生命周期。TSP的建立，也是为了支持CMMI的这样一个系统。那么CMMI究竟是什么呢？它并不是一个过程，也不是告诉你怎么去做一件事情。如果用一句话来概括什么是CMMI，它就是各个进程的一个关键的元素，在很多领域里面一个集成的点。它是这样的一个基本架构，能够用来度量你的有效性和实用性；能够找出这样的一些机会，继续改进的机会，包括在商业目标、策略还有降低项目的风险等方面。
工具
组织在实践CMMI过程中，提升和改进研发管理能力的同时，也面临着辅助过程改进工具的挑战，缺少工具支撑，CMMI的规程、流程，尤其量化数据分析的推行成本非常高，往往使很多组织望而生畏；实践证明能够很好支撑CMMI落地的工具有：微软Project Server、IBM Rational系列工具、青铜器RDM研发管理系统、Techexcel DevSuite。CMMI工具至少要满足如下特点：
1. 以项目运作为主线条，至少包含计划进度管理、工时管理、文档管理、变更管理、风险问题管理、量化管理。
2. 强大的流程自定义能力，能够支撑不同组织根据自己的要求自定义相应的流程。
3. 量化数据收集与分析能力，能够自定义项目质量目标，根据项目质量数据自动汇总组织的能力基线；同时要有智能报表能力。
4. 知识管理能力，尤其要实现情境化知识管理，能够将项目历史实际数据直接作为知识进行分享、重用，知识管理要与操作人的行为关联。
5. 工程技术要全覆盖，至少要涵盖需求分析与需求管理、测试管理（测试计划、测试用例、测试执行）、需求跟踪管理、文档管理、评审与验证管理。
人员素质
一切项目或系统计划得再完美，也需要人去执行。CMMI本身是一件工具，为我们执行大型项目提供了范本和解决思路。每个公司都需要指定符合本公司情况的体系，才能真正用好CMMI模型。
否则，正如下面网友所说，变成非常苦恼的差事了。
1 CMMI文档过多过滥
抽象看，好像CMMI的文档每一项都能说出它的用处来，但为什么这些“有用”的文档却不能在软件开发实践中起到促进作用，反而成为一种累赘呢？可能有以下几点：
1）现实中这些“有用”的文档都只是可能有用，而非一定有用。而且每份文档能起到作用的概率都很小，只是小概率事件。为了应对大量的小概率时间，而写大量的文档，付出相当大的工作量；即使这个小概率事件在一个较长时间内发生了一次，CMMI文档为此节省的成本，一般也无法抵消大量文档编写导致的成本升高。更何况不用CMMI也要写必要的文档，这个小概率未必就一定造成损失。
这就好比，每次赶飞机都提前2小时到机场以避免误机一样，坐一千次飞机耽误了2000小时。另一个人每次都提前三十分钟到机场，虽然偶尔有一次误了机，导致的损失也比不上2000小时的时间损失。
2）项目开发人员都不是作家，没有几个人有下笔成章的文笔能力。编写文档往往本身成为一个大的时间开销。假定每个人都有随手把心中所想转化为文档的能力是不切实际的。
3）软件开发人员的工作成效往往是在特定时段创造的，就是通常大家说的“灵感来了”。这种状态一旦被打断，下次进入这种状态就比较困难，勉强去做可能比高效状态效率低得多，出错概率还高。CMMI繁琐的文档和会议常常打断开发人员的思路，客观上延长了项目开发的周期，提高了出错量。
4）CMMI把高度创造性的开发过程当成机器的开动运转和停止，忽视了人的主观能动性和人在不同状态下工作效率的很大差异，必然遇到开发人员的普遍抵制。
2 CMMI定位是精细化管理，需要过程、交付、量化数据来支撑，如果还是依赖人员的检查、海量的Excel文件汇总，势必导致技术人员抵触，这样CMMI必然流于形式，所以结合业界成功实施CMMI公司的经验：CMMI必须要借助IT手段来推行。
各位朋友：
大家久等了。
在12月初我们为大家提供了FIDIC国际工程项目管理实务英语教材，不知各位是否收到。这里提醒大家可以直接在手机端访问www.fidic.cn下载文件，学习、交流。
言归正传，这次我们讨论的话题是CMMI，即能力成熟度模型集成。中文翻译听起来有些拗口，不必担心，我们结合项目管理来为大家介绍一下有关知识。
CMMI全称是Capability Maturity Model Integration，即能力成熟度模型集成（也有称为：软件能力成熟度集成模型），是美国国防部的一个设想，1994年由美国国防部（United States Department of Defense）与卡内基-梅隆大学（Carnegie-Mellon University）下的软件工程研究中心（Software Engineering Institute，SEISM）以及美国国防工业协会（National Defense Industrial Association）共同开发和研制的，他们计划把现在所有现存实施的与即将被发展出来的各种能力成熟度模型，集成到一个框架中去，申请此认证的前提条件是该企业具有有效的软件企业认定证书。
其目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件开发中的困难。CMMI为改进一个组织的各种过程提供了一个单一的集成化框架，新的集成模型框架消除了各个模型的不一致性，减少了模型间的重复，增加透明度和理解，建立了一个自动的、可扩展的框架。因而能够从总体上改进组织的质量和效率。CMMI主要关注点就是成本效益、明确重点、过程集中和灵活性四个方面。
CMMI自出道以来，它所达到的目标就没有变过，第一个是质量，第二个是时间表，第三就是要用最低的成本。不过特别强调的是，CMMI不是传统的、仅局限于软件开发的生命周期，它应该被运用于更广泛的一个范畴——工程设计的生命周期。TSP的建立，也是为了支持CMMI的这样一个系统。那么CMMI究竟是什么呢？它并不是一个过程，也不是告诉你怎么去做一件事情。如果用一句话来概括什么是CMMI，它就是各个进程的一个关键的元素，在很多领域里面一个集成的点。它是这样的一个基本架构，能够用来度量你的有效性和实用性；能够找出这样的一些机会，继续改进的机会，包括在商业目标、策略还有降低项目的风险等方面。
工具
组织在实践CMMI过程中，提升和改进研发管理能力的同时，也面临着辅助过程改进工具的挑战，缺少工具支撑，CMMI的规程、流程，尤其量化数据分析的推行成本非常高，往往使很多组织望而生畏；实践证明能够很好支撑CMMI落地的工具有：微软Project Server、IBM Rational系列工具、青铜器RDM研发管理系统、Techexcel DevSuite。CMMI工具至少要满足如下特点：
1. 以项目运作为主线条，至少包含计划进度管理、工时管理、文档管理、变更管理、风险问题管理、量化管理。
2. 强大的流程自定义能力，能够支撑不同组织根据自己的要求自定义相应的流程。
3. 量化数据收集与分析能力，能够自定义项目质量目标，根据项目质量数据自动汇总组织的能力基线；同时要有智能报表能力。
4. 知识管理能力，尤其要实现情境化知识管理，能够将项目历史实际数据直接作为知识进行分享、重用，知识管理要与操作人的行为关联。
5. 工程技术要全覆盖，至少要涵盖需求分析与需求管理、测试管理（测试计划、测试用例、测试执行）、需求跟踪管理、文档管理、评审与验证管理。
人员素质
一切项目或系统计划得再完美，也需要人去执行。CMMI本身是一件工具，为我们执行大型项目提供了范本和解决思路。每个公司都需要指定符合本公司情况的体系，才能真正用好CMMI模型。
否则，正如下面网友所说，变成非常苦恼的差事了。
1 CMMI文档过多过滥
抽象看，好像CMMI的文档每一项都能说出它的用处来，但为什么这些“有用”的文档却不能在软件开发实践中起到促进作用，反而成为一种累赘呢？可能有以下几点：
1）现实中这些“有用”的文档都只是可能有用，而非一定有用。而且每份文档能起到作用的概率都很小，只是小概率事件。为了应对大量的小概率时间，而写大量的文档，付出相当大的工作量；即使这个小概率事件在一个较长时间内发生了一次，CMMI文档为此节省的成本，一般也无法抵消大量文档编写导致的成本升高。更何况不用CMMI也要写必要的文档，这个小概率未必就一定造成损失。
这就好比，每次赶飞机都提前2小时到机场以避免误机一样，坐一千次飞机耽误了2000小时。另一个人每次都提前三十分钟到机场，虽然偶尔有一次误了机，导致的损失也比不上2000小时的时间损失。
2）项目开发人员都不是作家，没有几个人有下笔成章的文笔能力。编写文档往往本身成为一个大的时间开销。假定每个人都有随手把心中所想转化为文档的能力是不切实际的。
3）软件开发人员的工作成效往往是在特定时段创造的，就是通常大家说的“灵感来了”。这种状态一旦被打断，下次进入这种状态就比较困难，勉强去做可能比高效状态效率低得多，出错概率还高。CMMI繁琐的文档和会议常常打断开发人员的思路，客观上延长了项目开发的周期，提高了出错量。
4）CMMI把高度创造性的开发过程当成机器的开动运转和停止，忽视了人的主观能动性和人在不同状态下工作效率的很大差异，必然遇到开发人员的普遍抵制。
2 CMMI定位是精细化管理，需要过程、交付、量化数据来支撑，如果还是依赖人员的检查、海量的Excel文件汇总，势必导致技术人员抵触，这样CMMI必然流于形式，所以结合业界成功实施CMMI公司的经验：CMMI必须要借助IT手段来推行。