软件生命周期模型的其它几种典型的软件生命周期模型
其它几种典型的生命周期模型包括迭代模型、快速原型模型、V模型、W模型。
迭代式模型是是RUP(Rational Unified Process,统一软件开发过程,统一软件过程)推荐的周期模型。
在RUP中,迭代被定义为:迭代包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。
所以,在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。
实质上,它类似小型的瀑布式项目。
RUP认为,所有的阶段(需求及其它)都可以细分为迭代。
每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。
迭代的思想如图所示。
迭代和瀑布的最大的差别就在于风险的暴露时间上。
“任何项目都会涉及到一定的风险。
如果能在生命周期中尽早确保避免了风险,那么您的计划自然会更趋精确。
有许多风险直到已准备集成系统时才被发现。
不管开发团队经验如何,都绝不可能预知所有的风险。
” 由于瀑布模型的特点(文档是主体),很多的问题在最后才会暴露出来,为了解决这些问题的风险是巨大的。
在迭代式生命周期中,您需要根据主要风险列表选择要在迭代中开发的新的增量内容。
每次迭代完成时都会生成一个经过测试的可执行文件,这样就可以核实是否已经降低了目标风险。
快速原型(Rapid Prototype)模型在功能上等价于产品的一个子集。
注意,这里说的是功能上。
瀑布模型的缺点就在于不够直观,快速原型法就解决了这个问题。
一般来说,根据客户的需要在很短的时间内解决用户最迫切需要,完成一个可以演示的产品。
这个产品只是实现部分的功能(最重要的)。
它最重要的目的是为了确定用户的真正需求。
在我的经验中,这种方法非常的有效,原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河,有些观点让你都觉得非常的吃惊。
在得到用户的需求之后,原型将被抛弃。
因为原型开发的速度很快,设计方面是几乎没有考虑的,如果保留原型的话,在随后的开发中会为此付出极大的代价。
至于保留原型方面,也是有一种叫做增量模型是这么做的,但这种模型并不为大家所接受,不在我们的讨论之内。
上述的模型中都有自己独特的思想,其实软件组织中很少说标准的采用那一种模型的。
模型和实用还是有很大的区别的。
软件生命周期模型的发展实际上是体现了软件工程理论的发展。
在最早的时候,软件的生命周期处于无序、混乱的情况。
一些人为了能够控制软件的开发过程,就把软件开发严格的区分为多个不同的阶段,并在阶段间加上严格的审查。
这就是瀑布模型产生的起因。
瀑布模型体现了人们对软件过程的一个希望:严格控制、确保质量。
可惜的是,现实往往是残酷的。
瀑布模型根本达不到这个过高的要求,因为软件的过程往往难于预测。
反而导致了其它的负面影响,例如大量的文档、繁琐的审批。
因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。
例如把过程细分来增加过程的可预测性。
软件生命周期模型概述及使用准则是什么呢?
软件生命周期模型是软件开发的全部过程、活动和任务的结构框架。
软件生命周期模型能清晰、直观地表达软件开发全过程,明确规定了要完成的主要活动和任务,用来作为软件项目开发的基础。
典型的生命周期模型有: 1. 瀑布模型(Waterfall Model) 2. 渐增模型/演化/迭代模型(Incremental Model) 3. 原型模型(Prototype Model) 4. 螺旋模型(Spiral Model) 5. 喷泉模型(Fountain Model) 6. 智能模型(Intelligent Model) 7. 混合模型(Hybrid Model)...
软件生命周期模型的瀑布型生命周期主要阶段
瀑布型生命周期的典型六个阶段1、问题的定义及规划此阶段是软件开发方与需求方共同讨论,主要确定软件的开发目标及其可行性。
2、需求分析在确定软件开发可行的情况下,对软件需要实现的各个功能进行详细分析。
需求分析阶段是一个很重要的阶段,这一阶段做得好,将为整个软件开发项目的成功打下良好的基础。
唯一不变的是变化本身。
,同样需求也是在整个软件开发过程中不断变化和深入的,因此我们必须制定需求变更计划来应付这种变化,以保护整个项目的顺利进行。
3、软件设计此阶段主要根据需求分析的结果,对整个软件系统进行设计,如系统框架设计,数据库设计等等。
软件设计一般分为总体设计和详细设计。
好的软件设计将为软件程序编写打下良好的基础。
4、程序编码此阶段是将软件设计的结果转换成计算机可运行的程序代码。
在程序编码中必须要制定统一,符合标准的编写规范。
以保证程序的可读性,易维护性,提高程序的运行效率。
5、软件测试在软件设计完成后要经过严密的测试,以发现软件在整个设计过程中存在的问题并加以纠正。
整个测试过程分单元测试、组装测试以及系统测试三个阶段进行。
测试的方法主要有白盒测试和黑盒测试两种。
在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试,以减少测试的随意性。
6、运行维护软件维护是软件生命周期中持续时间最长的阶段。
在软件开发完成并投入使用后,由于多方面的原因,软件不能继续适应用户的要求。
要延续软件的使用寿命,就必须对软件进行维护。
软件的维护包括纠错性维护和改进性维护两个方面。
如何为软件开发项目选择一个合适的软件生命周期模型
果单纯从技术上来说。
不同的出发点,定义的结果也不同,一般推荐迭代模型。
但软件并不是因为技术而产生的,是因为业务性目的而产生的。
这个业务性目的可能是商业的,也可能是非商业的。
不同的软件建造目的和效果预期决定了选择怎样的模型。
如果是一锤子买卖的软件,也未必就用迭代模型。
这个看你怎么定义一个软件的全生命周期...
什么是软件的生命周期模型?它主要有那些模型?
软件生命周期是指从软件定义、开发、使用、维护到报废为止的整个过程,一般包括问题定义、可行性分析、需求分析、总体设计、详细设计、编码、测试和维护。
问题定义就是确定开发任务到底“要解决的问题是什么”,系统分析员通过对用户的访问调查,最后得出一份双方都满意的关于问题性质、工程目标和规模的书面报告。
可行性分析就是分析上一个阶段所确定的问题到底“可行吗”,系统分析员对系统要进行更进一步的分析,更准确、更具体地确定工程规模与目标,论证在经济上和技术上是否可行,从而在理解工作范围和代价的基础上,做出软件计划。
需求分析即使对用户要求进行具体分析,明确“目标系统要做什么”,把用户对软件系统的全部要求以需求说明书的形式表达出来。
总体设计就是把软件的功能转化为所需要的体系结构,也就是决定系统的模块结构,并给出模块的相互调用关系、模块间传达的数据及每个模块的功能说明。
详细设计就是决定模块内部的算法与数据结构,也是明确“怎么样具体实现这个系统”。
编码就是选取适合的程序设计语言对每个模板进行编码,并进行模块调试。
测试就是通过各种类型的测试使软件达到预定的要求。
维护就是软件交付给用户使用后,对软件不断查错、纠错和修改,使系统持久地满足用户的需求。
软件的生命周期也可以分为3个大的阶段,分别是计划阶段、开发阶段和维护阶段。
瀑布模型有时也称为V模型,它是一种线型顺序模型,是项目自始至终按照一定顺序的步骤从需求分析进展到系统测试直到提交用户使用,它提供了一种结构化的、自顶向下的软件开发方法,每阶段主要工作成果从一个阶段传递到下一个阶段,必须经过严格的评审或测试,以判定是否可以开始下一阶段工作,各阶段相互独立、不重叠。
瀑布模型是所有软件生命周期模型的基础。
原型+瀑布模型原型模型本身是一个迭代的模型,是为了解决在产品开发的早期阶段存在的不确定性、二义性和不完整性等问题,通过建立原型使开发者进一步确定其应开发的产品,使开发者的想象更具体化,也更易于被客户所理解。
原型只是真实系统的一部分或一个模型,完全可能不完成任何有用的事情,通常包括抛弃型和进化型两种,抛弃型指原型建立、分析之后要扔掉,整个系统重新分析和设计;进化型则是对需求的定义较清楚的情形,原型建立之后要保留,作为系逐渐增加的基础,采用进化型一定要重视软件设计的系统性和完整性,并且在质量要求方面没有捷径,因此,对于描述相同的功能,建立进化型原型比建立抛弃型原型所花的时间要多。
原型建立确认需求之后采用瀑布模型的方式完成项目开发。
增量模型与建造大厦相同,软件也是一步一步建造起来的。
在增量模型中,软件被作为一系列的增量构件来设计、实现、集成和测试,每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成。
增量模型在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品。
整个产品被分解成若干个构件,开发人员逐个构件地交付产品,这样做的好处是软件开发可以较好地适应变化,客户可以不断地看到所开发的软件,从而降低开发风险。
一些大型系统往往需要很多年才能完成或者客户急于实现系统,各子系统往往采用增量开发的模式,先实现核心的产品,即实现基本的需求,但很多补充的特性(其中一些是已知的,另外一些是未知的)在下一期发布。
增量模型强调每一个增量均发布一个可操作产品,每个增量构建仍然遵循设计-编码-测试的瀑布模型。
迭代模型早在20世纪50年代末期,软件领域中就出现了迭代模型。
最早的迭代过程可能被描述为“分段模型”。
迭代,包括产生产品发布(稳定、可执行的产品版本)的全部开发活动和要使用该发布必需的所有其他外围元素。
所以,在某种程度上,开发迭代是一次完整地经过所有工作流程的过程:(至少包括)需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。
实质上,它类似小型的瀑布式项目。
所有的阶段(需求及其它)都可以细分为迭代。
每一次的迭代都会产生一个可以发布的产品,这个产品是最终产品的一个子集。
转载请注明出处51数据库 » 软件生命周期模型及其主要活动