软件开发模型瀑布模型的介绍是什么?
软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。
软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。
软件开发模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目工作的基础。
最早出现的软件开发模型是1970年W·Royce提出的瀑布模型。
该模型给出了固定的顺序,将生存期活动从上一个阶段向下一个阶段逐级过渡,如同流水下泻,最终得到所开发的软件产品,投入使用。
但计算拓广到统计分析、商业事务等领域时,大多数程序采用高级语言(如FORTRAN、COBOL等)编写。
瀑布模式模型也存在着缺乏灵活性、无法通过并发活动澄清本来不够确切的需求等缺点。
典型的开发模型有:①瀑布模型(waterfall model);②渐增模型/演化/迭代(inCRemental model);③原型模型(prototype model);④螺旋模型(SPIral model);⑤喷泉模型(fountAIn model);⑥智能模型(intelligent model) ; 7. 混合模型(hybrid model)1. 边做边改模型(Build-and-Fix Model) 遗憾的是,许多产品都是使用"边做边改"模型来开发的。
在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改.在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。
在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户满意为止。
这是一种类似作坊的开发方式,对编写几百行的小程序来说还不错,但这种方法对任何规模的开发来说都是不能令人满意的,其主要问题在于: (1) 缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改; (2) 忽略需求环节,给软件开发带来很大的风险; (3) 没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难。
2. 瀑布模型(Waterfall Model)1970年WinSTon Royce提出了著名的"瀑布模型",直到80年代早期,它一直是唯一被广泛采用的软件开发模型。
瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。
在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。
当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。
瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。
但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于: (1) 各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量; (2) 由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险; (3) 早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。
我们应该认识到,"线性"是人们最容易掌握并能熟练应用的思想方法。
当人们碰到一个复杂的"非线性"问题时,总是千方百计地将其分解或转化为一系列简单的线性问题,然后逐个解决。
一个软件系统的整体可能是复杂的,而单个子程序总是简单的,可以用线性的方式来实现,否则干活就太累了。
线性是一种简洁,简洁就是美。
当我们领会了线性的精神,就不要再呆板地套用线性模型的外表,而应该用活它。
例如增量模型实质就是分段的线性模型,螺旋模型则是接连的弯曲了的线性模型,在其它模型中也能够找到线性模型的影子。
3. 快速原型模型(RAPId Prototype Model) 快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。
通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。
显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。
快速原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃。
因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求。
4. 增量模型(Incremental Model) 与建造大厦相同,软件也是一步一步建造起来的。
在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。
整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。
但是,增量模型也存在以下缺陷: (1) 由于各个构件是逐渐并入已有的软件体系结构...
软件过程中瀑布模型的缺点?
1.客户很难一次给出所有的需求,但该需求对于模型来说是必需的.2.用户很难根据规范说明书预见最终构建的系统是否能满足他的需求.3.在实现过程中所做的任何更改都将导致混乱,因为这种模型本身是顺序的.4.吸有在最晚的阶段才能看到可运行的版本,如果发生严重的错误,必须将该错误反馈到需求阶段.
软件开发的瀑布模型的优点和缺点
瀑布模型的优点1、瀑布模型有以下优点:1)为项目提供了按阶段划分的检查点。
2)当前一阶段完成后,您只需要去关注后续阶段。
3)可在迭代模型中应用瀑布模型。
缺点1)在项目各个阶段之间极少有反馈。
2)只有在项目生命周期的后期才能看到结果。
3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
瀑布、原型、面向对象三种模式各适合于哪些软件系统的开发
瀑布模型(Waterfall Model)是一个项目开发架构,瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。
1、瀑布模型有以下优点1)为项目提供了按阶段划分的检查点。
2)当前一阶段完成后,您只需要去关注后续阶段。
3)可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。
迭代1解决最大的问题。
每次迭代产生一个可运行的版本,同时增加更多的功能。
每次迭代必须经过质量和集成测试。
2、瀑布模型有以下缺点1)在项目各个阶段之间极少有反馈。
2)只有在项目生命周期的后期才能看到结果。
3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
尽管瀑布模型招致了很多批评,但是它对很多类型的项目而言依然是有效的,如果正确使用,可以节省大量的时间和金钱。
面向对象这个概念很抽象...不过我觉得是3者当中最适合于软件系统的开发。
每个人对于面向对象这个概念的看法都有点不同,开发的系统越多,对于面向对象这个概念就理解的越深刻。
有关于面向对象的解释,你可以参考下这个:http://baike.baidu.com/view/125370.html?wtp=tt原型模型的特点:(1)开发人员和用户在“原型”上达成一致。
这样一来,可以减少设计中的错误和开发中的风险,也减少了对用户培训的时间,而提高了系统的实用、正确性以及用户的满意程度。
(2)缩短了开发周期,加快了工程进度。
(3)降低成本。
原型模型的缺点:当告诉用户,还必须重新生产该产品时,用户是很难接受的。
这往往给工程继续开展带来不利因素。
不宜利用原型系统作为最终产品。
采用原型模型开发系统,用户和开发者必须达成一致:原型被建造仅仅是用户用来定义需求,之后便部分或全部抛起,最终的软件是要充分考虑了质量和可维护性等方面之后才被开发。
软件开发流程的瀑布模型主要包含哪些步骤
瀑布开发模型可以分为六个不同步骤,义如下: 1.需求分析:2.设计:这一步包括了“定义硬件和软件架构、组件、模块、界面和数据等来满足指定的需求(Wikipedia)。
”它包括了硬件和软件架构的定义,确定性能和安全参数,设计数据存储容器和限制,选择集成开发环境(IDE)和编程语言,并指定异常处理、资源管理和界面连接性的策略。
这一阶段还强调了用户接口的设计,包括与浏览和可用性相关的问题,这一步骤的输出结果是一份或多份设计说明书,这些说明书将在下一阶段使用。
3.实现:这一步包含了根据设计说明书来构建产品,通常,这一阶段是由开发团队来执行的,开发团队包括了程序员、界面设计师和其他的专家,他们使用的工具包括编译软件、调试软件、解释软件和媒体编辑软件。
这一阶段将生成一个或多个产品组件,它们是根据每一条编码标准而编写的,并且经过了调试、测试并进行集成以满足系统架构的需求。
对于大型开发团队而言,建议使用版本控制工具来追踪代码树的变化,这样在出现问题的时候可以还原以前的版本。
4.测试:在这一阶段,独立的组件和集成后的组件都将进行系统性验证以确保没有错误并且完全符合第一阶段所制定的需求。
一个独立的质量保证小组将定义“测试实例”来评估产品是完全实现了需求还是只有部分满足。
5.安装:在产品通过测试并且被鉴定为符合需求的产品后,就会进入到安装阶段,这一阶段包括了在客户站点进行系统或产品的安装和使用,这可以通过互联网或者物理媒介进行,通常交付使用的产品都带有正式的版本号,这为今后的产品升级提供了便利。
6.维护:这一阶段发生在安装之后,包括了对整个系统或某个组件进行修改以改变属性或者提升性能,这些修改可能源于客户的需求变化或者系统使用中没有覆盖到的缺陷,通常,在维护阶段对产品的修改都会被记录下来并产生新的发布版本(称作“维护版本”并伴随升级了的版本号)以确保客户可以从升级中获益。
...
软件开发时,什么情况用瀑布模型,什么情况用原型模型?
当开发的软件是已知领域和行业,并且有比较好的积累,有可重用的架构或者模型。
或者软件对安全和性能有极其严格的要求,容不得半点疏漏,比如航空航天软件。
这样用瀑布模型的话能够有效地控制每一环节,所有流程都有文档可循。
而规模不是很大的,商业型的应用软件,更倾向于快速得到可用的软件。
而且软件需要能够适应市场的变化作出相应的调整。
原型模型无疑是更适合的。
...
瀑布模型的定义
瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作,形如瀑布流水,最终得到软件产品。
1970年温斯顿·罗伊斯(Winston Royce)提出了著名的“瀑布模型”,直到80年代早期,它一直是唯一被广泛采用的软件开发模型。
1)为项目提供了按阶段划分的检查点。
2)当前一阶段完成后,您只需要去关注后续阶段。
3)可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。
迭代1解决最大的问题。
每次迭代产生一个可运行的版本,同时增加更多的功能。
每次迭代必须经过质量和集成测试。
4)它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4)瀑布模型的突出缺点是不适应用户需求的变化。