`
thecloud
  • 浏览: 879687 次
文章分类
社区版块
存档分类
最新评论

软件生存期模型

 
阅读更多

软件生存期模型是跨越整个生存期的系统开发、运作和维护所实施的全部过程,活动和任务的结构框架.

一、下面介绍几种常见的软件生存期模型的优缺点,及其适用范围。

1、瀑布模型

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

优点:

(1)为项目提供了按阶段划分的检查点,当前一个阶段完成后,只需要关注后续阶段。

(2)提供了软件开发的基本框架,有利于大型软件开发过程中人员的组织与管理

缺点:

(1)在软件开发的初期阶段就要求做出正确、全面、完整的需求分析对许多应用软件来说是极其困难的。

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

(3)早期的错误可能要等到开发后期才能发现,进而带来严重后果。

适用范围:瀑布模型是以文档作为驱动,适合于软件需求很明确的软件项目即一般适用于功能明确、完整、无重大变化的软件系统的开发,例如:操作系统、数据库管理系统等系统软件的开发,其应用有一定的局限性。

2、快速原型模型

快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。

优点:

(1)快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。

缺点:

(1)所选用的开发技术和工具不一定符合主流的发展;

(2)快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。

(3)使用这个模型的前提是要有一个展示性的产品原型,因此在一定程度上可能会限制开发人员的创新。

适用范围:

原型模型适合于那些不能确切定义需求的软件系统的开发。

3、螺旋模型

螺旋模型,该模型运用快速原型法,以进化的开发方式为中心,在每个项目阶段使用瀑布模型法,可以说它将瀑布模型和快速原型模型结合起来。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段,由这4个阶段进行迭代。软件开发过程每迭代一次,软件开发又前进一个层次。

优点:

(1)强调严格的全过程风险管理。

(2)强调各开发阶段的质量。

(3)强调原型的可扩充性和可修改性,原型的进化贯穿整个软件生存周期。

(4)为项目管理人员及时调整管理决策提供了方便,进而可降低开发风险。

缺点:

(1)很难让用户确信这种演化方法的结果是可以控制的。建设周期长,而软件技术发展比较快,所以经常出现软件开发完毕后,和当前的技术水平有了较大的差距,无法满足当前用户需求。

(2)使用该模型需要有相当丰富的风险评估经验和专门知识,要求开发队伍水平较高。

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


增量模型

增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产品。在使用增量模型时,第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。

优点:

(1)软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险

缺陷:

(1)由于各个构件是逐渐并入已有的软件体系结构中的,所以加入构件必须不破坏已构造好的系统部分,这需要软件具备开放式的体系结构。

(2)在开发过程中,需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型,但也很容易退化为边做边改模型,从而是软件过程的控制失去整体性。

适用范围:

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

二、上述整理中发现,每种模型基本上都和“迭代”“增量”“原型”有着或多或少的联系,下面谈下一下三者的区别与联系。

原型即先建立一个样品系统(不全面的系统),然后供测试评价,再次优化。如果采用螺旋模型,每次迭代都会产生一个原型。

下面看一下迭代和增量的概念。

假设现在要开发A,B,C,D四个大的业务功能,每个功能都需要开发两周的时间.则对于增量方法而言可以将四个功能分为两次增量来完成,第一个增量完成A,B功能,第二次增量完成C,D功能;而对于迭代开发来将则是分两次迭代来开发,第一次迭代完成A,B,C,D四个基本业务功能但不含复杂的业务逻辑,而第二个功能再逐渐细化补充完整相关的业务逻辑.在第一个月过去后采用增量开始时候A,B全部开发完成而C,D还一点都没有动;而采用迭代开发的时候A,B,C,D四个的基础功能都已经完成.

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

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

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

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

  1.在前期需求明确的情况下尽量采用瀑布模型或改进型的瀑布模型.

  2.在用户无信息系统使用经验,需求分析人员技能不足情况下一定要借助原型.

  3.在不确定性因素很多,很多东西前面无法计划情况下尽量采用增量迭代和螺旋模型

  4.在需求不稳定情况下尽量采用增量迭代模型

  5.在资金和成本无法一次到位情况下可以采用增量模型,软件产品分多个版本进行发布

  6.对于完全多个独立功能开发可以在需求阶段就分功能并行,但每个功能内都应该遵循瀑布模型

  7.对于全新系统的开发必须在总体设计完成后再开始增量或并行.

  8.对于编码人员经验较少情况下建议不要采用敏捷或迭代等生命周期模型.

  9.增量,迭代和原型可以综合使用,但每一次增量或迭代都必须有明确的交付准则.

前面介绍的软件生存期模型是针对软件开发的某些问题和要求设计的,他们都有各自的优点和缺陷,在软件工程实践中,经常把几种模型组合在一起配套使用,形成组合模型。每个软件开发组织应该选择适合于该组织的软件开发模型,并且应该随着当前正在开发的特定产品特性而变化,以减小所选模型的缺点,充分利用其优点。

初步理解与归纳,如有不足,请指出!

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics