最新消息:

软件开发生命周期模型 瀑布模型、原型模型、螺旋模型、喷泉模型等

项目管理 鲁, 文坤 来源:http://blog.csdn.net/ 2991浏览 0评论

瀑布模型/改进的瀑布模型

虽然瀑布模型仍然存在很多的问题有待解决,但瀑布模型仍然是最基本的和最效的一种可供选择的软件开发生命周期模型.瀑布模型要求软件开发严格按照需求->分析->设计->编码->测试的阶段进行,每一个阶段都可以定义明确的产出物和验证准则.瀑布模型在每一个阶段完成后都可以组织相关的评审和验证,只有在评审通过后才能够进入到下一个阶段.

由于需要对每一个阶段进行验证,瀑布模型要求每一个阶段都有明确的文档产出,对于严格的瀑布模型每一个阶段都不应该重叠,而应该是在评审通过,相关的产出物都已经基线后才能够进入到下一个阶段.
1474350500-6981-20070131
瀑布模型的优点仍然是可以保证整个软件产品较高的质量,保证缺陷能够提前的被发现和解决.采用瀑布模型可以保证系统在整体上的充分把握,使系统具备良好的扩展性和可维护性.但对于前期需求不明确,而又很难短时间明确清楚的项目则很难很好的利用瀑布模型.另外对于中小型的项目,需求设计和开发人员往往在项目开始后就会全部投入到项目中,而不是分阶段投入,因此采用瀑布模型会导致项目人力资源过多的闲置的情况,这也是必须要考虑的问题.

很多人往往会以进度约束而不选择瀑布模型,这往往是一个错误的观点.导致这种情况的一个关键因素往往是概念需求阶段人力不足.因此在概念需求阶段人力能够得到充分保证的情况下,瀑布模型和迭代模型在开发周期上并不会存在太大的差别.反而是很多项目对于迭代或敏捷模型用不好,为了赶进度在前期需求不明确,没有经过一个总体的架构设计情况下就开始编码,后期出现大量的返工而严重影响进度.

架构设计是软件开发中一个重要的关注点.因此在RUP中也提及到软件开发要以架构为核心.因此在架构设计完成后系统会被分为相关的子系统和功能模块.每个功能模块间的接口都可以定义清楚.在这种情况下,当模块B的详细设计做完成后往往就没有必要等到其它模块的详细设计都要完全作完才开始编码,因此在架构设计完成后可以将系统分为多个模块并行开发,每个模块仍然遵循先设计和编码测试的瀑布模型思路.这是瀑布模型的一种最重要的改进思路,也可以说这是一种增量开发的模型.

1474350500-9832-20070131

当一个新系统的开发存在多个完全不相关的独立需求的功能开发的时候,这个时候也可以选择将整个开发过程按独立的需求来分为多个小瀑布进行操作.这种方式的最大问题就是没有一个完全总体的设计,架构设计人员无法在洞悉了所有需求后从系统的可扩展性,复用等方面总体规划.

在项目管理中有一种压缩进度的方法叫赶工,因此瀑布模型的另外改进处就在适当的重叠各个阶段过程,达到资源的有效利用.比如我们通过讨论,会议确定的实现方式就可以开始执导下一个阶段的工作而不一定完全等到相关的交付物文档化出来.

螺旋模型

首先螺旋模型是遵从瀑布模型的.即需求->架构->设计->开发->测试的路线.螺旋模型最大的价值在于整个开发过程是迭代和风险驱动的.通过将瀑布模型的多个阶段转化到多个迭代过程中,以减少项目的风险.1474350500-7130-20070131

螺旋模型的每一次迭代都包含了以下六个步骤
1.决定目标,替代方案和约束
2.识别和解决项目的风险
3.评估技术方案和替代解决方案
4.开发本次迭代的交付物和验证迭代产出的正确性.
5.计划下一次迭代
6.提交下一次迭代的步骤和方案.

螺旋模型实现了随着项目成本投入不断增加,风险逐渐减小.以帮我我们加强项目的管理和跟踪,在每次迭代结束后都需要对产出物进行评估和验证,当发现无法继续进行下去时可以及早的终止项目.

螺旋模型复杂的地方在于尽责,专心和知识渊博的管理.因为对于每一次迭代我们要制定出清晰的目标,分析出相关的关键风险和计划中可以验证和测试的交付物并不是一件容易的事情.

螺旋模型的每一次迭代只包含了瀑布模型的某一个或两个阶段.如第二次迭代重点是需求,第三次迭代是总体设计和后续设计开发计划等.因此这是和RUP提倡的迭代模型是有区别的,RUP的每一次迭代都会包含需求,设计,开发和测试等各个阶段的活动.RUP迭代的目的在于逐步求精而不是仅仅完成瀑布模型某一阶段的工作.

增量和迭代模型

