软件开发中的快速原型法

软件开发中的快速原型法
软件开发中的快速原型法

快速原型法(rapid prototyping)

快速原型法是近年来提出的一种以计算机为基础的系统开发方法,它首先构造一个功能简单的原型系统,然后通过对原型系统逐步求精,不断扩充完善得到最终的软件系统。原型就是模型,而原型系统就是应用系统的模型。它是待构筑的实际系统的缩小比例模型,但是保留了实际系统的大部分性能。这个模型可在运行中被检查、测试、修改,直到它的性能达到用户需求为止。因而这个工作模型很快就能转换成原样的目标系统。

原型法有三个层次

第一层包括联机的屏幕活动,这一层的目的是确定屏幕及报表的版式和内容、屏幕活动的顺序及屏幕排版的方法;

第二层是第一层的扩展,引用了数据库的交互作用及数据操作,这一层的主要目的是论证系统关键区域的操作,用户可以输入成组的事务数据,执行这些数据的模拟过程,包括出错处理;

第三层是系统的工作模型,它是系统的一个子集,其中应用的逻辑事务及数据库的交互作用可以用实际数据来操作,这一层的目的是开发一个模型,使其发展成为最终的系统规模。

原型法的主要优点在于它是一种支持用户的方法,使得用户在系统生存周期的设计阶段起到积极的作用;它能减少系统开发的风险,特别是在大型项目的开发中,由于对项目需求的分析难以一次完成,应用原型法效果更为明显。原型法的概念既适用于系统的重新开发,也适用于对系统的修改;原型法不局限于仅对开发项目中的计算机方面进行设计,第三层原型法是用于制作系统的工作模型的。快速原型法要取得成功,要求有象第四代语言(4GL)这样的良好开发环境/工具的支持。原型法可以与传统的生命周期方法相结合使用,这样会扩大用户参与需求分析、初步设计及详细设计等阶段的活动,加深对系统的理解。近年来,快速原型法的思想也被应用于产品的开发活动中。

快速原型方法与开发的风险管理

软件系统往往体现一定的功能,这些功能要符合一定的使用目的。现实世界是在不断变化的,而且变化的速度是越来越快,唯一不变的就是“变化”的主题。这一现实也就直接影响到了实现实际功能的软件系统,体现在需求、技术实现手段、应用环境等多个方面,这些都直接影响到了软件系统自身的稳定性。同时,由于快速变化这一事实,人们对于以后的预测能力也越来越有限,有时根本难以明确未来的需求,只能是根据环境的变化而随时调整,因此直接导致了软件生命周期越来越短这一现实,特别是应用软件,直接与这种变化紧密相

连。

但是,软件开发往往需要一定的时间,一个软件系统从需求、设计、开发到投入使用,这一周期都不会很短,即从需求产生到实际能够投入使用这段时间,其本身就已经成为应用软件自身的风险,很可能当一个软件开发完成的时候,市场需求已经发生了变化,开发出来的软件已经不适用了。软件生命周期已经缩短,特别是应用软件,随着新业务的市场窗口变窄的趋势,其自身的寿命周期也在缩短。快速投放市场已经成为软件系统的首要因素。另一方面,由于快速变化的外部环境给软件产品带来的风险,成本控制也成为软件工程管理的一个重要方面,通过对需求变化的风险的评估来重新认识软件寿命周期,以合理的成本完成软件开发,也已经成为对软件产品管理者的一个挑战。

在传统的软件工程方法中,主要使用瀑布式顺序开发方法,包括需求分析和定义、系统设计、实现和单元测试、系统集成测试、运行维护等多个阶段,这一方法的优点是全面、严谨,但最大的缺陷,就是过程一旦启动就难以适应变化。这一方法是基于一个重要的假设前提——能够提出明确的需求。当面对快速变化、甚至是根本不明确的需求时,这种假设根本上就不成立,因此这种传统的开发方法的缺点就越来越突出,特别是应用软件的开发,由于它与市场的联系更加紧密,使用这种传统的开发方法,已经难以为继。我们需要寻找一种更加快速、成本合理的软件开发方法。

快速原型方法就是这样一种开发更加迅速、更加成本合理的开发方法。在软件开发过程中,最关键的步骤就是确切定义出需求,明确软件要实现的功能是什么,而这恰恰也是最困难的过程,因为现在许多用户在初期只有一个隐约的、大致的考虑,根本不可能提出具体明确的需求。这种情况下,使用快速原型进行反复交流、细化需求,就成为一种更加有效的方法。一个软件的原型,主要是模拟重要的功能和界面,但是一般不考虑运行效率,也不考虑系统的健壮性,出错处理也考虑不多,它的目的只是为了实际描述概念中的结构,使用户能够检测与其概念的一致性和概念的可用性。

目前主要有两种快速原型方法:

·丢弃原型(Throw-away prototyping)。其目标只是为了明确需求,使用最简单的开发方法,以最低的成本实现一个可工作的系统,该系统只关注功能,不考虑开发工具、性能、容错、未来实际运行环境等。通过反复与客户交流和修改原型,使原型的功能能够充分体现客户需求。在明确了需求之后,原型就会被丢弃。以后软件的开发将根据明确了的需求按照传统的工程化方法来开发。

