瀑布模型
瀑布模型
它是软件开发中使用的第一种方法和基本模型。这是一个简单的模型，易于使用和理解。执行按顺序发生，这意味着一个阶段的结果等于另一个阶段的输入。这就是为什么它也被称为线性顺序生命周期模型。
为了避免多个阶段的重叠问题，每个阶段都应该在进入下一阶段之前完成。瀑布模型的每个阶段都涉及前一阶段的可交付成果，如需求、转移到设计阶段、设计转移到开发等。当我们有生命关键(医院应用)和机器关键(军事项目)时，我们会广泛使用瀑布模型。
瀑布模型分为各个阶段，如下:
需求收集
可行性研究
设计
编码
测试
安装
维护
让我们一一理解:
需求集合
需求集合是瀑布模型的第一阶段，一个业务分析师将以需求文档的形式收集客户的所有信息或业务需求。并且这个文档应该清晰易懂，所有需求都正确列出。
借助软件需求规范[SRS]、客户需求规范[CRS]和业务需求规范[BRS] ，生成 SRS 文档。并且这个 SRS 文档涵盖了应该开发和设计的全部内容。
功能需求的特征
它应该用简单的语言编写，以便易于理解。
规范应该在适当的流程中。
要求应该是可数的。
可行性研究
可行性研究是基于项目的需求，许多人(人力资源、业务分析师、架构)评估项目是否可以完成。
设计
完成可行性研究后，我们将进入下一阶段，即设计。在此，我们将借助一些基本工具，例如不同软件和硬件的组合、各种编程语言(PHP、Java、.Net 等)、数据库(MySQL、Oracle)来创建产品的架构。然后设计人员为应用程序准备好可以分为两个不同部分的计划:
高级设计
低级设计
高级设计[HLD]:
在此，设计者将只专注于决策树、流程图、决策表等模型、流程图、数据字典，架构师做。
低级设计[LLD]:
在这方面，设计者将专注于诸如用户界面(UI) 之类的组件，开发人员经理负责。
编码
一旦我们完成了设计阶段，我们就准备好开发应用程序。为此，开发人员将根据他们的编程语言知识开始编写代码，它可以是任何语言，例如 Python、C、Java、C#、C++ 等。而后端开发人员将根据所需的操作进行后端编码，而前端开发人员将开发有吸引力的 GUI。
测试
编码编译完成后，交给相关测试工程师。之后，测试工程师将根据客户的要求开始测试应用程序的功能。
在测试应用程序时，他们可能会遇到一些缺陷或错误(不按照客户的需求工作)应用程序，并以适当的理由将这些错误发送给开发人员。开发人员将验证给定的错误是否有效。如果它是正确的，它将由开发人员修复并更改为新的。该测试人员将重新测试并验证错误是否已修复。
安装
应用程序测试完毕后，我们将转到下一个阶段(安装)。在这种情况下，该过程将一直持续到软件稳定或无错误并满足所有客户要求。当应用程序稳定后，它会安装到客户的环境中供客户使用。
客户拿到软件后，会进行一轮测试，让客户满意。如果他们遇到任何错误，他们将通知开发团队为特定应用程序解决这些问题。当所有问题得到解决后，应用程序将被部署供最终用户使用。
维护
成功完成六个阶段后，我们将转到瀑布模型的最后阶段(维护)。在这种情况下，该过程将一直持续到软件结束，最终用户开始使用该应用程序，他们可能会遇到一些需要测试和修复的问题。对产品进行定期保养称为维护，其中包括硬件和软件中发生的变化，以保持操作有效性并提高性能。
示例瀑布模型
之前它用于人力资源管理[HRM]、供应链管理系统、客户关系管理[CRM]和零售链等应用程序. 但现在，瀑布模型被其他模型取代，例如迭代模型和敏捷方法等。
瀑布模型的优缺点
| 优点 |
缺点 |
| 在瀑布模型中，需求应该是明确的。 |
这个模型没有并行的可交付成果，这意味着两个团队可以一起工作。 |
| 它适用于了解需求的小型项目。 |
瀑布模型不提供需求变更和需求审查。 |
| 这个模型很容易理解，也很容易使用。 |
以前，当瀑布被发明时，没有测试的概念，这就是为什么使用开发人员来测试应用程序。 |
| 这将使我们能够有效地安排任务。 |
在两者之间，不允许更改，因为一个阶段依赖于另一个阶段。 |
| 在此模型中，允许更改版本级别。 |
无法向后跟踪。 |
| 在这个模型中，过程和结果都有很好的记录。 |
这是一个耗时的过程。 |
