【问题标题】:(Rational) Unified Process vs Waterfall Model(理性的)统一过程与瀑布模型
【发布时间】:2013-12-13 06:35:53
【问题描述】:

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

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

【问题讨论】:

  • 那么我们是否可以断定UP类似于快速应用开发模型或分阶段开发模型?
  • 我已经在下面回答了,但请注意,由于问题的潜在主观性质,这对 SO 来说不是一个好的问题格式。
  • 我投票结束这个问题,因为它不是关于编程的。

标签: waterfall rational-unified-process


【解决方案1】:

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

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

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

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

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

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

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

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2019-10-28
    • 1970-01-01
    • 2019-04-05
    • 1970-01-01
    • 2013-12-02
    • 2018-12-05
    • 2020-01-14
    • 2013-03-03
    相关资源
    最近更新 更多