瀑布模型测试与敏捷有什么优势吗？

Question

我已经读了很多关于敏捷和瀑布的信息，我只是想不出任何理由为什么今天的人应该做瀑布。我特别关心测试过程。我是不是错过了什么，是不是有什么明显的优势被我忽略了？

Answer 1

仍然有一些情况下瀑布是合适的。典型的例子包括军事、太空、医疗和安全关键系统，如飞行控制软件，在这些系统中，您绝对需要首先确定确切的详细规格，开发它，然后彻底测试整个产品。

敏捷适用于大多数业务和产品软件(即大多数已构建的软件)，因为它允许用户从粗略的想法开始，并在进行过程中对其进行改进。如果他们的网站或内部业务线应用程序在几次迭代中不太正确(或有bug)，那么它通常会被那些确实有效的部分快速交付的业务价值所取代。你不会想一开始就对核电站控制器系统有一个粗略的想法，然后在进行过程中对其进行改进。

使用纯瀑布的权衡是，在这些场景中开发软件的成本要高出几个数量级。然而，成本效益仍然是有利的，因为你负担不起(比方说)你的航天器在轨道中途遇到空指针异常。

当然，在两者之间也有一些灰色的阴影。在瀑布框架中使用敏捷技术是可能的(参见RUP)，并且可以在纯瀑布和纯敏捷之间扩大和缩小平衡。

Answer 2

开发的瀑布模型的主要优点之一是，它已经被使用了很多年。它起作用了。尽管有一个很大的转变和对敏捷的关注，瀑布是一个非常清晰的过程，有开发的每个部分的起点和终点。

随着敏捷编程的引入，很容易看到瀑布的衰落，以及它如何不能适应当今编程的需求。

只要你谨慎，提前计划，充分测试，我会说敏捷测试可以和瀑布一样有效，甚至更有效-当测试抛出一些可能导致您的设计更改的错误时，使用敏捷肯定更容易。

另一件要考虑的事情是使用开发，测试驱动开发。http://en.wikipedia.org/wiki/Test-driven_development

Answer 3

外包

我看到许多公司在外包项目中坚持使用瀑布。当涉及到报价时，大多数供应商都会非常具体。瀑布非常适合这个模型--你把你想要的交给他们，他们就会生产出来。我对此并不感兴趣，但我可以理解以这种方式执行的理由。我认为大多数外包公司最终会找到一种方法来变得更加敏捷，因为它越来越成为行业标准。