瀑布模型的问题是什么？ - IT 观察者随笔

Table of Contents hide

对于某些工程设计领域，瀑布模型是一种相对线性的顺序设计方法。

在软件开发中，它往往是较少迭代和灵活的方法之一，因为进展在很大程度上是向下流动的，就像瀑布一样，通过概念、启动、分析、设计、构建、测试、部署和维护等阶段。在软件开发项目中使用的阶段通常如下所示：

一、要求

如果您从事软件开发或任何类型的项目创建团队，您会想知道您尝试创建的业务环境——您想定义您尝试解决的问题类型以及人们对您的反应的反应完成的产品。在您定义了所有这些“要求”之后，您就有了进入下一步所需的输入。

2. 设计

此步骤由满足您之前确定的所有要求所需的所有步骤组成。在软件开发中，这是您定义所有软件和硬件架构、编程语言、数据存储等的部分。这也是您确定项目如何对其最终用户有用的部分。

3. 实施

在这一步中，您开始构建您在计划中设计的内容。瀑布方法的这一部分致力于满足您在前面的步骤中制定的标准。这是开发团队的人进来并让前面步骤中讨论的所有事情发生的部分。

4. 验证

这是质量保证人员进入以确保开发团队没有犯任何错误的方法的一部分。这也很可能是人们意识到他们的计划中哪些有效或无效的部分。

注意

当项目开发人员对所有事情都满意时，如果项目准备好启动，客户或最终用户就会进来并做出最终决定。

瀑布方法指出，当某个特定阶段出现问题时，人们可以回到前一个阶段，看看出了什么问题。例如，如果计划实施中出现问题，人们知道他们只是按照交给他们的蓝图进行操作，那么管理者就会查看他们的计划并从那里进行修改。

客户在看到工作软件之前可能并不确切地知道他们的需求是什么，因此会改变他们的需求，从而导致重新设计、重新开发和重新测试，并增加成本。

开发人员在设计新的软件产品或功能时可能没有意识到未来的困难，在这种情况下，最好修改设计而不是坚持不考虑任何新发现的约束、要求或问题的设计。

因此，不能保证组织所考虑的要求会真正起作用。从这里，您会意识到瀑布模型存在以下问题：

1. 人们盲目地遵循计划。

在传统的方法中，人们更多地关注事情在正确的时刻会如何发生，而不去注意事情是否真的到位。虽然计划很重要，但开发人员和质量检查人员了解事情应该如何发生也很重要，尤其是与客户或最终用户。同样重要的是，所有参与项目的人都可以立即说出项目执行中的特定步骤如何在无需等待测试阶段的情况下崩溃。

2. 顺序流程和变更成本高昂

这种方法没有考虑到随着项目的进展而改变定义的需求。因此，软件很可能无法完全满足用户的需求，效率低下，功能差。

这是不够的，因为开发人员不能随着消费者需求的变化而返回并更改前一阶段的某些内容，而是开发人员必须回到需求需要更改的地方并重新开始该阶段。直到那个阶段完成，他才能进入下一个阶段。

3. 最终用户不知道他们想要什么。

大多数时候，最终用户的想法是不断变化的，大多数人对他们的软件需求有一个模糊的概念，并且随着软件的发展，他们指定了他们的需求。

当到了将成品交给客户的时候，他们很可能不喜欢结果，尽管在最初阶段故意说不同。随着时间的推移，客户和最终用户很容易改变他们想要的东西。瀑布系统还没有办法解决这个问题，而无需修改计划并完全重做整个项目。

4. 质量测试可能会受到影响。

一个项目的结果是无法准确预测的，当整个团队时间紧迫时，为了赶上最后期限，缩短测试阶段是可能的。

5. 你永远不知道自己真正处于什么阶段。

由于您尝试创建的产品直到最后才会生产，因此您不确定您是否仍在计划中或已经处于开发阶段。这意味着由于能见度差，您在舞台上花费的时间也可能比您预期的要多。

最后，瀑布方法可能太冒险了，因为它太死板了。为了让您生产出有效且足够灵活的产品，以帮助您确定什么有效或无效。