瀑布模型的替代方案是什么

Question

您能给出一种方法来减轻瀑布模型的缺点吗？

Answer 1

瀑布的问题在于它由整体阶段组成，每个阶段都建立在前一个阶段上。因此，在设计整个系统后，代码将被分成一大块进行开发，而这又是在收集并签署所有需求之后进行的。

这是一个问题，因为任何变更都必须通过复杂的程序来批准，并波及所有阶段。但历史的教训是：改变总会发生。当我们开始编码时，需求总是不完整的，或者指定错误的，或者干脆已经过时了。很多时候，设计和构建都是基于假设进行的，而当系统达到 UAT 时，这些假设就失效了。这会导致疯狂的返工和延误。

事实上，没有多少客户擅长设想可工作的软件系统所需的抽象思维。而且太多的 IT 专业人员缺乏理解业务逻辑所需的经验。瀑布拒绝接受这些事实。

唯一诚实的需求规范是“我看到它就知道”。因此，尽快向真实用户提供可用的软件至关重要。任何专注于在短迭代中增量交付工作软件的方法都将“减轻瀑布模型的缺点”。

最初是 RAD 或 DSDM。然后XP 举起了横幅。现在有敏捷和相关的东西，例如Scrum 和看板。

那么为什么人们坚持使用瀑布方法？

人们普遍认为敏捷只是牛仔黑客的一个幌子，他们可以抛弃所有无聊的流程，继续做他们最喜欢的事情：编写代码。 “极限编程”的品牌无疑鼓励了这种想法，而且，说实话，这并不是毫无根据的指控。也就是说，一些程序员以敏捷为借口，不进行计划、设计或记录。这并不反映敏捷的实际实践，敏捷与任何其他方法论一样需要严格性。

此外，敏捷需要客户员工投入更多的时间，这是许多组织不愿意接受的。此外，买单的人可能不愿意授权初级员工做决定。 客户和用户之间有一个重要的区别。

在外包方面，瀑布模型提供了一个简单的框架，用于将可交付成果与分阶段付款相匹配。事实上，合同方面可能比这更强大：在欧盟，所有价值 1 亿欧元或以上的项目都必须使用瀑布。

最后，还有一些瀑布效果很好的项目。这些项目具有稳定且被客户和开发人员充分理解的知识领域。

最后一句话

尽管瀑布失败了，但它还是成功地交付了许多项目。这是因为努力、能力和诚信比方法论更重要。

Answer 2

1970 年，Winston Royce 博士在题为“管理大型软件系统的开发”的论文中记录了瀑布模型。基本上概述了他关于顺序开发的想法。他的想法是软件可以以与汽车类似的方式生产，其中车辆以顺序/线性阶段拼凑在一起。

这种线性方法实际上不允许软件一旦开始就进行更改。与最终用户/客户没有紧密的关系，因此很难概述可能的问题区域。

值得注意的是，瀑布模型的某些阶段允许“回击”，即在开发期间有足够的时间返回并进行小的更改。时间限制、涉及的工作量和预算实际上不允许使用此模型进行太大的改变（如果有的话）。

瀑布模型已经很古老了，随着时间的推移，软件范式本身也在发生变化。面向对象编程很流行，但当时它还几乎没有生命力。通过使用瀑布模型，很明显缺陷已经被发现，这导致了替代的开发方法。

好的，现在寻找替代方案。 Alistair Cockburn（2008）将增量模型描述为一种分期和调度策略，其中各个部分在不同的时间或速率开发，并在完成该特定部分后进行集成。

基本上增量看起来很像这样：

Analysis->Design->Code->Test
  Analysis->Design->Code->Test
  Analysis->Design->Code->Test

好处包括生命周期灵活并允许从一开始就进行更改。
工作软件或者更确切地说是部件是在早期快速生成的。由于进度迭代较小，生成的代码可以更早地进行测试和管理。并未预先收集系统的所有需求，而只是一个概要。这允许快速启动，但是在某些系统中这可能是一个缺点，因为可能会错过支持的系统架构等内容。