·进化原型(Evolutionary prototyping)。其目标就是与客户一起工作,从一个原始的需求的轮廓开始,逐步改进,最终发展成为符合实际需要的系统。采用这种方法,就需要考虑到软件未来的运行环境等有关要求,这就要求从一开始就要对需求有一个比较清晰的认识,不能有方向性的错误。

市场需求和新技术发展,最大的风险往往来自对需求的分析和技术实现手段的选择,通过原型化方法,首先以合理的成本细化需求、试验技术手段,把最主要的风险降到最低,从而在总体上降低软件开发的风险,加快软件产品的形成,降低软件开发的成本。

快速原型方法的过程,特别是进化的原型方法,与软件的版本升级有些类似。随着市场需求的变化,软件版本不断升级,每升级一次,就会增加新的功能,或者引入符合发展新趋势的技术手段。但是每一个版本都是产品化的,在产品质量方面都达到了相当的要求,这与软件原型是不同的,快速原型是一个由粗到细的过程,在最终形成产品之前,不论原型被修改了多少个版本,都还不能达到产品化的要求,不能对外发布。

使用快速原型方法的最大困难就是工程管理的问题,许多具有较强管理能力的企业对快速原型方法也感到畏惧,根本原因就是其不确定性所带来的风险。但是应该知道,快速原型的方法,正是为了针对主要风险,分解风险,尽早地、低成本地降低风险。否则,如果一味

地强调软件开发必须以明确的需求为前提,采用传统的瀑布式开发方法,则会面临更大的市场风险,如果以不明确的需求采用传统的开发方法,软件开发本身也必然面临着灾难性的风险。因此,快速原型方法应该成为我们软件开发过程中降低风险的一种有效的方法。

许多企业在新的软件开发需求提出时,实际已经建立了自己的信息系统的基础架构,也已经开发了类似的软件系统,因此在新产品开发中应采用的技术手段方面,已经不存在问题,这时的风险主要存在于不明确的需求上,此时采用进化的原型方法,比丢弃的原型方法会更有效。为了加强对原型化方法的开发过程的管理,可以在整个原型化过程中把每一次对需求的细化看作是一次版本升级,在每一次升级过程中,细化了的需求是明确的(虽然还不一定是最终的),这就可以采用瀑布式开发管理方法,只是这一过程的周期会非常短,而且只要不是最终版本,成本就必须控制在最低。从另一个角度来说,如果企业的规划能力比较强,对整个产品发展、信息系统建设都有比较明确的思路,这对于降低单个软件产品的风险非常有利,限制了产品的风险,为单个软件产品的设计开发,提供了很好的基础。因此,使用快速原型方法,需要充分考虑到与企业原有的规划和基础设施的关系,并注意对它们的影响。下图是一种典型的快速原型方法的工作流程。

最后还需要强调一点。为了是软件工程管理能够适应这种快速变化的要求,使用相应的软件工程管理软件是十分必要的。它主要有几个方面的好处:

1,建模工具和自动代码生成工具能够大大提高开发的速度。

2,配置管理工具可以有效对对软件的变更进行管理。

3,强大的测试工具可以更加有效地覆盖测试范围,提高测试的效率。

4,强化对软件开发过程中的流程管理,加强沟通协作,提高工作效率。

5,提高项目的绩效管理水平。

越是风险高的项目,就越需要引入强有力的管理工具,提高管理力度和管理水平。加强科学管理是提高风险管理水平的唯一出路。

软件开发中的快速原型法

快速原型法(rapid prototyping) 快速原型法是近年来提出的一种以计算机为基础的系统开发方法,它首先构造一个功能简单的原型系统,然后通过对原型系统逐步求精,不断扩充完善得到最终的软件系统。原型就是模型,而原型系统就是应用系统的模型。它是待构筑的实际系统的缩小比例模型,但是保留了实际系统的大部分性能。这个模型可在运行中被检查、测试、修改,直到它的性能达到用户需求为止。因而这个工作模型很快就能转换成原样的目标系统。 原型法有三个层次 第一层包括联机的屏幕活动,这一层的目的是确定屏幕及报表的版式和内容、屏幕活动的顺序及屏幕排版的方法; 第二层是第一层的扩展,引用了数据库的交互作用及数据操作,这一层的主要目的是论证系统关键区域的操作,用户可以输入成组的事务数据,执行这些数据的模拟过程,包括出错处理; 第三层是系统的工作模型,它是系统的一个子集,其中应用的逻辑事务及数据库的交互作用可以用实际数据来操作,这一层的目的是开发一个模型,使其发展成为最终的系统规模。 原型法的主要优点在于它是一种支持用户的方法,使得用户在系统生存周期的设计阶段起到积极的作用;它能减少系统开发的风险,特别是在大型项目的开发中,由于对项目需求的分析难以一次完成,应用原型法效果更为明显。原型法的概念既适用于系统的重新开发,也适用于对系统的修改;原型法不局限于仅对开发项目中的计算机方面进行设计,第三层原型法是用于制作系统的工作模型的。快速原型法要取得成功,要求有象第四代语言(4GL)这样的良好开发环境/工具的支持。原型法可以与传统的生命周期方法相结合使用,这样会扩大用户参与需求分析、初步设计及详细设计等阶段的活动,加深对系统的理解。近年来,快速原型法的思想也被应用于产品的开发活动中。 快速原型方法与开发的风险管理 软件系统往往体现一定的功能,这些功能要符合一定的使用目的。现实世界是在不断变化的,而且变化的速度是越来越快,唯一不变的就是“变化”的主题。这一现实也就直接影响到了实现实际功能的软件系统,体现在需求、技术实现手段、应用环境等多个方面,这些都直接影响到了软件系统自身的稳定性。同时,由于快速变化这一事实,人们对于以后的预测能力也越来越有限,有时根本难以明确未来的需求,只能是根据环境的变化而随时调整,因此直接导致了软件生命周期越来越短这一现实,特别是应用软件,直接与这种变化紧密相

