本节书摘来自异步社区《OOD启思录》一书中的第1章1.3节瀑布模型，作者【美】Arthur J.Riel，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.3 瀑布模型OOD启思录以往的范型把软件开发过程当作一条装配流水线，这已经不再正确。请看图1.1所示的传统的软件开发瀑布模型。在这一模型中，分析、设计、编码、测试和维护形成了5个独立的步骤，每个步骤都有精确定义的输入和精确定义的输出。每个阶段的过渡，输出工件都成为经理评估项目进度的依据。没过多久，软件与装配流水线的不同之处就显而易见了。想象一下，如果装配流水线上有一个环节速度太慢而拖累了其他环节，我们能采取的最佳行动是什么？比如，如果装配流水线正在组装洋娃娃，负责安装胳膊的工人太慢了而拖累了整条流水线，那么我们应当怎么办？显然，我们应当指派另外一位工人去协助原来安装胳膊的工人。这样，我们就可以消除瓶颈。那么，在软件工程中也尝试一下这种方法吧，结果多半是灾难性的。如果编码延迟了，项目经理无法简单地给开发团队增加一些人手。如果这样做的话，团队现有成员的生产效率会降低，因为他们需要花时间来指导新来的人。但是，很多公司依然在继续使用瀑布模型来开发项目。
或许瀑布模型易于理解，易于跟踪，并且符合经理人员的喜好，因为他们可以通过一系列精确定义的工件来跟踪进度。但是，对大系统开发者而言，这个模型并不能很好工作。事实上，我怀疑开发者是否真地用过这个模型。如果你在设计你的第15个邮件列表程序，这个模型可能会工作得很好。你已经创建过14个邮件列表程序了，现在你只需要稍稍修改一下你已有的分析模型和设计模型，并实现新的模型（这个新模型看上去和以往的14个非常像），然后测试它。但如果把一个负责折叠西装袖子的机器人实时进程控制系统的规约交给写邮件列表的这组开发者，并要求他们用瀑布过程来写出一个好的应用程序，这实在是无法想象的。我有太多的开发者朋友被要求用瀑布模型来应对不熟悉的领域，而他们的反应是：“噢，好吧，我会写那些规约以便让老板高兴，但我会以我想要的方式来编写真正的东西。”当然，错误的规约要比根本没有规约还糟。为什么不建立一个真正反映现实的软件开发过程呢？这样的过程应当包含回头修改设计、增加新的需求以及测试新的想法等要求。这样的过程被称作软件开发的迭代式过程。本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
相关资源：OOD启思录.PDF