快速原型模型需要迅速建造一个可以运行的软件原型 ,以便理解和澄清问题,使开发人员与用户达成共识,最终在确定的
客户需求基础上开发
客户满意的
软件产品。 快速原型模型允许在
需求分析阶段对软件的需求进行初步而非完全的分析和定义,快速设计开发出
软件系统的原型,该原型向用户展示待开发软件的全部或部分功能和性能;用户对该原型进行测试评定,给出具体改进意见以丰富细化
软件需求;开发人员据此对软件进行修改完善,直至用户满意认可之后,进行软件的完整实现及测试、维护。
模型简述
原型是指模拟某种产品的原始模型,在其他产业中经常使用。
软件开发中的原型是软件的一个早期可运行的版本,它反映了最终系统的重要特性。
快速原型模型又称原型模型,它是
增量模型的另一种形式;它是在开发
真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作。快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发
客户满意的
软件产品。
优缺点
优点:克服
瀑布模型的缺点,减少由于
软件需求不明确带来的开发风险。
这种模型适合预先不能确切定义需求的软件系统的开发。
缺点:所选用的开发技术和工具不一定符合主流的发展;快速建立起来的
系统结构加上连续的修改可能会导致
产品质量低下。
使用这个模型的前提是要有一个展示性的
产品原型,因此在一定程度上可能会限制开发人员的创新。
产生原理
思想的产生
由于种种原因,在
需求分析阶段得到完全、一致、准确、合理的需求说明是很困难的,在获得一组基本需求说明后,就快速地使其“实现”,通过原型反馈,加深对系统的理解,并满足用户基本要求,使用户在试用过程中受到启发,对需求说明进行补充和精确化,消除
不协调的
系统需求,逐步确定各种需求,从而获得合理、协调一致、无歧义的、完整的、现实可行的需求说明。又把快速原型思想用到软件开发的其他阶段,向软件开发的全过程扩展。即先用相对少的成本,较短的周期开发一个简单的、但可以运行的系统原型向用户演示或让用户试用,以便及早澄清并检验一些主要
设计策略,在此基础上再开发实际的软件系统。
原理
快速原型是利用原型辅助软件开发的一种新思想。经过简单快速分析,快速实现一个原型,用户与开发者在试用原型过程中加强通信与反馈,通过反复评价和改进原型,减少误解,弥补漏洞,适应变化,最终提高
软件质量。
模型类型
探索型原型
这种类型的原型是把原型用于开发的
需求分析阶段,目的是要弄清用户的需求,确定所期望的特性,并探索各种方案的可行性。它主要针对开发目标模糊,用户与开发都对项目都缺乏经验的情况,通过对原型的开发来明确用户的需求。
实验型原型
这种原型主要用于
设计阶段,考核实现方案是否合适,能否实现。对于一个大型系统,若对
设计方案心中没有把握时,可通过这种原型来证实设计方案的正确性。
演化型原型
这种原型主要用于及早向用户提交一个
原型系统,该原型系统或者包含系统的框架,或者包含系统的主要功能,在得到用户的认可后,将原型系统不断扩充演变为最终的软件系统。它将原型的思想扩展到软件开发的全过程。
运用方式
由于运用原型的目的和方式不同,在使用原型时也采取不同的策略,有抛弃策略和附加策略。
1、抛弃策略是将原型用于开发过程的某个阶段,促使该阶段的开发结果更加完整、准确、一致、可靠,该阶段结束后,原型随之作废。探索型和实验型就是采用此策略的。
2、附加策略是将原型用于开发的全过程,原型由最基本的核心开始,逐步增加新的功能和新的需求,反复修改反复扩充,最后发展为用户满意的最终系统,演化型快速原型就是采用此策略。
采用何种形式、何种策略运用快速原型主要取决于软件项目的特点、
人员素质、可供支持的原型
开发工具和技术等,这要根据实际情况的特点来决定。
开发步骤
快速分析
在分析人员与用户密切配合下,迅速确定系统的基本需求,根据原型所要体现的特征描述基本需求以满足开发原型的需要。
构造原型
在快速分析的基础上,根据基本需求说明尽快实现一个可行的系统。这里要求具有强有力的
软件工具的支持,并忽略最终系统在某些细节上的要求,如安全性、
坚固性、例外处理等等,主要考虑
原型系统能够充分反映所要评价的特性,而暂时删除一切次要内容。
运行原型
这是发现问题、消除误解、开发者与用户充分协调的一个步骤。
评价原型
在运行的基础上,考核评价原型的特性,分析运行效果是否满足用户的愿望,纠正过去交互中的误解与分析中的错误,增添新的要求,并满足因
环境变化或用户的新想法引起的
系统要求变动,提出全面的修改意见。
修改
根据评价原型的活动结果进行修改。若原型未满足需求说明的要求,说明对需求说明存在不一致的理解或实现方案不够合理,则根据明确的要求迅速修改原型。
模型对比
传统的
瀑布模型本质上是一种
线性顺序模型,存在着比较明显的缺点,各阶段之间存在着严格的顺序性和
依赖性,特别是强调预先定义需求的重要性,在着手进行具体的开发工作之前,必须通过
需求分析预先定义并“冻结”
软件需求,然后再
一步一步的实现这些需求。但是实际项目很少是遵循着这种线性顺序进行的。在系统建立之前很难只依靠分析就确定出一套完整、准确、一致和有效的
用户需求,这种预先定义需求的方法更不能适应用户需求不断变化的情况。
用户的不断变化的需求具体表现在:
(1)需求是可变的。某些应用软件的需求与外部环境、经营内容等密切相关,因此需求是随时变化的,按照这样预先指定的需求开发软件,当软件开发出来的时候就往往已经过时,不符合用户的需要。
(2)需求是模糊的。对于大多数的应用系统,例如
管理信息系统,其需求往往很难预先准确的定义,也就是说,预先定义需求的策略所做出的假设,只对某些软件成立,对多数软件并不成立。许多用户对他们的需求最初只有模糊的概念,想要求一个对需求只有初步设想的人准确无误的说出全部需求,显然是不切实际的。
(3)用户和开发者沟通困难。大多数用户和专业领域的专家不热悉计算机和软件开发技术,软件开发人员也往往不熟悉用户的专业领域,因此,开发人员和用户之间很难做到完全沟通和
相互理解,在
需求分析阶段做出的用户需求常常是不完整、
不准确的。
传统的
瀑布模型很难适应需求可变、模糊不定的
软件系统的开发,而且在开发过程中,用户很难参与进去,只有到开发结束才能看到整个软件系统。这种理想的、线性的开发过程,缺乏灵活性,不适合实际的开发过程。
而快速原型模型的提出,可以较好的解决瀑布模型的局限性,通过建立原型,可以更好的和客户进行沟通,解决对一些模糊需求的澄清,并且对需求的变化有较强的
适应能力。原型模型可以减少技术、应用的风险,缩短开发时间,减少费用,提高
生产率,通过实际运行原型,提供了用户直接
评价系统的方法,促使用户主动参与开发活动,加强了信息的反馈,促进了各类人员的协调交流,减少误解,能够适应需求的变化,最终有效提高软件系统的质量。