原型法和结构化系统开发法

结构化系统开发方法包括哪些步骤?与原型法相比,有什么缺点 随着金融领域计算机应用的快速普及,软件规模越来越大,复杂程度越来越高,相应的项目风险也越来越高,尤其在管理信息系统项目面临需求不明确、性能要求比较高的情况下,仅仅依赖传统的基于瀑布模型的开发模式已无法满足实际需要。快速原型法通过构建一个含有目标系统主要特征的“软件样机”,实现产品设计的快速评价、优化改进、功能试验、性能试验,用户通过测试原型,可以亲身体会目标系统的大致功能、性能等,同时也可启发用户的思路,反馈给开发人员,使需求更台理、明确.使设计更符合应用需要。 一、选择 1.以下各点中(A )不属于“业务流程”的基本要素: A 效率 B 输入资源 C 活动 D 价值 2.在以下各点中,(D )不属于“业务流程”的特点: A 目标性 B 动态性 C 整体性 D 环境适应性 3.以下各点中,(C )不是UC矩阵的作用之一: A 进行数据的完整性和匹配性检验 B 划分子系统

C 生成数据流程图 D 在网络中进行数据资源的分布 4.在以下系统规划方法中,(D )能抓住主要矛盾,使目标的识别突出重点: A 价值链分析法 B 企业系统规划法 C 战略目标集转化法 D 关键成功因素法 5.以下各点中,(C )不是诺兰阶段模型中提出的信息系统发展的阶段之一: A 初装 B 蔓延 C 成长 6.结构化系统开发方法的基本思想是什么?该方法具有哪些特点?[答] D 成熟 二、判断 1.用原型法开发信息系统需要一定的软件环境的支持。(正确) 2.原型法特别适合对大型系统的开发。(错误) 3.UC矩阵的每一列(数据列)中应当至少有一个以上的“U”。(正确) 4.结构化系统开发方法的缺点之一是工作繁琐、工作量大。(正确) 5.采用面向对象的系统开发方法可以不进行需求分析。(错误) 6.通常,“自下而上”的开发策略用于小型系统的设计,适用于对开发工作缺乏经验的情况。(正确) 7.建立信息系统是企业进行流程再造的有力工具之一。(正确) 8.BSP方法规划信息系统的缺点之一是,其规划的信息系统不能独立于企业的组织机构,

快速原型法--资料

“快速原型法”在项目开发中的成功案例 项目型软件的开发流程,通常会包括七个步骤:第一步:需求调研分析;第二步:概要设计;第三步:详细设计;第四步:编码;第五步:测试;第六步:软件交付准备;第七步:验收与收尾工作。 在项目型产品的开发过程中,依据软件工程思想的标准,遵循软件开发流程(Software development process)一步步的操作是最正统和最标准而且有效的做法,项目组人员的理解并落实这一点,整个项目就会朝着良性的方向发展。 狭义的项目组成员是指软件公司的人员,广义的项目组成员还应该包括客户方,对于客户来说,更关心的是结果而不是过程。由于项目组成员们的专业素养和技术水平会有差异(比如项目开发方的长处在计算机方面,而合作方在专业知识),再加上沟通不畅等因素,会给项目带来一些负面影响,比如甲乙双方对于研发成果存在争议、项目无法按期完成等等。 简单谈一下Byteh经历的一个项目情况。由于项目的专业性,摆在项目组人员的第一个问题就是理解需求其次才是后续步骤。如果严格按照软件开发的流程,必然会出现一些不可控的风险。 我方项目组果断决定采用快速原型法和敏捷开发的思想作为此次项目开发的主导,主要有以下几个措施: 1、在获取用户原始需求后迅速理解开发出一个雏形,把一个能看到的软件界面反馈给用户去探讨更进一步的需求,去更准确的把握用户需求,反复迭代。这点对甲乙双方都是有利的,当你拿着一堆文档让客户确认需求签字,从文档上看双方理解一致就签字了,然而等中期汇报做出来成果会发现简直就是南辕北辙,下次再签字肯定就会犹豫了…… 下图来自网上,说明了各方理解的“需求”和成果的差异:

演化原型法的基本思想

