瀑布模型不是用于什么的软件开发(瀑布模型不是用于什么的软件开发的)

软件开发 1978
本篇文章给大家谈谈瀑布模型不是用于什么的软件开发,以及瀑布模型不是用于什么的软件开发的对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。 本文目录一览: 1、瀑布模型不适用于什么的软件开发

本篇文章给大家谈谈瀑布模型不是用于什么的软件开发,以及瀑布模型不是用于什么的软件开发的对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。

本文目录一览:

瀑布模型不适用于什么的软件开发

复杂软件不适合瀑布模型,比如功能需求多、需求不清晰、需求变化大、软件复杂度高、开发周期长这类型的“复杂域”软件项目。

瀑布型方法适用的范围是什么

适用于结构化方法

也就是面向过程的软件开发方法,瀑布模型是一个项目开发架构,开发过程是通过设计一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好 “返回”上一个阶段并进行适当的修改,项目开发进程从一个阶段“流动”到下一个阶段,这也是瀑布模型名称的由来。包括软件工程开发、企业项目开发、产品生产以及市场销售等构造瀑布模型。

那种系统不适合瀑布模型

小型软件系统开发不适合瀑布模型。根据查询相关公开信息显示,根据瀑布模型的特点(连续无反馈)是对于每一个阶段来说,前一个阶段工作的正确无误是至关重要的。因此,瀑布模型不能很好地适应那些需求不易确定和多变的软件项目的开发。由于大项目在软件开发的前期阶段,人们很难详细地了解系统的许多细节,从而在项目进行过程中常会出现需求变化。因此,瀑布模型适用于小系统开发项目,而不适用于大、中型软件系统开发。

瀑布模型

一、瀑布模型

1.1什么是瀑布模型

1970年温斯顿.罗伊斯提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型

瀑布模型将 软件生命周期 划分为制定计划、需求分析、 软件设计 、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落

瀑布模型是最早出现的 软件开发模型 ,在软件工程中占有重要的地位,它提供了软件开发的基本框架。其过程是从上一项活动接收该项活动的工作对象作为输入,利用这一输入实施该项活动应完成的内容给出该项活动的工作成果,并作为输出传给下一项活动

从本质来讲,它是一个软件开发架构,开发过程是通过一系列阶段顺序展开的,从系统需求分析开始直到产品发布和维护,每个阶段都会产生循环反馈,因此,如果有信息未被覆盖或者发现了问题,那么最好 “返回”上一个阶段并进行适当的修改,开发进程从一个阶段“流动”到下一个阶段,这也是瀑布开发名称的由来

对于经常变化的项目而言,瀑布模型毫无价值

1.2特点

1、阶段间具有顺序性和依赖性

该阶段具有两重含义

必须等前一阶段的工作完成后,才能开始后一阶段的工作

前一阶段的输出文档就是后一阶段的输入文档,因此只有前一阶段的输出文档正确,后一阶段的工作才能获得正确的结果

2、推迟实现的观点

对于规模较大的软件项目来说,往往编码开始的越早,最终完成开发所需时间越长。因为前面阶段的工作没做或做的不扎实,过早地考虑进行程序实现,往往导致大量返工,有时甚至发生无法弥补的问题

瀑布模型在编码之前设置了系统分析与系统设计的各个阶段,分析与设计阶段的基本任务规定,在这两个阶段主要考虑目标系统的逻辑模型,不涉及软件的物理实现

清楚的区分逻辑设计与物理设计,尽可能推迟程序的物理实现,是按照瀑布模型开发软件的一条重要的指导思想

3、质量保证的观点

为了保证所开发的软件的质量,在瀑布模型的每一个阶段都应坚持两个重要做法

每个阶段都必须完成规定的文档,没有交出合格的文档就是没有完成该阶段的任务

每个阶段结束前都要对所完成的文档进行评审,以便尽早发现问题,改正错误

