《瀑布模型、渐增模型演化迭代、原型模型、螺旋模型具体区别》由会员分享，可在线阅读，更多相关《瀑布模型、渐增模型演化迭代、原型模型、螺旋模型具体区别（7页珍藏版）》请在金锄头文库上搜索。
1、由安博测试空间技术中心由安博测试空间技术中心 http:/ 5 大类：大类：瀑布：瀑布：迭代：迭代：演化；增量；喷泉。演化；增量；喷泉。螺旋：螺旋：瀑布瀑布+演化演化+风险；其实严格的讲也是一种迭代；风险；其实严格的讲也是一种迭代；转换转换：基于形式化规格说明语言及程序变换的软件开发模型，它采：基于形式化规格说明语言及程序变换的软件开发模型，它采用形式化的软件开发方法对形式化的软件规格说明进行一系列自动用形式化的软件开发方法对形式化的软件规格说明进行一系列自动或半自动的程序变换，最后映射为计算机系统能够接受的程序系统。或半自动的程序变换，最后映射为计算机系统能够接受的程序系统。变换模型的优点是
2、解决了代码结构经多次修改而变坏的问题，减少变换模型的优点是解决了代码结构经多次修改而变坏的问题，减少了许多中间步骤（如设计、编码和测试等）。但是变换模型仍有较了许多中间步骤（如设计、编码和测试等）。但是变换模型仍有较大局限，以形式化开发方法为基大局限，以形式化开发方法为基 础的变换模型需要严格的数学理论础的变换模型需要严格的数学理论和一整套开发环境的支持，目前形式化开发方法在理论、实践和人和一整套开发环境的支持，目前形式化开发方法在理论、实践和人员培训方面距工程应用尚有一段距离。员培训方面距工程应用尚有一段距离。第四代：第四代：自动生成代码；自动生成代码；目前软件组织常采用的几种范型：瀑布；演
3、化；增量；喷泉；螺旋；目前软件组织常采用的几种范型：瀑布；演化；增量；喷泉；螺旋；5 种种适用场景适用场景特点特点缺点缺点瀑布瀑布 Waterfall需求能够被很好的定义和理解；需求能够被很好的定义和理解；阶段性明确；阶段性明确；基线（或里程碑）管理；基线（或里程碑）管理；是其他范型的基础；是其他范型的基础；项目结束前可能出现大量的集成和测试工作；项目结束前可能出现大量的集成和测试工作；项目结束前用户都不能看到系统；项目结束前用户都不能看到系统；演化演化 evolution需求不明；需求不明；用户愿意更多的参与；用户愿意更多的参与；瀑布模型的增量演化；瀑布模型的增量演化；与瀑布相比，需要更有力
4、的管理；与瀑布相比，需要更有力的管理；需要用户更多的参与需要用户更多的参与增量增量 increment需求明确且可分段；需求明确且可分段；适用于开发公司产品；适用于开发公司产品；与瀑布相比可以很快的交付一个小的版本；与瀑布相比可以很快的交付一个小的版本；可以增量投资；可以增量投资；早期对于整个产品的规划要求很高，如何后期发生变更就很麻烦。早期对于整个产品的规划要求很高，如何后期发生变更就很麻烦。管理成本高；管理成本高；需求是唯一的风险源；需求是唯一的风险源；喷泉喷泉适用于面向对象；适用于面向对象；以对象驱动；以对象驱动；迭代和无缝；迭代和无缝；各阶段是相互重叠和多次反复各阶段是相互重叠和多次反
5、复控制不好容易无序；控制不好容易无序；螺旋螺旋 spiral不能确定需求；不能确定需求；项目风险很大；项目风险很大；每一个周期都是一个瀑布；每一个周期都是一个瀑布；=瀑布瀑布+演化演化+风险；风险；支持动态的需求变化；支持动态的需求变化；项目组人员要求有较高的风险评估经验；项目组人员要求有较高的风险评估经验；成本高；成本高；凡是软件项目十之八九都会遇到工期紧的问题，我们经常会采用一凡是软件项目十之八九都会遇到工期紧的问题，我们经常会采用一种快速跟进（种快速跟进（fast tracking）的方法，就是在瀑布范型中的几个）的方法，就是在瀑布范型中的几个相邻的阶段彼此重叠，缩短开发周期，具体操作可
6、以考虑采用网络相邻的阶段彼此重叠，缩短开发周期，具体操作可以考虑采用网络图和关键路径法合理安排资源和时序。图和关键路径法合理安排资源和时序。软件开发的几种驱动模式：软件开发的几种驱动模式：需求驱动：以用户为中心；需求驱动：以用户为中心；测试驱动：以质量为中心；测试驱动：以质量为中心；风险驱动风险驱动: 以风险为中心；以风险为中心；瀑布模型、渐增模型瀑布模型、渐增模型/演化演化/迭代、原型模型、螺旋模型具体区别迭代、原型模型、螺旋模型具体区别瀑布模型瀑布模型在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活 动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行
7、验证，如果验证 通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过 程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于： （1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量； （2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增 加了开发的风险； （3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。原型模型原型模型快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户 或客户对原
8、型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户 的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户 满意的软件产品。 显然，快速原型方法可以克服瀑布模型的缺点，减少由于软件需求 不明确带来的开发风险，具有显著的效果。 与建造大厦相同，软件也是一步一步建造起 来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个 构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型增量模型增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集 的可运行产品。整个产品被分解成若干个构件，开发人员逐
9、个构件地交付产品，这样做的 好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发 风险。但是，增量模型也存在以下缺陷： （1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构 造好的系统部分，这需要软件具备开放式的体系结构。 （2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变 化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软 件过程的控制失去整体性。增量和迭代模型理解增量和迭代模型理解RUP 的软件开发生命周期模型常挂在嘴边，却无法真正理解增量和迭代二种模型的区别 （在昨天的 CMM
10、I 过程培训会上有了更清楚的认识） 。以下引言能生动的说明增量和迭代的 概念: 假设现在要开发 A,B,C,D 四个大的业务功能,每个功能都需要开发两周的时间. 则对于增量方法而言可以将四个功能分为两次增量来完成,第一个增量完成 A,B 功能,第 二次增量完成 C,D 功能; 而对于迭代开发来将则是分两次迭代来开发,第一次迭代完成 A,B,C,D 四个基本业务功 能但不含复杂的业务逻辑,而第二次迭代再逐渐细化补充完整相关的业务逻辑.在第一个月过 去后采用增量开始时候 A,B 全部开发完成而 C,D 还一点都没有动;而采用迭代开发的时候 A,B,C,D 四个的基础功能都已经完成. 很容易理解吧。
11、现实中我们常常是把这二种模型整合 一起使用，即增量迭代增量迭代，所以才会忽略它们单独的存在。 螺旋模型螺旋模型螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动： （1） 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件； （2） 风险分析：分析评估所选方案，考虑如何识别和消除风险； （3） 实施工程：实施软件开发和验证； （4） 客户评估：评价开发工作，提出修正建议，制定下一步计划。 螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量 作为特殊目标融入产品开发之中。但是，螺旋模型也有一定的限制条件，具体如下： （1） 螺旋模型强调风险分析，但
12、要求许多客户接受和相信这种分析，并做出相关反应是 不容易的，因此，这种模型往往适应于内部的大规模软件开发。 （2） 如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺 旋模型只适合于大规模软件项目。 （3） 软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风 险 一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后 从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完 成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该 阶段的结果，并设计下一个阶段。所谓“迭代”式开发，就是把一
13、个传统的梯级进行的大过程，转变为一个多个螺旋方式进 行的小过程的连续进行，每一个螺旋过程，就是一次迭代，在每次的迭代过程中，系统分 析员，设计师，程序员，测试员，用户代表全员参与，同步工作，每次迭代过程在上一次 迭代基础上，增加适当新的开发内容，并交付一个可用可用的新的软件成果，逐步演进到完全 符合用户需求的软件产品为止。这样做，可以将用户需求由开始不明确到最终全明确引起由开始不明确到最终全明确引起 的的“需求变化需求变化”的风险，分布到多个迭代的过程中的风险，分布到多个迭代的过程中，而不是象瀑布式开发中那样集中在第 一个阶段中，就算用户的需求真的发生变化，在迭代的过程中，也可以把这种变化纳入到 下一个迭代过程中来处理，这样就能大大提高软件开发过程的成功率在迭代式开发中，每次迭代只实现当前时段下，对客户价值最高的需求每次迭代只实现当前时段下，对客户价值最高的需求，而有意保留其他 的需求暂不实现，留待后续的迭代逐步实现，也就是说，迭代式开发方式在“求同求同”的过 程中，没有忘记“存异存异” ，也就是主动保留一些价值目标的差异。