演化原型法的基本思想是,通过概略的系统分析与设计,在先进的IS开发工具的支持下,快速地实现一个能反映用户当前最迫切需求的原型,然后与用户一起运行并逐步改进,基本满足这个需求后,再逐步扩充其功能。因此,首先要把系统划分为相对独立的而又容易把握的若干个小系统,并选定其中一个作为第一期工程,然后在首轮开发中快速地得到其初始原型。本节以数据库(DB)设计为中心,使用Visual FoxPro(VFP)6.0,对某商业企业以其仓库的进、销、存信息系统为第一期工程,讨论用原型法开发首轮原型的具体过程。这里把系统分析与设计做得比较规范,叙述也是直线推进,是为使学生把握全貌。原型法的各轮开发都是只要做概略分析与设计就动手实现,并且是不断反复而非直线推进的。讨论中假定读者已经学过并熟悉VFP6.0。因此,有关VFP6.0的知识和程序设计这里不再重复,不熟悉的读者可参见有关的书籍。 11.4.1 系统首轮概要分析 仓库进、销、存(进货、销售、存储)管理是商业企业经营管理中的核心环节,也是一个企业能否取得效益的关键。建立仓库进、销、存信息系统的目的是使企业能做到合理进货、及时销售、库存量最小、周转灵活、没有积压,使企业取得最好的经济效益。 一. 需求初步分析 1.组织结构概况 通过调查研究,得出该商业企业的组织机构图如图11.3所示,图中只简单地给出与仓库进、销、存业务相关部分的结构层次图。供应部负责进货业务;销售部负责销售业务;仓储部下有三个仓库,负责存储各类商品。 图11.3某商业企业仓库的进、销、存组织机构图 2.业务流程概况 业务流程分析简述如下: J.进货管理 接受供应部门交来的进货单,审查,有错退回,无错则与已到货物核对,单物不符则退回,相符则把货物入库,在库存台帐各相关帐页中登入进货栏并修改库存栏。 P.盘存管理 接受仓储部门交来的盘存通知,审查,有错退回,无错则依库存台帐盘点货物,填写盘存明细表,按处理意见,登记库存台帐相应货物页,对使现存量少于最小存量者,登记进货要求单,交供应部门。 T.提货管理 接受销售部门交来的订货单,审查,有错退回,无错则与库存台帐核对,缺货项填缺货单交

快速原型法在深圳地铁AFC系统中的应用(一)

快速原型法在深圳地铁AFC系统中的应用(一) 摘要:系统地描述快速原型法在深圳地铁AFC应用系统实施过程中的应用,分析深圳地铁AFC应用系统在改进更新过程中遇到客观阻力的原因,并对采用快速原型法的两种分类途径解决实际应用情况进行阐述。 关键词:轻轨铁路;自动售检票系统;快速原型法;应用自动售检票(AFC)系统是综合技术性很强的一个专业系统,涉及到机械、电子、微控、传感、计算机、网络、数据库和系统集成等多个方面,整个系统实现具有很大难度。AFC应用系统软件是其中最具有代表性的,它不仅要集成所有售检票设备信息,还要对车票和现金等实物进行管理,涉及车站管理、收益管理和车票管理等各个环节,数据关系较为复杂,需求难以把握,开发具有一定难度,是实现AFC系统集成的关键环节。1AFC应用系统在开发和应用中遇到的问题 深圳地铁AFC系统的建设是在探索中前进的,作为第一个具有自主知识产权的国产化AFC系统来讲,它不断要根据实际情况做出改进。但对于这个涉及面广、层次多的庞大系统而言,达到应用系统的需求一步到位是不可能的。这就对AFC项目的使用维护方提出了高水平的要求,要在掌握到第一线的乘客需求、车站运作情况和目前应用系统软件所实现功能的前提下,提出AFC系统的改进方向。对项目的开发方而言,用户需求的多变是让开发人员头痛的问题,如何快速地根据用户需求改进软件,尽快拿出满足用户需求的软件更是增加了开发的难

度。 通过深圳地铁AFC系统两年来的实际使用,其中存在的一些问题显现出来,比如,管理信息不完整,部分统计数据不能满足实际运营需要,系统功能待改进等,造成工作效率低下、人力资源浪费和运作成本提高。在此基础之上,经深入讨论研究,使用快速原型法可以使实际和应用结合的较为紧密,是解决以上问题的有效方法。 2快速原型法技术介绍 快速原型法(RapidPrototypingMethod)是近年来提出的一种以计算机为基础的系统开发方法,它首先构造一个功能简单的原型系统,然后通过对原型系统逐步求精,不断扩充完善得到最终的软件系统。原型就是模型,而原型系统就是应用系统的模型。这个模型可在运行中被检查、测试和修改,直到它的性能达到用户需求为止。因而这个工作模型很快就能转换成原样的目标系统。 快速原型法主要包括两种开发方法:快速建立需求规格模型法和快速建立渐进原型法。 3快速原型法在优化AFC应用 系统中的应用统的神经中枢,它实现系统运作、收益及设备维护集中管理功能。监控并管理车站AFC系统内的所有设备,采集并上传售检票设备的交易、工作状态等信息,储存并下载运营和设置参数,具备售检票设备及运营的收益管理功能,能统计、生成及打印地铁运营日的现金收益、车站管理和票卡管理等报表,具备辅助分析功能。

