(Rational)统一流程与瀑布模型

Question

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

有人能帮我弄清楚这两者之间的区别吗？

Answer 1

您还没有指定‘哪个’统一过程或‘哪个’瀑布过程--两者都有许多变体，因此一些比较将在泛化中丢失。

以Rational Unified process为例，它与瀑布过程的不同之处在于，规程(分析、设计、编码、测试等)是迭代和并行完成的，而在waterfall processes中，规程通常是按顺序完成的(例如，编码仅在需求最终确定和设计被接受后才开始)。

在RUP中，术语phases (初始、精化、构建、转换)并不是专门针对单个规程或单个可交付件的-- RUP阶段都是初始阶段--例如，尽管初始阶段主要是关于需求和分析的；一些设计和原型编码也被鼓励来降低风险并改进对未来阶段的估计，甚至在构建阶段，可能需要进一步的分析。

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

另一个主要区别是RUP将可视模型的概念(特别是统一建模语言)作为描述需求、高级和类级设计(在某些情况下，可以从详细的统一建模语言模型生成代码)的可交付工件，而瀑布工件通常是非常繁重的文档(例如，ESA / IEEE processes)

另一个不同之处在于商业参与的方法。瀑布通常促进“合同”软件需求或软件规范文档的概念，该文档定义了可交付件(功能上和非功能上)，项目预算或固定价格交易将基于该文档。相反，RUP在每个阶段的基础上促进预算，例如，下一阶段的工作/成本将被知道/迭代/改进，因为前一阶段的可交付成果之一已经交付。

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