经典的瀑布模型是基本的软件开发生命周期模型。它非常简单，但理想主义。以前这种模型非常受欢迎，但现在它没有被使用。但这非常重要，因为所有其他软件开发生命周期模型都基于经典的瀑布模型。
经典的瀑布模型将生命周期划分为一组阶段。此模型认为在完成上一阶段后可以启动一个阶段。也就是说，一个阶段的输出将是下一阶段的输入。因此，可以将开发过程视为瀑布中的顺序流。在这里，这些阶段彼此不重叠。经典瀑布模型的不同顺序阶段如下图所示：

阶段介绍

现在，让我们简要了解一下每一个阶段：

1. 可行性研究：此阶段的主要目标是确定开发软件在财务和技术上是否可行。
   可行性研究涉及了解问题，然后确定解决问题的各种可能策略。根据这些不同确定的解决方案的优缺点进行分析，选择最佳解决方案，并按照此解决方案策略执行所有其他阶段。

2. 需求分析和规范：需求分析和规范阶段的目的是了解客户的确切需求并正确记录它们。此阶段由两个不同的活动组成。

   • 需求收集和分析： 首先，从客户那里收集有关软件的所有要求，然后分析收集到的需求。分析部分的目标是消除不完整性（不完整的需求是省略了实际需求的某些部分）和不一致（不一致的要求是需求的某些部分与某些其他部分相矛盾的需求）。
   • 要求规范： 这些分析的需求记录在软件需求规范 （SRS） 文档中。SRS 文档充当开发团队和客户之间的合同。客户和开发商之间的任何未来争议都可以通过检查SRS文档来解决。

3. 设计：此阶段的目标是将 SRS 中获取的需求转换为可以用编程语言编码的格式。它包括高级和详细的设计以及整体软件架构。软件设计文档用于记录所有这些工作 （SDD）

4. 编码和单元测试：在编码阶段，使用任何合适的编程语言将软件设计转换为源代码。因此，每个设计的模块都是编码的。单元测试阶段的目的是检查每个模块是否正常工作。

5. 集成和系统测试：不同模块的集成在编码和单元测试后不久进行。各种模块的集成通过多个步骤逐步进行。在每个集成步骤中，将先前计划的模块添加到部分集成的系统中，并对生成的系统进行测试。最后，在所有模块都成功集成和测试后，获得完整的工作系统并对其进行系统测试。

   系统测试由三种不同的测试活动组成，如下所述：

   • Alpha 测试： Alpha 测试是由开发团队执行的系统测试。
   • Beta测试： Beta测试是由一组友好的客户执行的系统测试。
   • 验收测试： 软件交付后，客户执行验收测试，以确定是接受还是拒绝交付的软件。

6. 维护： 维护是软件生命周期中最重要的阶段。用于维护的精力占开发完整软件所花费总工作量的60%。基本上有三种类型的维护：

   • 纠正性维护： 执行这种类型的维护是为了纠正在产品开发阶段未发现的错误。
   • 完善性维护： 这种类型的维护是根据客户的要求进行以增强系统的功能。
   • 适应性维护： 通常需要自适应维护才能将软件移植到新环境中，例如在新的计算机平台或新操作系统上工作。

经典瀑布模型的优点

经典的瀑布模型是软件开发的理想主义模型。它非常简单，因此可以将其视为其他软件开发生命周期模型的基础。以下是此SDLC模型的一些主要优点：

• 这个模型非常简单，易于理解。
• 此模型中的阶段一次处理一个阶段。
• 模型中的每个阶段都有明确的定义。
• 该模型具有非常清晰且易于理解的里程碑。
• 过程，行动和结果都有很好的记录。
• 强化好习惯：先定义先设计，
  设计后代码。
• 此模型适用于较小的项目和需求得到良好
  理解的项目。

经典瀑布模型的缺点

经典的瀑布模型存在各种缺点，基本上，我们不能在实际项目中使用它，但是我们使用其他基于经典瀑布模型的软件开发生命周期模型。以下是此模型的一些主要缺点：

• 无反馈路径： 在经典的瀑布模型中，软件从一个阶段到另一个阶段的演变就像一个瀑布。它假设开发人员在任何阶段都不会犯任何错误。因此，它不包含任何纠错机制。

• 难以适应变更请求： 此模型假设所有客户需求都可以在项目开始时完全正确地定义，但实际上客户的需求会随着时间的推移而不断变化。在需求规范阶段完成后，很难适应任何更改请求。

• 阶段无重叠： 此模型建议新阶段只能在前一阶段完成后启动。但在实际项目中，这是无法维持的。为了提高效率并降低成本，各个阶段可能会重叠。