软件需求确认之快速原型法

软件需求确认之快速原型法 常常听到许多朋友跟我埋怨,需求分析之难,就在于用户自身就常常弄不清楚自己的需求。起初在需求确认的时候说得好好的,一到软件上线的时候就不是那么回事了,这可没法整。但我们只要坐下来仔细分析就会发现,在需求分析的时候我们跟用户是在空对空地讨论问题。用户不是专业人士,他也搞不清楚软件到底会做成啥样,所以你跟他确认的时候他就点头了。但是,用户不是傻子,当你软件上线时,他拿到了实物了,知道软件做成啥样了,一旦不满意他就开始提变更了。所以,需求分析的症结就在与这个实物。 既然症结在此,毫无疑问,我们就应当在需求分析阶段拿出实物,用实物与用户确认需求,这就是快速原型法的基本思想。快速原型法,简称原型法(Prototyping),是20世纪80年代提出的一种从设计思想、工具、手段都全新的系统开发方法。它摒弃了那种一步步周密细致地调查分析,然后逐步整理出文字档案,设计开发,最后才能让用户看到软件结果的繁琐作法。当我们捕获了一批业务需求以后,就立即使用快速可视化工具开发出一个原型,交给用户去试用、补充和修改。再提出一些新的需求以后,再开发一版新的原型。原型法的关键就是这个快速开发。不用考虑性能、美观、可靠,原型的目的就是模拟客户的需求,与客户进行确认的。整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。 原型开发的快速与模拟到什么程度,是一对矛盾,我们要去把握。要快速开发,必然不可能和最终交付的软件系统一模一样,许多复杂问题被简化,非关键性流程被忽略,这就是所谓的模拟。因此,模拟到什么程度是关键,既能说明问题,又不耽误时间。根据我的经验,一般能拿出界面,并可以走通关键性流程就可以了。一些快速开发平台为快速原型法提供了可能。 当用户拿到原型可以自己操作时,需求研讨的气氛立即变得不太一样了。当用户享受原型给他们带来体验的快感时,需求被源源不断地被提出来。这时候的需求,就不再是枯燥无味的文字游戏,而是生动形象的图形界面。日后,如果项目采用迭代开发,让用户看着软件一点儿一点儿地成长,这又是多么美妙的体验啊。与此同时,你与用户的信任也在一步一步建立起来,软件风险在降低,项目将朝着正确方向前进。 快速原型法是美妙的,它给你与用户带来了从未有过的体验。但美妙的同时,也会带来一些的尴尬,不必要的误会,我们一定要注意。最常见的误会就是让用户将原型误以为最终交付的系统。开发一个系统需要持续数月,但你倒好,几天就搞定了,为什么还要在这个系统上投入大量资金呢?如果对方领导开始有这样的想法时,双方就开发费用进行的谈判就有一些不妙了。所以在给用户看到原型前,一定要跟用户解释清楚。 既然是原型,必要的校验、非正常操作的处理通通都被忽略。因此,当演示原型出错时,用户你可千万不要较真哟!这丑话可得说在前头,否则用户跟你较起真来,你在用户心目中的形象可就要大打折扣了。

快速原型法--资料

快速原型法--资料 “快速原型法”在项目开发中的成功案例 项目型软件的开发流程,通常会包括七个步骤:第一步:需求调研分析;第二步:概要设计;第三步:详细设计;第四步:编码;第五步:测试;第六步:软件交付准备;第七步:验收与收尾工作。 在项目型产品的开发过程中,依据软件工程思想的标准,遵循软件开发流程(Software development process)一步步的操作是最正统和最标准而且有效的做法,项目组人员的理解并落实这一点,整个项目就会朝着良性的方向发展。 狭义的项目组成员是指软件公司的人员,广义的项目组成员还应该包括客户方,对于客户来说,更关心的是结果而不是过程。由于项目组成员们的专业素养和技术水平会有差异(比如项目开发方的长处在计算机方面,而合作方在专业知识),再加上沟通不畅等因素,会给项目带来一些负面影响,比如甲乙双方对于研发成果存在争议、项目无法按期完成等等。 简单谈一下Byteh经历的一个项目情况。由于项目的专业性,摆在项目组人员的第一个问题就是理解需求其次才是后续步骤。如果严格按照软件开发的流程,必然会出现一些不可控的风险。 我方项目组果断决定采用快速原型法和敏捷开发的思想作为此次项目开发的主导,主要有以下几个措施: 1、在获取用户原始需求后迅速理解开发出一个雏形,把一个能看到的软件界面反馈给用户去探讨更进一步的需求,去更准确的把握用户需求,反复迭代。这点对甲乙双方都是有利的,当你拿着一堆文档让客户确认需求签字,从文档上看双方理解一致就签字了,然而等中期汇报做出来成果会发现简直就是南辕北辙,下次再签字肯定就会犹豫了……

