经典瀑布模型是基本的软件开发生命周期模型。这很简单但很理想。早些时候这个型号非常受欢迎，但现在它没有被使用。但这非常重要，因为所有其他软件开发生命周期模型都基于经典的瀑布模型。

经典瀑布模型将生命周期划分为一组阶段。该模型认为在完成前一阶段后可以启动一个阶段。也就是说，一个阶段的输出将是下一阶段的输入。因此，开发过程可以被视为瀑布中的顺序流。这里的相位彼此不重叠。经典瀑布模型的不同连续阶段如下图所示：

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

可行性研究：此阶段的主要目标是确定开发软件在财务和技术上是否可行。

可行性研究涉及了解问题，然后确定解决问题的各种可能策略。基于它们的优点和缺点分析这些不同的已识别解决方案，选择最佳解决方案，并根据此解决方案策略执行所有其他阶段。

需求分析和规范：需求分析和规范阶段的目的是了解客户的确切需求并正确记录。这一阶段包括两个不同的活动。

需求收集和分析：首先，从客户收集有关软件的所有要求，然后分析收集的需求。分析部分的目标是消除不完整性（不完整的要求是实际要求的某些部分被省略的要求）和不一致性（不一致的要求是要求的某些部分与其他部分相矛盾的要求）。

要求规范：这些分析的要求记录在软件需求规范（SRS）文档中。SRS文档是开发团队和客户之间的合同。客户和开发人员之间的任何未来争议都可以通过检查SRS文档来解决。

设计：设计阶段的目标是将SRS文档中指定的要求转换为适合在某种编程语言中实现的结构。

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

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

系统测试包括三种不同类型的测试活动，如下所述：

α测试： α测试是由开发团队执行的系统测试。

β测试： β测试是由一组友好的客户进行的系统测试。

验收测试：软件交付后，客户执行验收测试以确定是接受交付的软件还是拒绝软件。

维护：维护是软件生命周期中最重要的阶段。花在维护上的努力是开发完整软件所花费的总费用的60％。基本上有三种类型的维护：

纠正性维护：执行此类维护以纠正在产品开发阶段未发现的错误。

完善维护：执行此类维护是为了根据客户的要求增强系统的功能。

自适应维护：通常需要自适应维护来移植软件以在新环境中工作，例如在新计算机平台上工作或使用新操作系统。

经典瀑布模型的优势

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

这个模型非常简单，易于理解。

该模型中的阶段一次处理一个。

模型中的每个阶段都有明确的定义。

这种模式具有非常清晰且不受欢迎的里程碑。

流程，行动和结果都有很好的记录。

增强良好习惯：设计前定义，

代码前设计。

此模型适用于需要很好

理解需求的小型项目和项目。

古典瀑布模型的缺陷

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

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

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

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