下载掌阅APP，畅读海量书库
立即打开
在瀑布（或顺序）生命周期过程中，试图在编程之前（详细）定义所有或大部分需求。而且通常于编程之前创建出完整的设计（或模型集）。同样，会试图在开始前定义“可靠的”计划或时间表，但常常事与愿违。
警告：叠加瀑布于迭代
如果你发现自己在“迭代”项目中出现开发前确认大多数需求，编程前试图创建完整、详细的规格说明或UML模型和设计，那么说明瀑布思维已经在无情地折磨着这个项目了。无论如何声称，这都不是正常的迭代或UP项目。
现在的研究（汇集众多材料并在[Larman03]和[LB03]中总结）最终表明，20世纪60年代到70年代所推崇的瀑布方法（颇为讽刺），对于大多数软件项目是拙劣的实践而非巧妙的方法。它与高失败率、低生产率和高缺陷率具有极大关系（与迭代项目相比）。平均而言，瀑布方法需求中45%的特性从未被使用，其早期时间表和估计与最终实际情况可相差400%。
事后，我们才知道提倡瀑布方法源于推测和风闻，而非实践证实。与之相反，迭代和进化式开发为实际证据所支持，研究表明其失败的几率更小，与更理想的生产率和缺陷率相关。
需要强调的是，“瀑布思维”仍然时常侵蚀着所谓的迭代或UP项目。“让我们在开始编程前编写完所有用例”或“让我们在开始编程前用UML完成更多详细的OO模型”，诸如这些想法都是不健康的瀑布思维错误地叠加在UP上的例子。UP创立者引证了这一误解（初始阶段进行大量的分析和建模）是导致其失败的一个关键原因[KL01]。
为什么瀑布模型具有如此的错误倾向？对此并没有一个简单的答案。但是，它与众多失败软件项目背后的关键错误假设具有密切联系。这一假设是，规格说明是可预知的和稳定的，并且能够在项目开始时就正确定义，同时具有低变更率。这种假设与事实背道而驰，而且导致了代价高昂的误解。Boehm和Papaccio的研究表明，典型的软件项目在需求上会经历25%的变更[BP88]。并且，这一趋势在另一个对数千软件项目的重要研究中得到确认，对于大型项目，其变更率甚至高达35%到50%，如图2-3所示[Jones97]。
图2-3 各种规模软件项目的变更百分比
这一领域的高变更率是种极端。正如任何有经验的开发者或管理者所意识到的，图中的数据表明软件开发是（平均而言）变更极大且不稳定的领域，也被认为是新产品开发（new product development）的领域。软件通常并不是可预知的或可以大规模制造的，大规模制造领域属于低变更领域，在开始阶段可以有效地定义所有稳定的规格说明和可靠的计划。
因此，任何基于事物长期稳定这一假设所作出的分析、建模、开发或管理实践（即瀑布模型）都是具有根本缺陷的。变更对于软件项目来说是永恒的。迭代和进化式方法正视并包容了变更，并且根据反馈对局部和进化的规格说明、模型和计划进行改写。
在复杂、变更系统中（如大多数软件项目），反馈和调整是成功的关键要素。
·来自早期开发中的反馈，有助于程序设计人员理解规格说明，客户演示也有助于精化需求。
·来自测试中的反馈，有助于开发者精化设计或模型。
·来自团队处理早期特性过程的中反馈，有助于精化时间表和估计。
·来自客户和市场的反馈，有助于重新定义下一次迭代实现特性的优先级。
