瀑布模型[关闭]答案

【问题标题】：Waterfall model [closed]瀑布模型[关闭]
【发布时间】：2020-11-18 09:25:59
【问题描述】：

我正在考虑使用瀑布模型作为我的 CS 考试的主要开发方法。我有使用统一流程和敏捷方法（如 SCRUM 和 XP）的经验。所有这些都有清晰和结构化的方式来收集任务、用例或用户故事。但我似乎找不到瀑布模型的等价物。

所以我的问题是，瀑布模型是否有任何特定的方式来收集你的“用例/用户故事”（或任何你可能称之为的） - 或者我应该从前任那里借一些。 UP，并使用用例？

【问题讨论】：

用例应该在瀑布的第一阶段就定义好，因为你可以在这个阶段完成所有的设计。用户故事不是瀑布中的东西，但需求是。基本上，您不会有“作为用户，我希望界面丰富多彩”，而是设计阶段的要求。另见this
谢谢。但是在使用瀑布模型时，用例是强制性元素吗？
没有，据我所知。但是，根据我在软件（任何）行业的经验，你总是会从你的产品的至少一个用例开始：回答“我为什么要开发这个东西”这个问题。无论如何，您最终都会得到一些“用例”文档。这是基于意见和经验的，不是一个好的答案。

标签： task project-management use-case requirements waterfall

【解决方案1】：

瀑布、统一流程和敏捷方法在活动组织方式上有所不同：

他们都需要以某种方式涵盖所有软件开发活动，例如收集需求、设计系统、实现其功能以及测试结果并交付。
它们中的每一个都以不同的方式打包和组合这些活动：例如，敏捷倾向于将所有这些活动组合在一起以交付软件增量的小迭代，直到一切都完成。在另一个极端，瀑布式将这些活动一个接一个地分开，只有在出现重大问题时才进行交付和迭代（回到实现或回到需求）。

在开展这些活动时，您可以使用一组实践来帮助您更有效地实现结果。实践有时会出现在方法的上下文中，但通常可以概括为在其他上下文中使用。例如：

在Waterfall 上下文中，需求是预先编写的。仅当需求非常清楚并且不经常更改时，这才有效。在学习项目的情况下，您很可能处于这种情况。

如今，此类要求使用 IEEE 标准 Software Requirement Statements (SRS) 进行记录。通常，本文档的功能部分是根据use-cases 构建的（不一定是用例图）。此外，现代用例，即所谓的Use-case 2.0，演变成一种更敏捷的实践，允许收集“用户故事”（用户叙述）以制作用例切片，逐渐丰富用例。这种方法实际上与将叙述线分解为详细的用户故事的用户故事映射（定义高级叙述线）非常相似。

所以，是的，您可以借用这些技术中的任何一种，但瀑布式需要预先准备好一切。由于用例可以在瀑布式（传统用例）或敏捷（用例 2.0）中使用，因此在您的上下文中它肯定是一个很好的基础。对于学校作业，根据用例构建的 SRS 肯定会给人留下好印象。但是，如果您想要一种面向任务的方法，并且如果所有需求都还不清楚，我真的建议您使用用例 2.0 或用户故事映射，并避免瀑布。

【讨论】：