软件开发模型

1、 瀑布模型

1970年温斯顿·罗伊斯提出了著名的“瀑布模型”，这是直到20世纪80年代早期唯一被广泛使用的软件开发模型

瀑布模型将分为六个基本活动，包括规划、需求分析、编程、软件测试和操作与维护，并规定了它们自上而下和互连的固定顺序，就像瀑布流水一样，一步一步地下降

瀑布模型是最早出现的，在软件工程中起着重要作用。它为软件开发提供了一个基本框架。流程是从上一个活动中接收此活动的工作对象作为输入，使用此输入实现此活动应完成的内容，给出此活动的结果，并将其作为输出传输到下一个活动

本质上，它是一种软件开发架构。开发过程依次经过一系列阶段。从系统需求分析到产品发布和维护，每个阶段都会产生循环反馈。因此，如果没有覆盖任何信息或发现问题，最好“返回”到前一阶段并进行适当修改。开发过程从一个阶段“流动”到下一个阶段，这就是瀑布开发名称的由来

瀑布模型对于频繁变化的项目来说毫无价值

1.顺序和相关阶段

这个阶段有两个含义

只有在上一阶段的工作完成后，才能开始下一阶段工作

前一阶段的输出文档是下一阶段的输入文档，因此只有前一阶段输出文档正确，下一阶段工作才能获得正确的结果

2.推迟实施的观点

对于大型软件项目，编码开始得越早，最终开发所需的时间就越长。由于前一阶段的工作还没有完成或做得不好，早期考虑项目实施往往会导致大量返工，有时甚至是无法修复的问题

瀑布模型在编码之前设置了系统分析和系统设计的各个阶段，以及分析和设计阶段的基本任务规定。在这两个阶段，主要考虑目标系统的逻辑模型，而不涉及软件的物理实现

明确区分逻辑设计和物理设计，并尽可能延迟程序的物理实施，是一个重要的指导思想

3.质量保证视角

为了确保开发的软件的质量，在瀑布模型的每个阶段都应该遵循两个重要的实践

指定的文件必须在每个阶段完成。如果未移交合格文件，则无法完成此阶段的任务

完成的文件应在每个阶段结束前进行审查，以便尽快发现问题并纠正错误

传统的瀑布模型过于理想化，实际的瀑布模型有一个“反馈回路”。如图所示（图中实线箭头表示开发过程，虚线箭头表示维护过程），当后期发现前一阶段的错误时，需要沿着图左侧的反馈线返回前一阶段，纠正前一阶段中的产品，然后回来继续完成后期的任务

瀑布模型是一个文档驱动的模型。遵守此约束可以使软件维护更容易，从而显著减少软件预算

优点：

按阶段提供检查点

当前阶段完成后，您只需关注后续阶段

瀑布模型可以应用于

缺点：

不适用于要求模糊或频繁变化的系统

由于开销逐渐增加，它不希望在早期阶段获得反馈

在系统完成之前，它无法预测引入组织的新系统的影响

用户可能需要等待很长时间才能获得可用的系统，这可能会影响并打击用户的信任级别

最终产品通常反映用户的初始需求，而不是最终需求

对于一个项目，是否使用该模型主要取决于是否了解客户的需求以及这些需求在项目过程中的变化程度；对于频繁变化的项目，瀑布模型毫无价值。您可以考虑其他项目管理架构，如螺旋模型

瀑布模型强调文档的作用，需要在每个阶段进行仔细的验证。然而，该模型的线性过程过于理想化，不再适合mod