首页  ·  知识 ·  软件项目
软件生命周期模型概述及使用准则
网友   http://blog.csdn.net/tomfshao/archive/2009/07/24/4378299.aspx    编辑:德仔   图片来源:网络
. 概述 在做过程改进的几年中发现软件项目的失败都是由于没有选好作业模式,也就是没有选择出合适的
.  概述

在做过程改进的几年中发现软件项目的失败都是由于没有选好作业模式,也就是没有选择出合适的生命周期模型来执行项目。正确的选择生命周期模型是软件开发成功的第一部。下面是几个常用的生命周期模型的介绍,以及他们的使用准则。

2.  瀑布模型

有时也称为V模型,它是一种线型顺序模型,是项目自始至终按照一定顺序的步骤从需求分析进展到系统测试直到提交用户使用,它提供了一种结构化的、自顶向下的软件开发方法,每阶段主要工作成果从一个阶段传递到下一个阶段,必须经过严格的评审或测试,以判定是否可以开始下一阶段工作,各阶段相互独立、不重叠。瀑布模型是所有软件生命周期模型的基础。

 

图:瀑布模型示意图

3.  原型+瀑布模型

原型模型本身是一个迭代的模型,是为了解决在产品开发的早期阶段存在的不确定性、二义性和不完整性等问题,通过建立原型使开发者进一步确定其应开发的产品,使开发者的想象更具体化,也更易于被客户所理解。原型只是真实系统的一部分或一个模型,完全可能不完成任何有用的事情,通常包括抛弃型和进化型两种,抛弃型指原型建立、分析之后要扔掉,整个系统重新分析和设计;进化型则是对需求的定义较清楚的情形,原型建立之后要保留,作为系逐渐增加的基础,采用进化型一定要重视软件设计的系统性和完整性,并且在质量要求方面没有捷径,因此,对于描述相同的功能,建立进化型原型比建立抛弃型原型所花的时间要多。原型建立确认需求之后采用瀑布模型的方式完成项目开发。

 

 

图:原型+瀑布模型示意图

4.  增量模型

与建造大厦相同,软件也是一步一步建造起来的。在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。

一些大型系统往往需要很多年才能完成或者客户急于实现系统,各子系统往往采用增量开发的模式,先实现核心的产品,即实现基本的需求,但很多补充的特性(其中一些是已知的,另外一些是未知的)在下一期发布。增量模型强调每一个增量均发布一个可操作产品,每个增量构建仍然遵循设计-编码-测试的瀑布模型

 

图:增量模型示意图

概要设计是软件开发中一个重要的关注点,大部分需求在概要设计完成后系统会被分为相关的子系统和功能模块,每个功能模块间的接口都可以定义清楚,在这种情况下,当某个模块的详细设计做完成后没有必要等到其它模块的详细设计都要完全作完就能进行编码,这样就可以在概要设计完成后将系统分为多个模块并行开发,每个子系统或子模块仍然遵循设计-编码-测试的瀑布模型,这也是一种增量开发的模型。

 
 

图:增量模型示意图

5.  迭代模型

早在20世纪50年代末期,软件领域中就出现了迭代模型。最早的迭代过程可能被描述为“分段模型”。迭代,包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。所以,在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。

实质上,它类似小型的瀑布式项目。所有的阶段(需求及其它)都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。

图:迭代思想示意图

在现阶段,很多组织都无一例外地都推荐、主张采用能显著减少风险的迭代模型。美国国防部原本提倡瀑布过程和观点,在发现那么多采用了瀑布模型的失败的项目之后,不但放弃了对它的要求,而且从1994年的报告开始,积极地鼓励采用更加现代化的迭代模型来取代瀑布模型做法。同时,中国中科院也提倡选用迭代模型。

图:迭代模型示意图

6.  生命周期模型的选择准则

经过软件工程多年的经验积累,可以通过已知的项目特点来选择适合的生命周期模型,以此减少项目已知的风险,生命周期模型选择的原则如下:

项目特点
  瀑布模型
  增量模型
  原型+瀑布
  迭代
 
需求规模
  中、小
  大、中
  中、小
  大、中、小
 
需求清晰度
  很清晰
  较清晰
  不清晰
  不清晰
 
客户信息化能力
  高
  中
  中
  中、低
 
客户界面要求
  低
  中
  高
  高
 
行业特点
  行业规则简单或已掌握的行业
  新行业的应用型项目或已掌握的行业
  新行业的应用型项目
  新行业的研发型或应用型项目
 
架构设计能力
  有较成熟的架构设计能力
  采用了新的架构设计
  采用新的架构设计
  不能确定的架构设计
 
技术要求
  采用成熟的技术
  采用较少的新技术
  采用较少的新技术
  采用较多的新技术
 
管理要求
  工作产品的控制基线,需要有较高的可见度和可靠性 。
  每个增量阶段需要发布可操作产品。
  原型阶段,需要控制原型制作的成本。
  需要有较高的项目控制能力。每个迭代阶段需要有明确的目标。

本文作者:网友 来源: http://blog.csdn.net/tomfshao/archive/2009/07/24/4378299.aspx
CIO之家 www.ciozj.com 微信公众号:imciow
    >>频道首页  >>网站首页   纠错  >>投诉
版权声明:CIO之家尊重行业规范,每篇文章都注明有明确的作者和来源;CIO之家的原创文章,请转载时务必注明文章作者和来源;
延伸阅读