📜  瀑布模型

📅  最后修改于: 2021-01-10 15:39:26             🧑  作者: Mango

瀑布模型

它是软件开发中使用的第一种方法和基本模型。这是一个易于使用和理解的简单模型。执行是按顺序进行的,这意味着一个阶段的结果等于另一阶段的输入。这就是为什么它也被称为线性顺序生命周期模型。

为了避免多个阶段的重叠问题,每个阶段都应先完成,然后再进入下一个阶段。瀑布模型的每个阶段都涉及上一阶段的可交付成果,例如需求,已转移到设计阶段,设计已移至开发阶段等等。当我们拥有生命关键型(医院应用程序)和机器关键型(军事项目)时,我们将广泛使用瀑布模型。

瀑布模型分为多个阶段,分别为:

  • 需求收集
  • 可行性研究
  • 设计
  • 编码
  • 测验
  • 安装
  • 保养

让我们一一理解它们:

需求收集

需求收集是瀑布模型的第一阶段,业务分析师将以需求文档的形式组合客户的所有信息或业务需求。并且此文档应该清晰易懂,并且正确列出了所有要求。

在软件需求规范[SRS],客户需求规范[CRS]和业务需求规范[BRS]的帮助下,生成了SRS文档。并且此SRS文件涵盖了应开发和设计的整个内容。

功能需求的特征

  • 它应该用一种简单的语言编写,以便易于理解。
  • 规格应正确。
  • 要求应该是可数的。

可行性研究

可行性研究基于项目的需求,其中许多人(人力资源,业务分析师,架构)评估项目是否可以完成。要开发一个好的项目,我们应该遵循基于客户需求的各种特征:

Aspects Description
Legal Can the company handle the project as cyber law and other monitoring agreements?
Technical Check whether the available machine supports the software or not?
Operation feasibility The company should able to generate operation that is given by the clients?
Economic Should the company able to complete the product within given  budget or not?
Schedule The project should be done within the given schedule or not.

设计

一旦完成可行性研究,我们将进入下一步,即设计。在此,我们将借助一些必不可少的工具(例如,不同软件和硬件的组合,各种编程语言(PHP,Java,.Net等),数据库(MySQL,Oracle)的组合)来创建产品的体系结构。然后,设计师为应用程序准备了一个计划,该计划可以分为两个不同部分:

  • 高级设计
  • 低层设计

高级设计[HLD]:

在这种情况下,设计人员将只专注于决策树,流程图,决策表,流程图,数据字典等模型,而架构师则可以这样做。

低层设计[LLD]:

在这种情况下,设计人员将专注于诸如用户界面(UI)之类的组件,然后由开发人员经理来完成。

编码

一旦完成设计阶段,就可以开发应用程序了。为此,开发人员将根据他们的编程语言知识开始编写代码,并且可以是任何语言,例如Python,C,Java,C#,C++等。后端开发人员将根据所需的操作进行后端编码,而前端开发人员将开发有吸引力的GUI。

测验

编码编译后,它将移交给关注的测试工程师。然后,测试工程师将根据客户的要求开始测试应用程序的功能。

在测试应用程序时,他们可能会在应用程序中遇到一些缺陷或错误(无法按照客户的需求工作),并以适当的理由将这些错误发送给开发人员。开发人员将验证给定的错误是否有效。如果正确,它将由开发人员修复并随新版本更改。之后,测试人员将对其进行重新测试,并验证是否已修复该错误。

安装

测试完应用程序后,我们将进入下一阶段(安装)。在此过程中,过程将一直持续到软件稳定或没有错误并满足所有客户要求为止。当应用程序稳定后,它将安装到客户端环境中以供使用。

取得软件后,客户将进行一轮测试,以使他们满意。如果他们遇到任何错误,他们将通知开发团队解决特定应用程序的那些问题。解决所有问题后,将部署该应用程序供最终用户使用。

保养

成功完成六个阶段后,我们将移至瀑布模型的最后一个阶段(维护)。在这种情况下,该过程将一直持续到软件结束时,最终用户才开始使用该应用程序,并且他们可能会遇到一些需要测试和修复的问题。保养产品时,有时需要将其称为维护,其中包括在硬件和软件中发生的变化,以维护操作效率并提高性能。

瀑布模型的例子

早先用于诸如人力资源管理[HRM],供应链管理系统,客户关系管理[CRM]和零售链等应用程序,但是现在,瀑布模型已被其他模型取代,例如迭代模型和敏捷方法论

瀑布模型的优缺点

Pros Cons
In the Waterfall model, the requirement should be clear. This model has no parallel deliverable, which means that two teams can work together.
It is suitable for a smaller project where needs are well understood. The waterfall model doesn’t provide the requirement changes and requirement review.
This model is easy to understand, as well as easy to use. Previously, when the waterfall is invented, there is no concept of testing, that’s why the developer is used to test the application.
It will allow us to arrange the tasks efficiently. In between, changes are not allowed because one phase is dependent on another stage.
In this model, release level changes are allowed. Backward tracking is not possible.
In this model, the procedure and the results are well documented. It is a time-consuming process.