waterfall - （理性的）统一过程与瀑布模型

Question

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

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

Answer 1

您没有指定“哪个”统一流程或“哪个”瀑布流程 - 两者都有很多变体，因此一些比较在概括时会丢失。

以Rational Unified 流程为例，它与瀑布流程的不同之处在于学科（分析、设计、编码、测试等）是迭代和并发地完成的，而在瀑布流程中，学科通常是按顺序完成的（例如，编码只开始一次要求已定稿，设计已被接受）。

在 RUP 中，术语phases（初始、细化、构建、过渡）并不专用于单个学科或单个可交付成果——RUP 阶段都是多学科的——例如，尽管初始阶段主要是关于需求和分析；还鼓励进行一些设计和原型编码，以降低风险并改进对未来阶段的估计，即使在施工阶段，也可能需要进一步分析。

RUP 使用术语“生成”来表示另一个完整的开发周期，例如，对于项目的“版本 2”，第 2 代的新工作将在初始阶段开始。

另一个主要区别是 RUP 将可视模型（尤其是 UML）的概念作为描述需求、高级和类级别设计的可交付工件（在某些情况下可以从详细的 UML 模型生成代码）的概念，而瀑布工件通常非常文件繁重（例如ESA / IEEE 流程）

另一个不同之处在于商业参与的方法。Waterfalls 通常提倡“合同”软件需求或软件规范文档的概念，它定义了可交付成果（功能性和非功能性），并以此为基础制定项目预算或固定价格交易。相反，RUP 促进了基于每个阶段的预算编制，例如，随着前一阶段的可交付成果之一已经交付，下一阶段的工作量/成本将是已知的/迭代的/改进的。

在许多软件开发操作中，敏捷过程已经取代了瀑布和 RUP，尽管瀑布和 RUP 的许多工件和学习仍然存在。敏捷的主要好处是将工作分解成更小的块（通常是 2 周的 sprint，而不是长达数月的 RUP 阶段或长达一年的瀑布项目）。这种快速周转允许在成本与优先级的基础上交付功能，更好地适应不断变化的需求，并允许比瀑布或 RUP 更快地识别成功的障碍。敏捷还减少了很多浪费——让我们面对现实吧，只有一小部分开发人员曾经阅读过详细的规范文档或仔细研究过详细的 UML 图。