瀑布模型_渐增模型演化迭代_原型模型_螺旋模型具体区别
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
选择一个良好的开发范型对于一个软件产品(项目)的开发至关重要,但是软件管理没有银弹,如何针对项目具体情况选择合适的范型是项目成功的第一步。
分为5大类:
瀑布:
迭代:演化;增量;喷泉。
螺旋:瀑布+演化+风险;其实严格的讲也是一种迭代;
转换:基于形式化规格说明语言及程序变换的软件开发模型,它采用形式化的软件开发方法对形式化的软件规格说明进行一系列自动或半自动的程序变换,最后映射为计算机系统能够接受的程序系统。变换模型的优点是解决了代码结构经多次修改而变坏的问题,减少了许多中间步骤(如设计、编码和测试等)。但是变换模型仍有较大局限,以形式化开发方法为基础的变换模型需要严格的数学理论和一整套开发环境的支持,目前形式化开发方法在理论、实践和人员培训方面距工程应用尚有一段距离。
第四代:自动生成代码;
目前软件组织常采用的几种范型:瀑布;演化;增量;喷泉;螺旋;5种
适用场景
特点
缺点
瀑布Waterfall
需求能够被很好的定义和理解;
阶段性明确;
基线(或里程碑)管理;
是其他范型的基础;
项目结束前可能出现大量的集成和测试工作;项目结束前用户都不能看到系统;
演化evolution
需求不明;
用户愿意更多的参与;
瀑布模型的增量演化;
与瀑布相比,需要更有力的管理;
需要用户更多的参与
增量increment
需求明确且可分段;
适用于开发公司产品;
与瀑布相比可以很快的交付一个小的版本;
可以增量投资;
早期对于整个产品的规划要求很高,如何后期发生变更就很麻烦。管理成本高;
需求是唯一的风险源;
喷泉
适用于面向对象;
以对象驱动;
迭代和无缝;
各阶段是相互重叠和多次反复
控制不好容易无序;
螺旋spiral
不能确定需求;
项目风险很大;
每一个周期都是一个瀑布;
=瀑布+演化+风险;
支持动态的需求变化;
项目组人员要求有较高的风险评估经验;
成本高;
凡是软件项目十之八九都会遇到工期紧的问题,我们经常会采用一种快速跟进(fast tracking)的方法,就是在瀑布范型中的几个相邻的阶段彼此重叠,缩短开发周期,具体操作可以考虑采用网络图和关键路径法合理安排资源和时序。
软件开发的几种驱动模式:
需求驱动:以用户为中心;
测试驱动:以质量为中心;
风险驱动: 以风险为中心;
瀑布模型、渐增模型/演化/迭代、原型模型、螺旋模型具体区别
瀑布模型
在瀑布模型中,软件开发的各项活动严格按照线性方式进行,当前活动接受上一项活动的工作结果,实施完成所需的工作内容。当前活动的工作结果需要进行验证,如果验证通过,则该结果作为下一项活动的输入,继续进行下一项活动,否则返回修改。
瀑布模型强调文档的作用,并要求每个阶段都要仔细验证。但是,这种模型的线性过程太理想化,已不再适合现代的软件开发模式,几乎被业界抛弃,其主要问题在于:
(1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量;
(2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发的风险;
(3)早期的错误可能要等到开发后期的测试阶段才能发现,进而带来严重的后果。
快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。与建造大厦相同,软件也是一步一步建造起来的。在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成.
增量模型
增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。但是,增量模型也存在以下缺陷:
(1)由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。
(2)在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。
增量和迭代模型理解
RUP的软件开发生命周期模型常挂在嘴边,却无法真正理解增量和迭代二种模型的区别(在昨天的CMMI过程培训会上有了更清楚的认识)。以下引言能生动的说明增量和迭代的概念: 假设现在要开发A,B,C,D四个大的业务功能,每个功能都需要开发两周的时间.
则对于增量方法而言可以将四个功能分为两次增量来完成,第一个增量完成A,B功能,第二次增量完成C,D功能;
而对于迭代开发来将则是分两次迭代来开发,第一次迭代完成A,B,C,D四个基本业务功能但不含复杂的业务逻辑,而第二次迭代再逐渐细化补充完整相关的业务逻辑.在第一个月过去后采用增量开始时候A,B全部开发完成而C,D还一点都没有动;而采用迭代开发的时候A,B,C,D四个的基础功能都已经完成. 很容易理解吧。现实中我们常常是把这二种模型整合一起使用,即增量迭代,所以才会忽略它们单独的存在。