对于实施CMMI，对软件过程进行改进，我原来一直观点是CMMI实施不一定能够提高软件的质量，因为过程和人始终是两个重要因素，软件项目团队和人往往起到重要作用。

当我们持这种观点的时候往往就表明了我们的成熟度比较低，没有上升到项目级和组织级，整个项目的成功往往取决于项目中的几个关键人员，这样对项目和组织的危险性都是很大的。实施CMMI的一个重要目的就是要尽量的减少人对项目的影响，形成组织级的过程和规范。因此我现在观点是实施CMMI一定可以改进软件质量，如果你实施了CMMI没有改进质量，只能够说明你某些重要的KPA没有达到CMMI的要求。

需求的不稳定或需求范围的蔓延往往是我们经常都要分析到的软件项目的关键风险，出现频繁需求变更的一个关键其实是需求开发RD这个过程域没有做好，如果我们前期需求收集，需求开发，与用户有足够多的沟通，交互和原型的演示，原则上不应该出现过多的需求变更。

GG 通用实践里面有两个重要的实践，一个是提供相应的资源，当资源技能不足的时候组织应该保证充足的技能培训。但我们项目一启动的时候，一般这两点都很难满足要求，及时资源能够满足，但人员的知识和技能水平往往也不能马上得到满足，而往往这个时候项目根本不可能说等着组织把你的人员培训来技能满足要求了，再给你，再开始项目，所以往往你知道人员技能有问题，还是得开始你得项目。所以经常出现这种情况往往是我们得GG根本没有达到要求，而CMMI很简单给你一个实践在需要时候可以得到充足满足技能得资源，及时不满足组织级可以通过技能培训让资源满足要求。所以这看似简单一句话，就包含了诸多需求我们进行过程改进得地方，需要考虑人得因素得地方，你做不到不能说CMMI不好或者没有要求，只有说你成熟度没有够。

有些项目往往一开始就注定失败，一个重要得是技术方案得选择，对于决定着项目重要成败得技术方案CMMI推荐要采用DAR过程域进行决策分析和解决方案得选择，而往往做一个复杂得 DAR需要1-2个月甚至更长得时间，一个大中型项目周期一般也就半年，时间决定金钱，市场决定研发项目要第一时间尽快交付，而这个时候不知道有多少人会等待这漫长时间去做一个DAR，而理直气壮得说这是按照CMMI得要求在做。 CMMI针对很多过程和问题都给出得实践得方案和标准，而由于资源限制，项目时间进度限制，往往我们很难达到这些目标和标准，这时候你可以说CMMI没有考虑这些，也可以说我们得过程确实还需要进一步改进。

CMMI 一个重要假设就是人员技能能够达到项目要求。同时CMMI也通过组织级技能评估，培训效果评估等多个子实践来验证这点，但往往我们是很难达到这个目标。项目往往考虑得是有人总比没人强。CMMI另外一个重要假设是假设制度和规范可以规范所有人员得活动，而这点往往又是很难做到得，CMMI强调你这些你过程没有做到，只能说明你能力成熟度不够。

CMM的VER和VAL两个过程域是保障软件质量的重要KPA,评审一直是我们提前发现缺陷和防止缺陷泄漏的重要手段，而评审一般要提前熟悉相关内容，提前预审，评审会议召开后还需要对评审文档进行修改，修改完成后还要相关人员逐一验证，基线后才能够开始后续的相关活动，而这个过程耗时至少一周以上，对于项目周期短的软件项目来说，这个时间对进度的影响是致命的。还有CMMI假设评审成员都会认真评审和发现问题，但往往这点要做到又很难，问题出在我们预审时间留的不够，或者规范根本很难去控制个人的预审过程。及时我们修改规范和标准，做到能够根据规范去检查也不一定最优，反而是适得其反。

RSKM风险管理也是CMMI三级的一个重要过程域，这个过程域对软件项目成功至关重要，很多项目最好导致延期或失败，关键还是我们没有提前发现不确定性和风险，而采取相关的缓解和应对措施。

软件能力成熟度也高一个直接的体现就是组织过程，个人对整个软件项目的影响降到最低。整个软件项目成功不依赖于项目几个人单打独斗。而是整个项目共同分工协助来完成。

CMMI一定可以改进软件质量，如果没有改进应该首先检查自己的各个KPA是否都达到要求了，而且现在CMMI过级本来就存在较大水平，只有我们真正按着以改进我们的软件过程目标为导向来过级的时候，才能够体会到CMMI对软件质量改进的好处。