软件开发过程生命周期模型
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件开发过程生命周期模型
一、序言
生命周期指软件开发全部过程、活动和任务的结构框架。
软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段。
目前软件开发实践中使用的各种生命周期模型,都是下面这些基本组成部分的不同的排列与组合。
∙市场分析,可行性研究,与项目定义
∙需求分析
∙设计(概要设计和详细设计)
∙编码实现
∙测试
∙使用与维护
主要有以下几种模型:
∙ 1.瀑布模型(waterfall model)
∙ 2.演化模型(evolutionary model)
∙ 3.螺旋模型(spiral model)
二、瀑布模型
瀑布模型将软件生命周期的各项活动规定为依固定顺序联接的若干阶段工作,形如瀑布流水,最终得到软件产品。
如图所示:
优点:
a.强调开发的阶段性;
b.强调早期计划及需求调查;
c.强调产品测试。
缺点:
a.依赖于早期进行的唯一一次需求调查,不能适应需求的变化;
b.由于是单一流程,开发中的经验教训不能反馈应用于本产品的过程;
c.风险往往迟至后期的开发阶段才显露,因而失去及早纠正的机会
下表是瀑布模型中各个阶段的主要工作,及相应的质量控制手段。
三、演化模型
该模型主要针对事先不能完整定义需求的软件开发。
用户可以给出待开发系统的核心需求,并且当看到核心需求实现后,能够有效地提出反馈,以支持系统的最终设计和实现。
软件开发人员根据用户的需求,首先开发核心系统。
当该核心系统投入运行后,用户试用之,完成他们的工作,并提出精化系统、增强系统能力的需求。
软件开发人员根据用户的反馈,实施开发的迭代过程。
第一迭代过程均由需求、设计、编码、测试、集成等阶段组成,为整个系统增加一个可定义的、可管理的子集。
如图所示。
在开发模式上采取分批循环开发的办法,每循环开发一部分的功能,它们成为这个产品的原型的新增功能。
于是,设计就不断地演化出新的系统。
实际上,这个模型可看作是重复执行的多个“瀑布模型”。
“演化模型”要求开发人员有能力把项目的产品需求分解为不同组,以便分批循环开发。
这种分组并不是绝对随意性的,而是要根据功能的重要性及对总体设计的基础结构的影响而作出判断。
有经验指出,每个开发循环以六周到八周为适当的长度。
优点:
∙ a.任何功能一经开发就能进入测试以便验证是否符合产品需求。
∙ b.帮助导引出高质量的产品要求。
如果没有可能在一开始就弄清楚所有的产品需求,它们可以分批取得。
而对于已提出的产品需求,则可根据对现阶段原型的试用而作出修改。
∙ c.风险管理可以在早期就获得项目进程数据,可据此对后续的开发循环作出比较切实的估算。
提供机会去采取早期预防措施,增加项目成功的机率。
∙ d.大大有助于早期建立产品开发的配置管理,产品构建(build ),自动化测试,缺陷跟踪,文档管理。
均衡整个开发过程的负荷。
∙ e.开发中的经验教训能反馈应用于本产品的下一个循环过程,大大提高质量与效率。
∙ f.如果风险管理发现资金或时间已超出可承受的程度,则可以决定调整后续的开发,或在一个适当的时刻结束开发,但仍然有一个具有部分功能的,可工作的产品。
∙g.心理上,开发人员早日见到产品的雏型,是一种鼓舞。
∙h.使用户可以在新的一批功能开发测试后,立即参加验证,以便提供非常有价值的反馈。
∙i.可使销售工作有可能提前进行,因为可以在产品开发的中后期取得包含了主要功能的产品原型去向客户作展示和试用。
缺点:
∙ a.如果所有的产品需求在一开始并不完全弄清楚的话,会给总体设计带来困难及削弱产品设计的完整性,并因而影响产品性能的优化及产品的可维护性。
∙ b.如果缺乏严格的过程管理的话,这个生命周期模型很可能退化为一种原始的无计划的“试-错-改”模式。
∙ c.心理上,可能产生一种影响尽最大努力的想法,认为虽然不能完成全部功能,但还是造出了一个有部分功能的产品。
d.如果不加控制地让用户接触开发中尚未测试稳定的功能,可能对开发人员及用户都产生负面的
影响。
四、螺旋模型
瀑布模型与演化模型相结合,并加入两者所忽略的风险分析所建立的一种软件开发模型。
该模型于1998年由美国TRW公司(B.W.Boehm)提出。
软件项目风险的大小作为指引软件过程的一个重要因素,引入这一概念有可能使得软件开发被看作一种元模型,因为它能包容任何一个开发过程模型。
螺旋模型基本的做法是在“瀑布模型”的每一个开发阶段之前,引入非常严格的风险识别、风险分析和风险控制。
直到采取了消除风险的措施之后,才开始计划下一阶段的开发工作。
否则,项目就很可能被取消。
另外,如果有充足的把握判断遗留的风险已降低到一定的程度,项目管理人员可作出决定让余下的开发工作采用另外的生命周期模型,如“演化模型”,“瀑布模型”,或自定的混合模型。
优点:
a.强调严格的全过程风险管理。
b.强调各开发阶段的质量。
c.提供机会检讨项目是否有价值继续下去。
缺点:
a.引入非常严格的风险识别,风险分析,和风险控制,这对风险管理的技能水平提出了很高的要求。
这需要人员,资金,和时间的投入。
五、软件生命周期模型的选择
对于需求明确的项目,建议采用演化模型。
对于规模小,需求简单,功能单一的项目,建议采用瀑布模型。
其他项目,一般采用迭代模型。
原型开发方法
快速原型法(rapid prototyping)快速原型法是近年来提出的一种以计算机为基础的系统开发方法,它首先构造一个功能简单的原型系统,然后通过对原型系统逐步求精,不断扩充完善得到最终的软件系统。
原型就是模型,而原型系统就是应用系统的模型。
它是待构筑的实际系统的缩小比例模型,但是保留了实际系统的大部分性能。
这个模型可在运行中被检查、测试、修改,直到它的性能达到用户需求为止。
因而这个工作模型很快就能转换成原样的目标系统。
原型法有三个层次
第一层包括联机的屏幕活动,这一层的目的是确定屏幕及报表的版式和内容、屏幕活动的顺序及屏幕排版的方法;
第二层是第一层的扩展,引用了数据库的交互作用及数据操作,这一层的主要目的是论证系统关键区域的操作,用户可以输入成组的事务数据,执行这些数据的模拟过程,包括出错处理;
第三层是系统的工作模型,它是系统的一个子集,其中应用的逻辑事务及数据库的交互作用可以用实际数据来操作,这一层的目的是开发一个模型,使其发展成为最终的系统规模。
原型法的主要优点在于它是一种支持用户的方法,使得用户在系统生存周期的设计阶段起到积极的作用;它能减少系统开发的风险,特别是在大型项目的开发中,由于对项目需求的分析难以一次完成,应用原型法效果更为明显。
原型法的概念既适用于系统的重新开发,也适用于对系统的修改;原型法不局限于仅对开发项目中的计算机方面进行设计,第三层原型法是用于制作系统的工作模型的。
快速原型法要取得成功,要求有象第四代语言(4GL)这样的良好开发环境/工具的支持。
原型法可以与传统的生命周期方法相结合使用,这样会扩大用户参与需求分析、初步设计及详细设计等阶段的活动,加深对系统的理解。
近年来,快速原型法的思想也被应用于产品的开发活动中。