贯标集团-北京-cmmi适合在软件开发中应用吗？

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、项目经理对软件风险失去监控，一个月前就预知的问题眼睁睁看着它变成现实。