软件工程 |经典瀑布模型

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

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

可行性研究：此阶段的主要目标是确定开发该软件在财务和技术上是否可行。
可行性研究包括了解问题，然后确定解决问题的各种可能策略。根据它们的优缺点分析这些不同的已识别解决方案，选择最佳解决方案，并根据此解决方案策略执行所有其他阶段。
需求分析和规范：需求分析和规范阶段的目的是了解客户的确切需求并正确记录它们。这个阶段包括两个不同的活动。
- 需求收集和分析：首先从客户那里收集有关软件的所有需求，然后对收集到的需求进行分析。分析部分的目标是消除不完整性（不完整的需求是实际需求的某些部分被省略的需求）和不一致（不一致的需求是需求的某些部分与其他部分相矛盾的需求）。
- 需求规范：这些分析的需求记录在软件需求规范 (SRS) 文档中。 SRS 文档充当开发团队和客户之间的合同。客户和开发商之间的任何未来争议都可以通过检查 SRS 文件来解决。
设计：此阶段的目标是将在 SRS 中获得的需求转换为可以用编程语言编码的格式。它包括高级和详细的设计以及整体软件架构。软件设计文档用于记录所有这些工作 (SDD)
编码和单元测试：在编码阶段，使用任何合适的编程语言将软件设计翻译成源代码。因此，每个设计的模块都被编码。单元测试阶段的目的是检查每个模块是否正常工作。
集成和系统测试：不同模块的集成是在它们被编码和单元测试后不久进行的。各种模块的集成是通过多个步骤逐步进行的。在每个集成步骤中，将先前计划的模块添加到部分集成的系统中，并对生成的系统进行测试。最后，在所有模块都成功集成和测试后，得到完整的工作系统，并在此进行系统测试。
系统测试由三种不同类型的测试活动组成，如下所述：
- Alpha 测试： Alpha 测试是由开发团队执行的系统测试。
- Beta 测试： Beta 测试是由一群友好的客户执行的系统测试。
- 验收测试：软件交付后，客户进行验收测试，以确定是接受交付的软件还是拒绝交付的软件。
维护：维护是软件生命周期中最重要的阶段。用于维护的工作量是开发完整软件所花费的总工作量的 60%。保养基本上分为三种：
- 纠正性维护：执行此类维护是为了纠正在产品开发阶段未发现的错误。
- 完善的维护：这种类型的维护是为了根据客户的要求增强系统的功能。
- 自适应维护：移植软件以在新环境中工作（例如在新计算机平台或新操作系统上工作）通常需要自适应维护。

经典瀑布模型的优点

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

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

经典瀑布模型的缺点

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

无反馈路径：在经典的瀑布模型中，软件从一个阶段到另一个阶段的演变就像一个瀑布。它假定开发人员在任何阶段都没有犯过错误。因此，它不包含任何纠错机制。
难以适应变更请求：该模型假设所有客户需求在项目开始时都可以完全正确地定义，但实际上客户的需求会随着时间而不断变化。在需求规范阶段完成后，很难适应任何变更请求。
阶段不重叠：该模型建议只有在前一个阶段完成后才能开始新阶段。但在实际项目中，这是无法维持的。为了提高效率和降低成本，阶段可能会重叠。