您能否提供一种方法来缓解瀑布模型的缺点？
答案 0 :(得分：16)
瀑布的问题在于它由整体阶段组成，每个阶段都在前一阶段。因此，代码是在整个系统设计完成后的一个块中开发的，而这又是在收集并签署所有需求之后发生的。
这是一个问题，因为任何变化都必须通过复杂的程序来批准，并在所有阶段中起到作用。但历史的教训是：改变发生了。在我们编码时，要求总是不完整，或错误指定或仅仅是过时的。通常基于在系统到达UAT时无效的假设来设计和构建。这导致了疯狂的重新工作和滑点。
事实并非许多客户擅长设想一个有效的软件系统所需的抽象思维。太多的IT专业人员缺乏理解业务逻辑所需的经验。瀑布拒绝接受这些真相。
唯一诚实的要求规范是“当我看到它时我会知道它”。因此，尽快将工作软件放在真实用户面前至关重要。任何专注于在短迭代中递增地提供工作软件的方法都将“缓解瀑布模型的缺点”。
最初是RAD或DSDM。然后XP抬起横幅。现在有Agile和相关内容，例如Scrum和Kanban。
那么为什么人们坚持使用瀑布法？
人们普遍认为，敏捷只是掩盖了牛仔黑客抛弃所有无聊过程的东西并继续他们最喜欢的东西：编写代码。 “极限编程”的品牌肯定会鼓励这种想法，而且说实话，这不是一个毫无根据的指控。也就是说，一些程序员假装敏捷是不计划，设计或记录的借口。这并不反映敏捷的实际做法，它需要与任何其他方法一样严格。
敏捷也需要客户的工作人员更多的时间，许多组织都不愿意接受。支持该法案的人也可能不愿意让初级员工做出决策。 Customer 和 User 之间存在重要区别。
在外包方面，瀑布模型提供了一个简单的框架，用于将可交付成果与分阶段付款相匹配。事实上，合同方面可能比那更强：在欧盟瀑布的所有项目都要求价值1亿欧元以上。
最后，还有一些瀑布运作良好的项目。这些项目拥有知识领域，这些知识领域是稳定的，并且得到了客户和开发人员的充分理解。
最后一句话
尽管失败，瀑布已成功交付了许多项目。这是因为努力工作，才能和诚信比方法更重要。
答案 1 :(得分：4)
瀑布模型由Winston Royce博士于1970年在题为“管理大型软件系统的开发”的论文中记录。基本概述了他对顺序开发的看法。他的想法是，软件可以以类似于汽车的方式生产，其中车辆以顺序/线性阶段拼接在一起。
这种线性方法一旦开始就不能真正改变软件。与最终用户/客户没有紧密的关系，因此更难以概述可能的问题区域。
值得注意的是，瀑布模型的某些阶段允许“回弹”，从而在开发期间有足够的时间返回并进行小的更改。如果使用这种模式，时间限制和所涉及的工作量和预算实际上不会有太大的变化。
瀑布模型是旧的，随着时间的推移，软件范例本身也会发生变化。面向对象的编程很受欢迎，当时它几乎没有活着。通过瀑布模型的使用，很明显发现了缺陷，这导致了替代的开发方法。
好的，现在是替代品。 Alistair Cockburn（2008）将增量模型描述为一种分期和调度策略，其中各个部分以不同的时间或速率开发，并在完成特定部分时进行集成。
基本上增量看起来很像这样：
Analysis->Design->Code->Test
Analysis->Design->Code->Test
Analysis->Design->Code->Test
许多好处包括生命周期的灵活性和允许从一开始就改变。 工作软件或更确切地说，部件是在早期快速生成的。由于进度的小迭代，生成的代码更早进行测试和管理。并非系统的所有要求都是预先收集的，只是概述。这样可以快速启动，但在某些系统中可能会有缺点，因为可能会错过支持的系统架构等。
另一方面，迭代允许对系统的某些部分进行重新设计和修改以改进系统。留出时间来考虑这一点。迭代不是从完整的要求规范开始的。通过指定和实现部分软件来完成开发。审核软件以确定进一步的要求。这更像是top down方法。这种方法的缺点是确保所有迭代都是兼容的。随着每个新迭代的批准，开发人员可以采用一种称为向后工程的技术，这是一种系统的审查和检查程序，以确保每个新的迭代与以前的迭代兼容。持续迭代的一个主要好处是客户端保持不变在循环中，最终产品应符合要求。
其他方法包括原型设计。进化和吞噬。这些也被视为自上而下的方法。这两个过程都是从工程中借用的。在工程中，通常构建要构建的对象的比例模型。建筑模型允许工程师测试设计的某些方面。软件开发原型方法提供了相同的意识形态。原型设计不是一种独立的，完整的开发方法，而是一种处理更大，更传统的开发方法的选定部分的方法。
Throwaway Prototyping - Throwaway原型设计不能保留已开发的原型。在一次性原型设计中，从来没有任何意图将原型转换为工作系统。而是快速开发原型以展示系统设计的某些方面，这一点尚不清楚。它还可以开发用于帮助用户或客户决定不同的功能或界面特征。一旦解决了任何问题或不确定性，就可以“抛弃”原型，并在实际产品的设计和文档中使用原理。
进化原型 - 在进化原型设计中，您首先对目标系统的各个部分进行建模，如果原型设计过程成功，您可以从这些部分进化系统的其余部分。这种方法的一个关键方面是原型成为实际的生产系统。这个过程允许系统的困难部分在原型中成功建模，并在项目的早期处理。
其他需要研究的领域包括Agile-＆gt; SCRUM，极限编程，配对编程等。
试图保持简短，但人们在这类东西上写书，还有很多事要讨论。
可能值得一看： Incremental and Iterative
答案 2 :(得分：2)
瀑布方法的替代方法是“以正确的方式”。
如果您在工厂车间装配线上，瀑布似乎有意义。但我从来没有看到它作为设计过程的一部分......而且软件开发完全是一个设计过程。所以瀑布式方法从未真正起作用，因为它无助于促进高质量产品的创造，而是专注于流程。流程可能很棒，但如果它生产的产品是二流的话，那又有什么意义呢？
答案 3 :(得分：0)
从头脑中，我可以想办法减轻瀑布模型的缺点：
另一件有用的事情是（正如前面的答案中提到的那样）是让开发人员更好地理解所涉及的业务逻辑，以及客户想要的内容，以及让客户获得有关特性的知识发展过程。
答案 4 :(得分：0)
Kanban和Scrum是瀑布最常用的两种替代品。我尝试对不同的SDLC approaches进行了很好的概述和比较。
瀑布很大程度上依赖于APC提到的巨大的整体阶段。这是一个巨大的弱点，因为从一开始就试图确定最终产品是一项徒劳无功的努力。看板有点牛仔，但我发现如果你把它与立式镜头结合在一起它肯定还有它的位置。
Scrum非常适合给团队施加压力并获得门票的所有权。我发现大多数地方都在这个地方，但是它的垮台是有些人为了应对所有事情而过火了。 Sprint计划会议，sprint启动会议，每天站立会议，持续20个人在场，模拟会议，最后是验尸。
请记住，敏捷只会和你做的一样好，而且如果你疯狂地参加不能增加价值的无限制会议，你就可以轻松地接受任何方法。尽可能保持精益，不要让它变得混乱。
答案 5 :(得分：-1)
