waterfall - (理性的)统一过程与瀑布模型

Question

我正在阅读有关软件开发模型和生命周期的内容，在那里我了解了瀑布模型和统一流程。然而，这两个过程都涉及需求收集、设计阶段、开发测试和部署(统一过程中的初始、细化、构建和过渡阶段)。

任何人都可以帮助我解决两者之间的区别吗？

Answer 1

您没有指定“哪个”统一流程或“哪个”瀑布流程 - 两者都有很多变体，因此一些比较在概括时会丢失。
以 Rational Unified process 为例，它与瀑布过程的不同之处在于学科(分析、设计、编码、测试等)是迭代和同时完成的，而在 waterfall processes ，这些学科通常是按顺序完成的(例如，只有在需求最终确定并接受设计后才开始编码)。
在 RUP 中，术语 phases (开始、细化、构建、过渡)不专注于单一学科或单一可交付成果 - RUP 阶段都是 multi disciplinary - 例如尽管 Inception 主要是关于需求和分析；还鼓励进行一些设计和原型(prototype)编码，以降低风险并改进对 future 阶段的估计，即使在施工阶段，也可能需要进一步分析。
RUP 使用术语“生成”来表示另一个完整的开发周期，例如对于项目的“第 2 版”，第 2 代的新工作将在初始阶段开始。
另一个主要区别是 RUP 将可视模型(尤其是 UML)的概念作为描述需求、高级和类级别设计的可交付工件(在某些情况下可以从详细的 UML 模型生成代码)的概念，而瀑布工件通常非常文件重(例如 ESA / IEEE processes )
另一个不同之处在于商业参与的方法。 Waterfalls 通常提倡“契约(Contract)”软件需求或软件规范文档的概念，该文档定义了可交付成果(功能性和非功能性)，并以此为基础制定项目预算或固定价格交易。相反，RUP 提倡按阶段编制预算，例如并且下一阶段的工作量/成本将是已知的/迭代的/改进的，因为前一阶段的可交付成果之一已经交付。
在许多软件开发操作中，Agile processes已经取代了 Waterfall 和 RUP，尽管 Waterfall 和 RUP 的许多人工制品和知识仍然存在。敏捷的主要好处是将工作分解成更小的 block (通常是 2 周的 sprint，而不是长达数月的 RUP 阶段或长达一年的瀑布项目)。这种快速周转允许在成本与优先级的基础上交付功能，更好地适应不断变化的需求，并允许比瀑布或 RUP 更快地识别成功的障碍。敏捷还减少了很多浪费——让我们面对现实吧，只有一小部分开发人员曾经阅读过详细的规范文档或仔细研究过详细的 UML 图。