传统的瀑布模型过于理想化,实际的瀑布模型是带"反馈环"的。如图所示(图中实线箭头表示开发过程,虚线箭头表示维护过程),当在后面阶段发现前面阶段的错误时,需要沿图中左侧的反馈线返回前面的阶段,修正前面阶段的产品后再回来继续完成后面阶段的任务

瀑布模型是文档驱动的模型,遵守这个约束可使软件维护变得比较容易一些,从而显著降低软件预算

1.3优缺点

优点:

为 项目 提供了按阶段划分的检查点

当前一阶段完成后,您只需要去关注后续阶段

可在 迭代模型 中应用瀑布模型

缺点:

不适合需求模糊或需求经常变动的系统

由于开销的逐步升级问题,它不希望存在早期阶段的反馈

在一个系统完成以前,它无法预测一个新系统引入一个机构的影响

在用户可能需要较长等待时间来获得一个可供使用的系统,也许会给用户的信任程度带来影响和打击

最终产品往往反映用户的初始需求而不是最终需求

1.4客户需求

对项目而言,是否使用这一模型主要取决于是否能理解客户的需求以及在项目的进程中这些需求的变化程度;对于经常变化的项目而言,瀑布模型毫无价值,可以考虑其他的架构来进行项目管理,比如螺旋模型

瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于:

各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量

由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险

早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果

按照瀑布模型的阶段划分, 软件测试 可以分为 单元测试 , 集成测试 , 系统测试

软件开发瀑布模型适用于

软件开发瀑布模型适用于以下场景:

1、需求在规划和设计阶段就已确定,且项目开发周期内需求没有或极少变化,对需求变更进行严格控制,例如航空航天、金融核心系统等。

2、稳定的低风险项目(对目标、环境非常熟悉),规模小实现简单易受控的项目。

3、合同式的合作方式,严格按照说明执行,客户需求明确且不参与软件实现过程。

瀑布模型

1、瀑布模型的优点:有利于大型软件开发过程中人员的组织、管理,有利于软件开发方法和工具的研究,从而提高了大型软件项目开发的质量和效率。

2、瀑布模型的缺点:开发过程一般不能逆转,否则代价太大;很难严格按该模型进行。

3、瀑布模型的使用范围:用户的需求非常清楚全面,且在开发过程中没有或很少变化,对软件的应用领域很熟悉;用户的使用环境非常稳定;开发工作对用户参与的要求很低。

快速原型模型

1、快速原型模型的优点:可以得到比较良好的需求定义,容易适应需求的变化;有利于开发与培训的同步;费用低、开发周期短且对用户更友好。

2、快速原型模型的缺点:客户与开发者对原型理解不同; 准确的原型设计比较困难; 不利于开发人员的创新。

3、快速原型模型的使用范围:对所开发的领域比较熟悉而且有快速的原型开发工具;项目招投标时,可以以原型模型作为软件的开发模型;进行产品移植或升级时,或对已有产品原型进行客户化工作时,原型模型是非常适合的。

增量模型

1、增量模型的优点:优点是人员分配灵活,刚开始不用投入大量人力资源;可先发布部分功能给客户,对客户起到镇静剂的作用。

2、增量模型的缺点:并行开发构件有可能遇到不能集成的风险,软件必须具备开放式的体系结构;变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。

3、增量模型的使用范围:进行已有产品升级或新版本开发,增量模型是非常适合的,完成期限严格要求的产品,可以使用增量模型对所开发的领域比较熟悉而且已有原型系统,增量模型也是非常适合的。

螺旋模型

1、螺旋模型的优点:灵活性,可以在项目的各个阶段进行变更计算变得简单容易;客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。

2、螺旋模型的缺点:需要具有相当丰富的风险评估经验和专门知识,在风险较大的项目开发中,如果未能够及时标识风险,势必造成重大损失;会增加开发成本,延迟提交时间。

3、螺旋模型的使用范围:螺旋模型只适合于大规模的软件项目。

瀑布模型不是用于什么的软件开发的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于瀑布模型不是用于什么的软件开发的、瀑布模型不是用于什么的软件开发的信息别忘了在本站进行查找喔。

扫码二维码