下图来自网上,说明了各方理解的“需求” 和成果的差异: 2、把编码工作提到了概要设计和详细设计的前面或者并行,不等待所有的文档都完成才去进行下一步的工作。任何好的制度如果僵化,就会出现与制度目的背离的结果,请参考byteh的另一篇博文。 3、出现疑问和争议时抱着“友好合作协商解决”的态度去及时沟通,当然了也是个合作与斗争的过程,一味的满足用户需求做出承诺意味着“死亡”而且客户未必也会领你的“情”。及时,就是对无法获得与客户有效沟通地机会这个问题上不要给自己找太多理由,也许客户方企业组织的一个集体活动都会比项目重要。 尽管最终无可避免的也出现了争议和延期两个问题,但是我方把风险做到了最小化,项目中后期一直到汇报,客户都是和我们站在一起的,要知道我们公司的“背景”是最薄的~ 当时客户方是两个软件项目同期进行的,通过几次集中汇报和私底下的交流,我们了解开发方是严格按照软件的开发流程展开工作。当客户方按流程要求所有项目进行中期汇报检查时,我们公司拿出的除了文档还有一个能满足客户40%左右工作需求的软件,而另一个项目却只有厚厚的文档;当项目第一次申请延期时,我方项目组实际已经和客户落实了90%以上的需求并完成了大部分的开发工作剩余部分

需求第12章之通过原型法减少项目风险

软件工程之需求规格 第二部软件需求工程: 第十二章通过原型法减少项目风险

目录 12.1 原型是“什么”和“为什么”要原型 (4) 12.2 水平和垂直的原型 (5) 12.3 抛弃型原型或进化型原型 (7) 12.4 书面原型和电子原型 (11) 12.5 原型评价 (13) 12.6 原型法的最大风险 (14) 12.7 原型法成功的因素 (16)

第12章通过原型法减少项目风险 我最近遇到一个软件开发组,他们有一个令人不悦的经历:用户以不适合为理由拒绝了他们开发的整个产品。在产品发布之前,用户并没有见过用户界面,他们发现界面和潜在的需求都存在问题。软件原型是一种技术,你可以利用这种技术减少客户对产品不满意的风险。来自用户的早期反馈可以使开发小组正确理解需求,并知道如何最好地实现这些需求。 即使你完成了在前几章所叙述的需求获取、分析和编写规格说明,你的需求中还有一部分对客户或开发者仍然不明确或不清晰。如果不解决这些问题,那么必然在用户产品视图和开发者对于开发什么产品的理解之间存在期望差距。通过阅读文本需求或研究分析模型,很难想象软件产品在特定的环境中如何运行。原型可以使新产品实在化,为使用实例带来生机,并消除你在需求理解上的差异。比起阅读一份冗长无味的软件需求规格说明,用户通常更愿意尝试建立有趣的原型。 原型有多种含义,并且参与建立原型的人可以有不同的期望。例如,一个飞机原型实际上可以飞翔—它是真实飞机的雏形。相反,一个软件原型通常仅仅是真实系统的一部分或一个模型,并且它可能根本不能完成任何有用的事。本章

将研究各种类型的软件原型、它们在需求开发中的应用以及如何使原型成为软件开发过程中有效的组成部分( Wood and Kang1 9 9 2)。 12.1 原型是“什么”和“为什么”要原型 一个软件原型是所提出的新产品的部分实现。使用原型有三个主要目的: ?明确并完善需求原型作为一种需求工具,它初步实现所理解的系统的一部分。用户对原型的评价可以指出需求中的许多问题,在你开发真正产品之前,可以最低的费用来解决这些问题。 ?探索设计选择方案原型作为一种设计工具,用它可以探索不同的用户界面技术,使系统达到最佳的可用性,并且可以评价可能的技术方案。 ?发展为最终的产品原型作为一种构造工具,是产品最初子集的完整功能实现,通过一系列小规模的开发循环,你可以完成整个产品的开发。 建立原型的主要原因是为了解决在产品开发的早期阶段不确定的问题。利用这些不确定性来判断系统中哪一部分需要建立原型和希望从用户对原型的评价中获得什么。对于发现和解决需求中的二义性,原型也是一种很好的方法。二义性和不完整性使开发者对所开发的产品产生困惑,建立一

