【IT168 信息化】
CMM等软件过程标准最初是由于印度软件提供商的积极采纳而为人们所熟知的，印度软件厂商也最先达到最高的一致性标准——CMM 5，他们让市场认为CMM（特别是CMM 5）就意味着能够可靠、可预测地交付高质量的商业软件。加上印度极具优势的劳动力价格和大量受过训练的程序员，特别是印度的软件公司还是流程方面的天才，使得软件开发项目潮水般地涌入印度，让印度软件公司很快成为软件开发、软件维护、系统集成与运营等与软件相关的各种项目的主角。然而，最近几年CMM这一软件过程遭到了挑战。
印度软件模式的困境
CMM由于其提高交付成功率的办法而大受青睐。CMM注重过程、度量标准以及可重复性，从某种意义上说它确实让交付变得更可预测，并且在某些特定情况下，一些变更造成的影响也变得更可预测。但在CMM管理下的“瀑布模型”给软件开发带来高度纪律性的同时，用户对软件开发的满意度并未提高。
问题的根源在于: 业务需求的变化促使企业不断调整它们的软件功能。在CMM模式下，瀑布式开发过程虽然已经很清楚地定义了需求变更的处理过程，但需求变更的成本非常高，即使很小的变更也需要大量的流程变更和返工。因此企业经常会陷入两难的境地: 要么重新制定关键项目的计划并接受延期发布，要么将新需求推迟到下次软件发布再完成。而当今的商业环境瞬息万变，几个月的拖延往往意味着市场机会的丧失。
在一些项目中，印度的软件公司引发了客户事后的强烈不满，因为交付的软件并不符合客户当前的需求。更让客户难以接受的是，CMM 5的严格让客户无话可说，因为交付的软件已经做到了合同中规定的一切。有些西方买家开始讽刺CMM，他们把CMM叫做“Costs More Money”（花更多的钱）。
事实上，按阶段方式定义流程（瀑布模型）的基础是一个假设，即客户知道他们将来需要什么，意味着客户必须在分析阶段就决定具体功能的内容。实际情况是，在项目的某些时间点，客户可能对变更的需求非常强烈，以至于要求项目必须适应这些变更。这时客户能做的选择少得可怜: 交付时间延期，付更多的费用，或者开始考虑第二个版本。
现在再看人们常说的“让开发软件如同建设桥梁”这句话也值得商榷。建桥所用的过程是为建设一个坚固耐用的产品而设计的，这种产品一旦建好就能用很多年。而对于重要的软件而言，在当前版本完成以后，它还有必要随着需求的变化而改变，正是由于这方面的原因，那些建立在工程学原理之上的软件过程方法无法很好地适应变化就毫不令人惊讶了。因为适应变化根本就不是其关注的东西。