另一方面，迭代允许对系统的某些部分进行返工和修改以改进系统。为此留出时间。迭代并不是从完整的需求规范开始。开发是通过仅指定和实现软件的一部分来完成的。对软件进行审查是为了确定进一步的要求。这更像是一种自上而下的方法。这种方法的缺点是确保所有迭代都是兼容的。当每个新的迭代获得批准时，开发人员可以采用一种称为逆向工程的技术，这是一种系统的审查和检查程序，以确保每个新的迭代与以前的迭代兼容。不断迭代的一个主要好处是，客户可以保留循环中，最终产品应满足要求。

迭代方法图。

其他方法包括原型设计。进化和一次性。这些也被认为更像是自上而下的方法。这两个过程都借鉴了工程学。在工程学中，构建要建造的物体的比例模型是很常见的。构建模型允许工程师测试设计的某些方面。软件开发原型方法提供了相同的思想。原型设计并不被视为一种独立的、完整的开发方法，而是一种处理更大、更传统的开发方法中选定部分的方法。

一次性原型制作 - 一次性原型制作不保留已开发的原型。在一次性原型设计中，从来没有任何意图将原型转换为工作系统。相反，原型会快速开发出来，以演示系统设计中尚不清楚的某些方面。它还可以开发来帮助用户或客户在不同的功能或界面特征之间做出决定。一旦任何问题或不确定性得到解决，原型就可以被“扔掉”，所学到的原理可以用于实际产品的设计和文档记录。

进化原型 - 在进化原型中，您首先对目标系统的各个部分进行建模，如果原型制作过程成功，您就可以从这些部分进化出系统的其余部分。这种方法的一个关键方面是原型成为实际的生产系统。此过程允许系统的困难部分在原型中成功建模并在项目的早期进行处理。

其他需要研究的领域将包括敏捷-> SCRUM、极限编程、结对编程等。

试图保持简短，但人们写了关于这类内容的书籍，而且有很多东西可以讨论。

可能值得一看：
增量和迭代

Answer 3

瀑布方法的替代方法是“以正确的方式进行”。

如果您在工厂车间的装配线上，瀑布似乎很有意义。但我从未见过它作为设计过程的一部分起作用……而软件开发就是一个设计过程。因此，瀑布方法从来没有真正起作用，因为它无助于促进高质量产品的创建，而是专注于过程。过程可以很棒，但如果它生产的产品是二流的，那还有什么意义呢？

Answer 4

看板和 Scrum 是瀑布最常用的两种替代方案。我试图对不同的 SDLC 方法。

正如 APC 提到的，瀑布严重依赖于大量的整体相。这是一个巨大的弱点，因为试图从一开始就确定最终产品是徒劳的。

看板有点牛仔风格，但我发现如果你将它与站立会议结合起来，它肯定仍然有一席之地。

Scrum 非常适合向团队施加压力并获得门票所有权。我发现大多数地方都在采用这种做法，但它的缺点是有些人过分地召开会议来处理所有事情。 Sprint 计划会议、Sprint 启动会议、持续 1 小时、有 20 多人出席的每日站立会议、演示会议，最后是事后分析。

请记住，敏捷的好坏取决于您的实践，如果您疯狂地进行无限制的会议，而这些会议不会增加价值，那么您很容易就会沉迷于任何方法。尽可能保持精简而不混乱。

Answer 5

从我的头脑中，我可以想出一些方法来减轻瀑布模型的缺点：

• 让编码人员专注于流程本身的自动化。自动执行一个步骤与另一个步骤之间的转换，以便更改或多或少自动进行。
• 使流程更加双向。瀑布模型的一个主要特征是从上到下改变流量。这是一个单向过程，也是问题的一部分。

另一件有帮助的事情是（正如前面的答案中有人提到的那样）是让开发人员更好地理解所涉及的业务逻辑以及客户想要什么，并让客户获得有关开发特征的知识过程。

Answer 6

以下是有关瀑布模型的一些链接：

http:// /www.cs.odu.edu/~zeil/cs451/Lectures/01overview/process2/process2_htsu2.html

http://www.buzzle.com/editorials/3-13-2005-67039.asp