增量迭代是RUP统一过程常采用的软件开发生命周期模型.增量和迭代有区别但两者又经常一起使用.所以这里要先解释下增量和迭代的概念.假设现在要开发A,B,C,D四个大的业务功能,每个功能都需要开发两周的时间.则对于增量方法而言可以将四个功能分为两次增量来完成,第一个增量完成A,B功能,第二次增量完成C,D功能;而对于迭代开发来将则是分两次迭代来开发,第一次迭代完成A,B,C,D四个基本业务功能但不含复杂的业务逻辑,而第二个功能再逐渐细化补充完整相关的业务逻辑.在第一个月过去后采用增量开始时候A,B全部开发完成而C,D还一点都没有动;而采用迭代开发的时候A,B,C,D四个的基础功能都已经完成.

RUP强调的每次迭代都包含了需求,设计和开发,测试等各个过程,而且每次迭代完成后都是一个可以交付的原型.迭代不是并行,在每次迭代过程中仍然要遵循需求->设计->开发的瀑布过程.迭代周期的长度跟项目的周期和规模有很大的关系.小型项目可以一周一次迭代,而对于大型项目则可以2-4周一次迭代.如果项目没有一个很好的架构师,很难规划出每次迭代的内容和要到达的目标,验证相关的交付和产出.因此迭代模型虽然能够很好的满足与用户的交付,需求的变化,但确是一个很难真正用好的模型.
1474350500-3440-20070131

就对风险的消除上,增量和迭代模型都能够很好的控制前期的风险并解决.但迭代模型在这方面更有优势.迭代模型更多的可以从总体方面去系统的思考问题,从最早就可以给出相对完善的框架或原型,后期的每次迭代都是针对上次迭代的逐步精化.

业界比较标准的增量模型往往要求在软件需求规格说明书全部出来后后续的设计开发再进行增量.同时每个增量也可以是独立发布的小版本.由于系统的总体设计往往对一个系统的架构和可扩展性有重大的影响,因此我们推荐的增量最好是在架构设计完成后再开始进行增量,这样可以更好的保证系统的健壮性和可扩展性.

原型法

原型一般都不是单独采用的一种生命周期模型,往往会结合瀑布和增量迭代等方法一起使用.对于螺旋模型就可以理解为瀑布+迭代+原型+风险的一种生命周期模型.对于迭代开发来讲,每一个迭代周期的产出都可以看做是下个阶段要精化的原型.而对于瀑布模型开发来讲,我们在需求阶段也可以进行界面和操作建模,形成DEMO后和用户做进一部的需求沟通和确认.

当你的用户没有信息系统的使用经验,你的系统分析员也没有过多的需求分析和挖掘经验的时候,需求分析和调研过程则更需要是一个启发式的过程.而原型则是这种很好的启发式方法,可以快速的挖掘用户需求并达成需求理解上的一致.否则即使双方都签字认可的需求往往仍然不是客户真正想要的东西.

原型可以分为抛弃型的和不抛弃型的.如果原型仅仅是需求阶段方面和用户沟通画的DEMO,则这种原型一般都建议抛弃掉.而对于迭代开发来将,每次迭代的产出都是可以独立运行和包含基础功能的系统,是后续细化的基础,这类原型一般都不建议抛弃,后期的设计开发也要基于该原型逐渐的进行完善.

快速和敏捷开发

我们一般将快速和敏捷开发做为方法论,而很少将其做为一种软件开发生命周期模型.敏捷的目的是减少繁重和不必要的工件的输出,提高效率.而不是要我们去挑阶段或过程,不是分析设计都还没有做就去做开发.因此对于瀑布,增量迭代或原型我们都可以借鉴敏捷方法论中的一些好的实践,这些实践都是对传统的生命周期模型很好的补充.对于敏捷方法论在此不再做过多的叙述.

关于选择生命周期模型的最后的总结

1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.
2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型.
3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型
4.在需求不稳定情况下尽量采用增量迭代模型
5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布
6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型
7.对于全新系统的开发必须在总体设计完成后再开始增量或并行.
8.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型.
9.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付和出口准则。

原创文章,转载请注明: 转载自职道

本文链接地址: 软件开发生命周期模型 瀑布模型、原型模型、螺旋模型、喷泉模型等

文章的脚注信息由WordPress的wp-posturl插件自动生成

转载请注明:职道 » 软件开发生命周期模型 瀑布模型、原型模型、螺旋模型、喷泉模型等

您必须 登录 才能发表评论!