E1340-1996用快速原型法开发计算机化系统(中文版

E1340-1996 标准指南 用快速原型法开发计算机化系统 1范围 1.1本指南介绍了一种开发计算机化系统的方法--快速原型法。本指南的既定读者为开发计算机化系统的科技工作者和从事系统开发方法教学的教师和学生。 1.2快速原型法是开发计算机化系统的一种方法,它产生活动模型的速度要比传统方法快得多。传统方法侧重于功能要求的准备和对所需系统进行描述的功能设计文件,而快速原型法侧重于工作原型的制作。通过与一系列原型(样机)相结合,使用者和开发者可以了解功能要求和相关的系统设计,而每一原型都是从一个起始构架或从一个较早版本快速产生的。一个原型可以发展成一个功能系统,它可以充当一个可操作系统的一个严格的行为规范,它也可以用于探索一个新创意或设计的可行性,融入一个更大的系统。这种方法对原型的每个版本制作速度快,但是系统开发需要的总体时间可能比传统方法需要的时间多也可能比传统方法需要的时间少。 1.3当一个系统的功能要求或功能设计没有被很好地理解的时候,或当需要通过实验来探索系统行为的某些方面时,快速原型法是最适合的方法。快速原型法不适合于危险设置或要求能被很好理解的情况。 1.4本指南建议使用原型制作工具,但它本身不是这些工具的一个标准。本指南不包含可执行的规范化工具。将一个用于澄清要求的原型转化成一个可操作系统的问题主要在第8节讨论并在其他引用标准中细化(见 2.1)。 1.5本标准并不致力于所有与安全相关的问题,如果有,也只是关系到标准的使用。在使用前建立适当的安全卫生细则并确定法规限制条件的适用性是本标准使用者的责任。 2引用文件 2.1ASTM标准 E622计算机化系统开发指南 E625计算机化系统使用者培训指南 E627计算机化系统文件制作指南 E731市场上可买到的计算机化系统的选择和采购指南 E919计算机化系统的软件资料技术要求 E1013与计算机化系统相关的术语 E1029临床实验室计算机系统的文件记录指南 2.2ANSI标准 ANSI/MIL-STD-1815A ADA编程语言

软件项目进度计划(整理)

施工进度计划书 一、工期安排 XX工程总体工程实施,依照合同按计划在5个月内完成.工期从20xx年月初开工,至20xx年月底截止.为了保证工程圆满完成,分阶段进行进度控制,同时加强软件质量管理,以保障工程按工期规定顺利交付. 二、工程进度表 三、工程实施各环节实施方案 在明确本工程地建设目标、建设任务和范围、建设时间进度要求、

工程建设特点分析地基础上,依据招标文件地要求和我方在以往大型信息化平台建设实施方面地经验和教训,为了更好地保障工程地整体进度和整体质量,更好地回避和解决工程建设过程中地可能风险,更好地达到系统地建设目标、工程地总体目标,在本章中,针对本工程地特点,提出我们地工程建设实施整体阶段过程地划分、每个阶段要达成地目标、实施方法和实施计划. 系统建设过程主要分为需求调研/分析、系统设计、开发/测试、集成测试、培训/试运行、验收交付以及质保期七个大地建设阶段. 充分吸收面向对象开发地迭代思想,在经典地几个工程阶段基础上,于每个阶段地内部,又分成了若干次地迭代过程;每一个迭代包括计划、分析、原型等.于是工程可以递进地进展,每一个迭代周期完成,都会形成一个产品原型,通过与业主地不断交互,完善,直到原型发展成为可用地产品. 如图: 1.工程里程碑 里程碑在工程实施中通常设置在阶段任务完成点或关键任务地完成点. 在工程实施计划中设置里程碑,便于以里程碑为监控点,对工程实施从进度、质量、绩效等方面进行更加有效地监控和管理;便于工程组织成员有一个共同地视野,展示工程简明清晰地阶段性目标;便于工程经理与相关人员之间就进度问题进行沟通. 在为工程进度计划设置里程碑时,遵循以下原则:

快速原型法在项目开发中的成功案例

“快速原型法”在项目开发中的成功案例项目型软件的开发流程,通常会包括七个步骤:第一步:需求调研分析;第二步:概要设计;第三步:详细设计;第四步:编码;第五步:测试;第六步:软件交付准备;第七步:验收与收尾工作。 在项目型产品的开发过程中,依据软件工程思想的标准,遵循软件开发流程(Software development process)一步步的操作是最正统和最标准而且有效的做法,项目组人员的理解并落实这一点,整个项目就会朝着良性的方向发展。 狭义的项目组成员是指软件公司的人员,广义的项目组成员还应该包括客户方,对于客户来说,更关心的是结果而不是过程。由于项目组成员们的专业素养和技术水平会有差异(比如项目开发方的长处在计算机方面,而合作方在专业知识),再加上沟通不畅等因素,会给项目带来一些负面影响,比如甲乙双方对于研发成果存在争议、项目无法按期完成等等。 简单谈一下Byteh经历的一个项目情况。由于项目的专业性,摆在项目组人员的第一个问题就是理解需求其次才是后续步骤。如果严格按照软件开发的流程,必然会出现一些不可控的风险。 我方项目组果断决定采用快速原型法和敏捷开发的思想作为此次项目开发的主导,主要有以下几个措施: 1、在获取用户原始需求后迅速理解开发出一个雏形,把一个能看到的软件界面反馈给用户去探讨更进一步的需求,去更准确的把握用户需求,反复迭代。这点对甲乙双方都是有利的,当你拿着一堆文档

让客户确认需求签字,从文档上看双方理解一致就签字了,然而等中期汇报做出来成果会发现简直就是南辕北辙,下次再签字肯定就会犹豫了…… 下图来自网上,说明了各方理解的“需求” 和成果的差异: 2、把编码工作提到了概要设计和详细设计的前面或者并行,不等待所有的文档都完成才去进行下一步的工作。任何好的制度如果僵化,就会出现与制度目的背离的结果,请参考byteh的另一篇博文央视2.4秒门对管理的启示。

快速原型法案例

项目型软件的开发流程,通常会包括七个步骤:第一步:需求调研分析;第二步:概要设计;第三步:详细设计;第四步:编码;第五步:测试;第六步:软件交付准备;第七步:验收与收尾工作。 在项目型产品的开发过程中,依据软件工程思想的标准,遵循软件开发流程(Software development process)一步步的操作是最正统和最标准而且有效的做法,项目组人员的理解并落实这一点,整个项目就会朝着良性的方向发展。 狭义的项目组成员是指软件公司的人员,广义的项目组成员还应该包括客户方,对于客户来说,更关心的是结果而不是过程。由于项目组成员们的专业素养和技术水平会有差异(比如项目开发方的长处在计算机方面,而合作方在专业知识),再加上沟通不畅等因素,会给项目带来一些负面影响,比如甲乙双方对于研发成果存在争议、项目无法按期完成等等。

简单谈一下我们公司经历的一个项目情况。由于项目的专业性,摆在项目组人员的第一个问题就是理解需求其次才是后续步骤。如果严格按照软件开发的流程,必然会出现一些不可控的风险。 我方项目组果断决定采用快速原型法和敏捷开发的思想作为此次项目开发的主导,主要有以下几个措施: 1、在获取用户原始需求后迅速理解开发出一个雏形,把一个能看到的软件界面反馈给用户去探讨更进一步的需求,去更准确的把握用户需求,反复迭代。这点对甲乙双方都是有利的,当你拿着一堆文档让客户确认需求签字,从文档上看双方理解一致就签字了,然而等中期汇报做出来成果会发现简直就是南辕北辙,下次再签字肯定就会犹豫了…… 2、把编码工作提到了概要设计和详细设计的前面或者并行,不等待所有的文档都完成才去进行下一步的工作。任何好的制度如果僵化,就会出现与制度目的背离的结果。 3、出现疑问和争议时抱着“友好合作协商解决”的态度去及时沟通,当然了也是个合作与斗争的过程,一味的满足用户需求做出承诺意味着“死亡”而且客户未必也会领你的“情”。及时,就是对无法获得与客户有效沟通地机会这个问题上不要给自己找太多理由,也许客户方企业组织的一个集体活动都会比项目重要。 尽管最终无可避免的也出现了争议和延期两个问题,但是我方把风险做到了最小化,项目中后期一直到汇报,客户都是和我们站在一起的,要知道我们公司的“背景”是最薄的! 当时客户方是两个软件项目同期进行的,通过几次集中汇报和私底下的交流,我们了解开发方是严格按照软件的开发流程展开工作。当客户方按流程要求所有项目进行中期汇报检查时,我们公司拿出的除了文档还有一个能满足客户40%左右工作需求的软件,而另一个项目却只有厚厚的文档;当项目第一次申请延期时,我方项目组实际已经和客户落实了90%以上的需求并完成了大部分的开发工作剩余部分为了不影响验收工作也达成了双方都可以接受的解决方案,而另一个公司的项目组的需求还在变化中;当项目验收汇报近在咫尺时,我方在科室内部汇报中获得了客户方大部分的认可并可能获得优秀外协项目的评价,而另一个公司却还得继续申请延期(这一次是按

原型法开发管理办法

XXXX银行XX分行 科技产品原型法开发管理办法 第一条为了提高科技产品的需求质量、成功率和客户的满意度,特制定本办法。 第二条本办法所指原型法是指在对用户需求初步提出的基础上,以快速的方法先制作为“软件样机”,以可视化的形式展现给用户,及时征求用户意见,经过几次反复,可以达到用户与开发者之间的完全沟通,形成明确的系统定义及用户界面要求,最终确定用户需求,在此基础上,才进入下一步的开发工作。 第三条本办法适用于基于WEB开发的软件项目的开发过程管理。 第四条对原型的基本要求包括: 一、提供基本的界面风格; 二、体现主要的功能; 三、可运行的,至少在各主要功能模块之间能够建立相互连接。 第五条原型法开发的流程: 一、需求的提出 (1)参加人员:规划科或业务部门、开发组 (2)提供成果:《需求说明书》,要求:主要功能或功能要点; (3)负责人员:产品技术经理 二、软件原型的制作 (1)参加人员:开发组成员;

(2)提供成果:原型软件和《简要操作说明》,原型软件要求:提供基本界面、体现主要功能、可运行,简要操作说明,功能性测试人员能快速上手的操作要点; (3)负责人员:项目经理 三、原型的功能性测试 (1)参加人员:规划科或业务部门、开发组、其他相关成员 (2)提供成果:《测试结果反馈》,要求:根据功能测试结果,充分收集反馈意见,需求提出人员和开发组成员充分沟通和交流(3)负责人员:产品技术经理、项目经理 四、原型的修改和修改后的原型的功能性测试 (1)根据《测试结果反馈》开发组对原型进行修改,具体要求同二; (2)对修改后的原型进行再次的功能性测试,具体要求同三; (3)该过程可以反复进行,到需求提出人员和开发人员认同一致为止。 五、需求的确定 (1)参加人员:规划科或业务部门、开发组; (2)提供成果:《需求分析说明书》,要求:确定界面、功能具体说明; (3)负责人员:产品技术经理、项目经理 (4)其他要求:确定的《需求说明书》需求提出部门、产品技术经理、项目经理签字确认。

相关主题
相关文档
最新文档