初见博客园，知之甚少，翻看网站分类，没有CMMI云云类，也许是此体系类不比语言架构等拿来即可用，不过真心觉得CMMI挺重要的，如果不懂CMMI，你可以做出产品，懂了CMMI,你可以做出一个项目，不知道这样说话恰不恰当，我只是想说CMMI可以调整整个开发过程的漏洞，做出来的东西，极具标准化，一个合格的开发者，绝不单单是完成手头的编码工具实现某功能完成任务，还要有头脑有思想有经营意识。
今后使用博客园，一来分享成果经验，二来做个总结笔记，见证成长，也方便温故而知新，暂时先体验体验。
讲到CMMI，最基本的就是现在它的两种表述方式，即连续式和阶段式，有三种类型的因素可能影响你的决定：经营、文化与现况。
情节1
一个电子系统开发者想要使用连续式表述来改进它的产品开发过程。
在情节1 中，你使用连续式表述，并选择对你的经营目标是重要的过程。由于有22 个过程域可以选择，当在开始时，过多的过程域通常使我们会不知如何着手。你需要缩小你的焦点。举例来说，你也许发现到竞争对手的产品总是比你的产品还要早发布，因此你可能选择专注于改进你的工程与项目管理过程。
建立在这个决定上，选择所有的工程过程域当成一个开始点：产品集成、需求开发、需求管理、技术解决方案、确认与验证。你也选择项目策划与项目监控。
你在此点上决定一开始要专注八个过程域仍然是过多的，然后你决定需求过程是问题的真实所在。所以你选择需求开发与需求管理过程域，开始你的改进工作。
接着下来你要决定需求领域需要改进到多好。你有任何的过程已经在需求领域上吗？如果你并没有，你的过程改进目标可能要从能力度第1级开始。
你的每一个项目都有需求开发及管理过程，但是它们却不是已管理的过程？举例来说，方针、培训和工具无法执行以支持过程。假如你有需求过程，但是它们并没有支持的基础建设，你的过程改进目标也许是在能力度等级第2级。
你有所有的需求开发与管理过程，并且它们已被管理，但是每一个项目执行的过程却是有差异的？例如，你的需求诱导过程无法在跨组织中被一致地执行。假如以这个项目来看，你的过程改进目标也许是在能力度等级第3级。
你有一致性地管理与执行你的需求开发及管理过程，但是没有用客观方式去控制和改进这些过程吗？假如以这个项目来看，你的过程改进目标也许是在能力等级第4 级。
你想要确保您根据量化目标所选择的适当子过程可以最大化你的经营？假设是如此，你的过程改进目标也许是针对所选择的过程到能力度等级第5级。在每个过程域的描述下，记得要去看「适用于硬件工程」、「适用于系统工程」与「适用于软件工程」的强化。使用没有特定标记与被框线标记为「仅适用于连续式表述」的所有信息。
如你在这个情节所见到的，你需要了解哪些过程需要改进以及每一个过程要达到的成熟度。这个进行方式反映了连续式表述的根本准则。
情节2
一个已经使用IPPD 与软件能力成熟度模型的软件开发公司，现在想要使用能力成熟度集成模型，这个公司目前达到软件能力成熟度的第3级。
在这个情节中，你是一间使用IPPD 与软件能力成熟度模型的软件开发公司，你想要使用能力成熟度集成模型。你选择成熟度第2 级与第3 级的过程域，以及选择CMMI for Development + IPPD 模型。
这个选择包含成熟度等级第2级下的七个过程域：需求管理、项目策划、项目监控、供应商协议管理、度量与分析、过程与产品质量保证、配置管理。它也包含成熟度等级第3 级下的11 个过程域：需求开发、技术解决方案、产品集成、验证、确认、组织过程焦点、组织过程定义、组织培训、集成的项目管理、风险管理及决策分析与解决方案。你也会包含IPPD 附加在内。
因为你在软件能力成熟度模型中，已经被评等为成熟度第3级，所以只要看那些包含在CMMI 内，但却未包含在软件能力成熟度模型内的过程域。这些过程域包含度量与分析、需求开发、技术解决方案、产品集成、验证、确认、风险管理及决策分析与解决方案。确认你的组织是否存在这些过程，即使它们没有被软件能力成熟度模型描述。假如有任何合适的过程可以与这些过程域对应，或是与软件能力成熟度模型之其它过程域对应，执行差异分析去对照这些目标及实践，以确保你解决每一个CMMI 过程域的意图。
记住，每一个你所选择的过程域，察看标记为「适用于软件工程」与「IPPD 附加」的信息。使用没有特定标记与被框线标记为「仅适用于阶段式表述」的所有信息。
如你所见，这份文档所提供的信息可以有各种使用方式，审视你的改进需要。能力成熟度集成模型的整体目标是提供一个可以一致地分享过程改进最佳实践的架构与表述，但是仍有足够的弹性解决社群变更的需要。