网友最新评论 (1)

  1. 总结一下经常可以见到的系统开发周期模型。 在过去的几年里,可以很奇葩的碰到类似于“创业项目库”这种需求非常明确,工作量十分可控,对质量要求比较低,业务建模比较easy,功能构成比较少的“面子项目”。类似于这种项目,采用传统意义上的瀑布模型就非常合适了,如果范围控制和风险控制做的比较好的话,真的如同一个瀑布一样,会“飞流直下三千尺”,直接将项目送到客户的小机上,部署运行,大家欢乐的拿到绩效奖金,回家happy去了。 但是仅仅注重“面子”的项目很难碰到几次,另一方面,即便是“面子型”的项目,也应当极其重视质量环节。项目管理的几个要素:质量,成本,时间,范围。质量是项目最重要的一环,如果丧失了质量,可以说项目产品就变成了无根之树,空中楼阁。所以,加强质量的把控是非常重要的,也需要对每一个阶段进行质量方面的控制,因此,V模型就是这样一种将开发过程与验证过程想对应的一种对称型的结构。 在项目实践中,用户的需求总是随着项目进展而更加明确,控制用户的需求变得非常的重要。为了让用户能在项目的起始阶段就深入的对自己的需求有一个明确的理解,原型就变得非常的重要,我们经常在开发中看到的LOW-FI的页面原型、其他类似项目的DEMO就算这种类型,用户对将来的产品有了直观的了解。建立在这种基础上的分析开发,会减少很多后面流程中可能出现的风险。在瀑布模型以及V模型当中,在需求分析阶段采用原型化,是目前非常有效甚至是必须要采用的手段。 现在的软件项目越来越大,同项目可能由相互联系的若干个子系统构成的,这样仅凭开发一个模型或者多个模型是满足不了项目对于多方面的要求,于是就衍生出了螺旋模型,螺旋模型适合于大型的软件的原因是,它更加注重风险的控制,强调风险的识别、风险的分析、以及风险的消除。 工作的后几年里,经常会按照Sprint(冲刺短跑)为周期的进行开发。这种敏捷的方式,是属于迭代式开发的一种实现。所谓迭代式模型就是在项目的每一个小的阶段中,都会执行一个传统的、完整的串行过程,执行一次就是一次迭代,每次迭代都可能会包含需求分析、设计、编码、测试等其中的全部或者部分活动。 这样就对软件的四种开发模型有了简单的了解:瀑布模型,V模型,原型化模型、螺旋模型、迭代模型。 下面对几个开发模型,结合理论逐一分析。 1.迭代模型 迭代模型,摒弃了传统的需求分析,设计,编码,测试的流程,而是将整个生命周期变成若干个冲刺(Sprint)阶段,而每一个阶段都是由以上若干或者全部传统的流程组成,在每一个阶段中,都会包含下面四个阶段:初始阶段,细化阶段,构建阶段,交付阶段。在初始阶段中,确认本次冲刺的范围,边界,系统选择的架构,计划,以及所需要的资源等信息。在细化阶段中,对问题进行建域,创建开发案例,创建模板以及准备工具等。在构建阶段的主要任务就是完成构建的开发并且进行测试,将完成的构建集成为产品,并且测试所有的功能(CI)。在交付阶段,主要是完成本次冲刺,将软件产品交付给相关的干系人。 2.螺旋模型 螺旋模型,尤其重视风险分析阶段,特别适用于庞大并且复杂,非常高风险的项目。通常螺旋模型由四个阶段组成:制定计划、风险分析、实施工程和客户评估。螺旋模型中,发布的第一个模型甚至可能是没有任何产出的,可能仅仅是纸上谈兵的一个目标,但是随着一次次的交付,每一个版本都会朝着固定的目标迈进,最终得到一个更加完善的版本。 3.原型化模型 原型化模型第一步就是创建一个快速原型,能够满足项目干系人与未来的用户可以与原型进行交互,再通过与相关干系人进行充分的讨论和分析,最终弄清楚当前系统的需求,进行了充分的了解之后,在原型的基础上开发出用户满意的产品。在实际的项目过程中,借助于组织过程资产以及快速模型软件,一般在需求分析的时候,就可以建立一些简单的原型,例如在第一家YH公司中,因为是“行业软件提供商”,所以拥有各个地域的行业解决软件方案,惯用的伎俩就是将其他地市的项目拿到本次项目实施地,作为原型化模型。原型化模型是极具意义的项目实践。 4.V模型 V模型从整体上看起来,就是一个V字型的结构,由左右两边组成。左边的下划线分别代表了需求分析、概要设计、详细设计、编码。右边的上划线代表了单元测试、集成测试、系统测试与验收测试。看起来V模型就是一个对称的结构,它的重要意义在于,非常明确的表明了测试过程中存在的不同的级别,并且非常清晰的描述了这些测试阶段和开发阶段的对应关系。 5.瀑布模型 瀑布模型是一个特别经典,甚至有点老套的周期模型,一般情况下将其分为计划、需求分析、概要设计、详细设计、编码以及单元测试、测试、运行维护等几个阶段。瀑布模型的周期是环环相扣的。每个周期中交互点都是一个里程碑,上一个周期的结束需要输出本次活动的工作结果,本次的活动的工作结果将会作为下一个周期的输入。这样,当某一个阶段出现了不可控的问题的时候,就会导致返工,返回到上一个阶段,甚至会延迟下一个阶段。
    raiseye2年前 (2016-09-18)