原文英文版: What is the Problems of Waterfall Model? （日本語）
瀑布模型是一种相对线性的顺序设计方法，适用于某些工程设计领域。
在软件开发中，它往往是较少迭代和灵活的方法之一，因为进展在很大程度上向下流动，如瀑布，通过概念，启动，分析，设计，构建，测试，部署和维护的阶段。在软件开发项目中，阶段通常如下所示：
瀑布模型
1.要求
如果您从事软件开发或任何类型的项目创建团队，您可能想知道您要创建的业务环境 - 您想要定义您要解决的问题以及人们如何对您做出反应完成的产品。定义所有这些“要求”后，您需要输入以继续下一步。
2.设计
此步骤由满足您之前确定的所有要求所需的所有步骤组成。在软件开发中，这是您定义所有软件和硬件体系结构，编程语言，数据存储等的部分。这也是您确定项目如何对其最终用户有用的部分。
3.实施
在此步骤中，您将开始构建计划中设计的内容。瀑布方法的这一部分致力于满足您在前面步骤中所做的标准。这是开发团队的人员进入并完成前面步骤中讨论的所有事情的部分。
4.验证
这是质量保证人员进入的方法的一部分，以确保开发团队不犯任何错误。这也很可能是人们意识到在他们的计划中工作或不工作的部分。
注意
当项目开发人员满足所有要求时，如果项目已准备好启动，则客户端或最终用户会进入并进行最终调用。
瀑布方法表明，当某个特定阶段出现问题时，人们可以回到前一个，看看出了什么问题。例如，如果计划实施中存在问题，并且人们知道他们只是按照已经移交给他们的蓝图，那么管理人员会查看他们的计划并从那里进行修改。
瀑布的问题是什么？
前期要求问题 - 计划与现实
客户在看到工作软件之前可能不知道他们的要求是什么，因此改变了他们的要求，导致重新设计，重新开发和重新测试，并增加了成本。
在设计新的软件产品或功能时，设计人员可能不会意识到未来的困难，在这种情况下，修改设计比保留在不考虑任何新发现的约束，要求或问题的设计中更好。
因此，无法保证组织所考虑的要求实际上会起作用。从这里，您会发现Waterfall模型存在以下问题：
1. 人们盲从计划。
在传统的方法中，人们更加关注事物在恰当的时刻将如何发生而不注意事物是否真的到位。虽然规划很重要，但开发人员和质量检查员理解事情应该如何发生也很重要，尤其是对于客户或最终用户。同样重要的是，参与项目的所有人都可以立即说明项目实现中的特定步骤如何在不必等待测试阶段的情况下崩溃。
2. 顺序过程和变更变得昂贵
随着项目的进展，这种方法不允许更改定义的需求。因此，软件很有可能不能完全满足用户的要求，效率低，功能差。
这是不够的，因为开发人员不能仅仅因为消费者需求的变化而返回并改变前一阶段的某些内容，但开发人员必须回到需求需要改变的地方，并开始全面开始这个阶段。直到该阶段完成，他才能进入下一阶段。
3. 最终用户不知道他们想要什么。
大多数时候，最终用户的想法是不断变化的，并且大多数人对他们的软件需求有一个模糊的概念，并且随着软件开发他们指定他们的要求。
当需要将成品交给客户时，尽管在初始阶段故意另有说法，但很可能他们不会喜欢它的结果。客户和最终用户可以轻松地随着时间的推移改变他们想要的东西。瀑布系统无法解决这个问题，无需修改计划并完全重做整个项目。
4. 质量测试可能会受到影响。
不可能准确地预测项目的结果，并且当整个团队按时间时，可以缩短测试阶段以满足截止日期。
5. 你永远不会知道你到底是什么阶段。
由于您尝试创建的产品直到最后才会生成，因此您不确定是否仍在进行规划或者您已经处于开发阶段。这意味着由于可见度差，您可能会花费更多时间在舞台上。
最后，瀑布方法风险太大，因为它过于僵化。为了让您生产出有效的产品，并且足够灵活，可以帮助您弄清楚什么在起作用。