问瀑布模型

EN

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

• 它们都需要以某种方式覆盖软件开发活动的各个方面，如收集需求、设计系统、实现其特性、测试结果和交付。
• 它们中的每一个都以不同的方式打包和组合这些活动:例如，敏捷倾向于将所有这些活动组合在一起以交付软件增量的小迭代，直到一切都完成为止。在另一个极端，瀑布将这些活动一个接一个地分开，只有在有重大问题的情况下，才有交付和迭代(返回实现或返回需求)。

在执行这些活动时，您可以使用一组帮助您更有效地实现结果的实践。实践有时出现在一种方法的背景下，但通常可以推广到其他情况下使用。例如：

在瀑布上下文中，需求是预先编写的。只有在需求非常清楚且不经常更改的情况下，这才能很好地工作。在一个学习项目中，你很可能处于这样的情况。

目前，这类需求都是用软件需求报表(SRS)的IEEE来记录的。通常，本文档的功能部分是根据用例 (不一定是用例图)构建的。此外，现代用例，即所谓的用例2.0，演变成一种更灵活的实践，它允许收集“用户故事”(用户描述)，使用例切片逐渐丰富用例。实际上，这种方法非常类似于用户故事映射(它定义了一个高层次的叙事线)，它将叙事线分解成详细的用户故事。

所以是的，你可以借用这些技巧中的任何一种，除了瀑布需要预先做好一切准备。由于用例既可以在瀑布(传统用例)中使用，也可以在敏捷(用例2.0)中使用，因此在您的上下文中它肯定是一个很好的基础。对于学校的工作，按照用例结构的SRS肯定会给人留下很好的印象。但是，如果您想要一种面向任务的方法，并且所有的需求还不明确，我建议您使用用例2.0或用户故事映射，并避免瀑布。