【IT168 信息化】

    CMM等软件过程标准最初是由于印度软件提供商的积极采纳而人们所熟知的，印度软件厂商也最先达到最高的一致性标准——CMM 5，他们让市场认为CMM（特别是CMM 5）就意味着能够可靠、可预测地交付高质量的商业软件，再加上印度极具优势的劳动力价格和大量受过训练的程序员，特别是印度的软件公司还是流程方面的天才。使得软件开发项目以惊人的价格潮水般地涌入印度，让印度软件公司很快成为软件开发、软件维护、系统集成与运营等与软件相关的各种项目的主角。

    印度式软件模式的困境

    CMM由于其提高交付成功率的办法而大受青睐。CMM注重过程、度量标准以及可重复性，从某种意义上说它确实让交付变得更加可预测，并且在某些特定情况下，一些变更造成的影响也变得更加可预测。但在CMM管理下的“瀑布模型”给软件开发带来高度纪律性的同时，用户对软件开发的满意度并未提高。

    问题的根源在于：业务需求的变化促使企业不断调整它们的软件平台。在CMM模式下，瀑布式开发过程虽然已经很清楚地定义了需求变更的处理过程，但需求变更的成本非常高，即使很小的变更也需要大量的流程和返工。因此企业经常会陷入两难的境地：要么重新制定关键项目的计划并接受延期发布，要么将新需求推迟到下次软件发布再完成。而当今的商业环境瞬息万变，几个月的拖延往往意味着失去大量的市场份额。

    在一些项目中，印度的软件公司引发了客户事后的强烈不满，因为交付的软件并不符合客户当前的需求。更让客户难以接受的是，CMM 5过程的严格导致客户的不满完全是客户自己的责任，因为交付的软件做到了合同中规定的一切。新的西方买家逐渐开始讽刺CMM，他们把CMM叫做“Costs More Money”（花更多的钱）。

    事实上，按阶段方式定义流程（瀑布模型）的基础是一个假设，即客户知道他们将来需要什么。客户必须在分析阶段就决定具体功能的内容。实际情况是，在项目的某些时间点，客户可能对变更的需求非常强烈（单个需求或者所有小变更的集合），以至于需要项目必须适应这些变更。这时客户能做的选择少得可怜：交付时间延期，付更多的费用；或者开始考虑第二个版本。

    现在回头“开发软件如同建设桥梁”这句话。建桥所用的过程是为建设一个坚固耐用的产品而设计的，这种产品一旦建好就能用很多年。而对于重要的软件而言，在当前版本完成以后，它有必要随着需求的变化而改变，正是由于这方面的原因，那些建立在工程学原理之上的软件过程方法无法很快地适应变化就毫不令人惊讶了。因为适应变化根本就不是其关注的东西。