参照前一节的描述，我们会发现CMMI主导下的流程几乎一定不是完美的流程。
CMMI对软件开发进行了大而全的分解，CMMI的过程域覆盖了几乎所有与软件相关的活动。
如果只是以CMMI为参照（不考虑评估）进行适当的取舍，那么CMMI无疑是非常有价值的模型。但是从评估的角度看，导入CMMI的组织必须为各个过程域提供证据，这就导致了一个矛盾：限定资源与复杂方法开销间的矛盾。
我们来看一个例子：
对于10000SLOC规模的软件，把所有CMMI L5的PA相关的活动都排入Schedule后，开发时间会在5个月以上，而5个月对于市场或者客户而言大多是完全不能接受的期限。
经济学里有一个概念叫做机会成本（Opportunity Cost），用这一个概念可以很好地解释上面的现象。在经济学里机会成本是指：一种资源（如资金或劳力等）用于本项目而放弃用于其他机会时所可能损失的利益。
比如说，一个人一天就这么多时间，如果用来养猪了，那么就不能养鸡。当他养猪的时候，养鸡的收益就是机会成本。
对于软件开发也是一样，如果项目的总体资源（如人月）一定，那么覆盖过程域了，编码的时间一定减少；如果减少编码时间，那么就要面对没覆盖过程域所带来的机会成本。比如，Code Review没写记录并进行后续跟踪，那么它的机会成本就是发现的缺陷可能没有被完全修正。
全面覆盖CMMI的过程域时，各种错漏的机会成本会很低，因为CMMI本身是大而全的，其考虑了项目中各种可能出错的地方，并进行了应对。但与忽视某些机会成本来比，这样做代价略高。
比如，在风险管理中，CMMI要求下列的实践活动。
●确定风险源和类别。
●确定风险参数。
●确定风险管理策略。(www.xing528.com)
●标识和分析风险。
●评估，归类并为风险确定优先级。
●……
这样做下来无疑是安全的，同这样的做法相比，依据人员判断，直接列出优先级最高的风险，并采取措施无疑是不安全的。然而，按照CMMI的要求的分解一步步下来，并且每一步骤都留下记录，又无疑是有开销的，而这种开销是否值得，则完全依赖于机会成本的大小。
与此同时，像编码或测试这种环节的时间事实上并不能压缩，所以同没有详细覆盖所有过程域相比，导入CMMI后的最终结局一定是时间和人月上的增加。而如果总的投入资源不能增加，那么就必然会压缩其他工作的时间，这很容易适得其反。
上述的观点可以更简单地概括为：是不是所有层次的人都需要同样尺度的流程？对于项目而言，是把人员的水平作为变量，还是把流程作为变量来进行控制？在特定时空背景下，对项目而言人员状况更难改变，把人员设为变量，意味着把招聘和公司在行业中所处的位置等统统考虑为支撑项目的要素，这并不现实。反倒是把流程设为根据人员层次进行调整的变量更为适合。
契诃夫曾经写过一篇非常有名的短篇小说，叫《装在套子里的人》，他在描写装在套子里的人时写道：
他只要出门，哪怕天气很好，也总要穿上套鞋，带着雨伞，而且一定穿上暖和的棉大衣。他的伞装在套子里，怀表装在灰色的鹿皮套子里，有时他掏出小折刀削铅笔，那把刀也装在一个小套子里。就是他的脸似乎也装在套子里，因为他总是把脸藏在竖起的衣领里。他戴墨镜，穿绒衣，耳朵里塞着棉花，每当他坐上出租马车，一定吩咐车夫支起车篷。
完全符合CMMI规范的项目或组织和这个人非常神似，可以称为“装在套子里的项目”或“装在套子里的组织”。套中人应对刮风下雨什么的无疑是安全的，但跑起来肯定快不了。这对身体不健康的人而言，也许是对的，但为了跑得快，身体健康的人事实上需要少穿点。
特别是当在外部环境中，确实有人以承担风险为代价而求得速度和成本时候，这种成本增加通常意味着失败—不是大鱼吃小鱼，而是快鱼吃慢鱼。更通俗的讲法是，软件组织更多的是要适应外部环境，而非期望外部环境来适应自己。就好比两军对垒，怎么也不能要求敌军在自己摆好阵势，一切就绪之后再发动进攻。而在软件开发中，所谓的敌军和环境可以是客户或市场，你并不能要求他们等待过多。
由此可见，CMMI比较适合外部环境比较静态，不怎么在意成本，并且要求完美的软件（如军工领域的某些软件）。
除上述所论之外，CMMI的实施大多时候必然违反“逻辑链3：共识之力量”，是一种由外向内推进的改善。当项目目标和CMMI目标（通过评级）彼此分离时，就为流程变得形式大于内容提供了足够的养分。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
