cmmi适合在软件开发中应用吗？
说不合适的人，大概是因为如下原因而说的：
1、CMMI是能力成熟度模型，但软件过程能力不等于组织的商业能力。过程成熟并不能保证商业上的成功。因此很多人把项目的失败归结在流程的失败，归结到过程的失败上，因此CMMI这个名堂正好可以用来掩饰决策的失误和人员配置的失误。
2、而这恰恰是CMMI模型本身的短板。CMMI不像ISO9000，不像PACE，本身并没有加入战略运营层面的要素，因此单纯的CMMI并不能解决组织战略对齐的问题，也不能解决决策的问题，更不能解决权衡取舍的问题。
3、说不适合的，是因为他们只是拿CMMI模型硬套在自己的组织当中。CMMI是一种改进模型，它只为组织的改进提供评估的框架，以及指出改进的方向，但它没有告诉我们，什么样的流程才是合适的。
4、在实践层面，CMMI只关注项目层面和部分产品层面的过程，至于更高一级的过程，如产品线工程、技术演进、平台化战略、专利战术、市场与创新等，这些问题无一例外，不能通过CMMI得到解决。这也是为什么有很多组织，按步就班地实施了CMMI导入但却迎来了项目和产品的失败的原因。
CMMI模型是结构蕞严谨的软件过程改进模型，没有之一。就拿CMMI2级那几个PA来说，REQM、CM、PP、PMC，覆盖了软件过程的输入、输出以及中间过程，这是一个放之四海而皆准的模型。以这个模型评估现有的软件开发过程，就可以发现大多数企业其实完全离不开CMMI这个模型：
1、客户需求不清晰、需求多变。
2、需求描述不严谨，在传递过程中信息走样变形。
3、需求在实现过程中没有得到验证，实现与需求不致。
4、项目配置项不清晰，功能合入冲突、版本配套错误。
5、缺乏历史信息，问题引入点无法追溯，导致问题一再重犯。
6、多个部件集中地提交和进版，项目的跑起来是一个灾难。
7、部件之间的依赖关系先天不足，所有问题都是系统性问题，一改就要动架构。
8、项目问题得不到分析，同类型的错误一再发生。
9、为了进度放弃代码评审，代码不经测试就提交。
10、项目经理对软件风险失去监控，一个月前就预知的问题眼睁睁看着它变成现实。
