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