快速原型开发模式在实际开发过程中的应用

【摘要】本文以作者的实践开发经验为主线,从理论和实际的角度探讨快速原型开发模式在实践开发中的应用,并从软件开发的各个角度、各个时期剖析快速开发模式的优缺点和应该注意的问题。

【关键字】软件工程、开发模式、快速开发、软件开发、原型模式

    快速原型开发模式的基本思想是在系统开发的初期,在对用户需求初步了解的基础之上,以快速的方法先构造一个可以工作的系统原型。将这个原型提供给用户使用,听取他们的意见。然后修正原型,补充新的数据、数据结构和应用模型,形成新的原型。经过几次迭代以后,可以达到用户与开发者之间的完美沟通,消除各种误解,形成明确的系统定义以及用户界面要求。

了解快速原型开发模式后,下面结合我开发过学分制收费管理系统项目经验来谈一下我是如何在实际开发过程中实施快速原型开发模式。

【项目背景】

随着国家教育事业的发展,很多高校纷纷引进学分制教学体制模式。我所在的学校为跟上时代的步伐,经市教委批准,从2008-2009学年试行学分制改革,2009-2010正式运行。以传统的教学模式相比学分制教学模式有很多明显的优势,学生的自由度也得到了很大的提高。然而一种新的教学模式要取代传统的教学模式,势必会存在很多麻烦和问题。其中学分制教学模式下的收费方式与传统的收费方式就存在很大的差异,任然沿用传统的收费方式已经无法满足学分制改革的要求,因此为推动学分制改革,制定一套符合学分制教学要求的收费管理系统势在必行。有幸这个项目由我们团队负责开发。

然而事情远没有想象那么简单,学分制改革是学校的大事情,需要财务处、教务处、学工部等行政部门的支持和各二级学院的配合。学分制收费更是与各个部门、学院和学生兮兮相关。试分析可以发现:待制定的学分制收费管理系统必须做到把财务处的各项收费标准信息、教务处的学生选课信息和学工部的助学贷款、缓缴学费、参军等学生信息紧密的糅合起来,并计算出学生预缴费用。由于涉及到的部门比较多,各部门领导又并不具备专业的软件知识,提出的需求并不明确或则是根本无法系统化。如果采用瀑布模式或则是演变模式进行开发,显然会存在着很大的风险,介于此、经项目组研讨决定采用快速原型开发模式进行项目开发。

【具体实施】

㈠      开发工具选择

 经项目研讨后我们决定选择.NET平台采用ASP.NET+AJAX+SQL SERVER2000技术进行开发。主要原因是.NET平台具有一下优势:

⑴、技术领先  

  .Net技术于2001年由微软公司推出,与Java构成当前最主流的开发平台,.Net对XML、Web Service、AJAX提供很好的支持,而且,提供了更为便捷的开发、调试、部署环境,同时,与微软的BizTalk、Office、SQL Server2000等系统可以无缝衔接。  

  ⑵、安全性  

  .Net是构建于操作系统之上的虚拟平台,提供了更为强健的安全系统。在系统当中,提供集成Windows验证、基于角色的权限管理机制、SSL传输加密、MD5数据加密等多种安全手段,以提高系统的安全性。  

 ⑶、稳定性  

  作为24*7运行的系统,除了提供良好的性能之外,系统的稳定性也非常重要,系统采用如下方法提高系统性能及稳定性:  

    ①Web服务器采用Windows 2003+IIS6     

    ②模板系统:更新不频繁的数据使用模板系统生成静态页面,减少数据库压力  

    ③站点缓冲:频繁更新的数据,使用缓冲以提高访问速度,减少数据库压力  

    ④系统日志:再好的设计都会有bug,系统日志记录程序运行过程中产生的异常,以方便调试系统,发现潜在的bug   

  ⑷、扩展性  

  采集4层结构,分为数据访问层、业务逻辑层、业务外观层、表现层,各层之间严格遵守"高内聚、低耦合"原则,使系统具备较好的扩展性。  

  数据访问层:完成基本的CRUD(Create/Read/Update/Delete)操作。  

  业务逻辑层:完成各种业务规则和逻辑的实现,调用数据访问层完成CRUD操作。  

  业务外观层:为表示层提供统一的访问接口,分离界面和具体的业务功能。  

  表示层:分为B/S和C/S两中表现形式(暂时只实现了B/S一种模式)。  

  多层分布式设计,当业务和访问量增大时,可以在中间层部署更多的应用服务器,前端部署更多的Web服务器,提高对客户端的响应,而所有的变化对客户端是透明的。

 项目组成员以及分工

我们项目组由一个项目负责人、一个测试工程师、一个文档管理员、三个编码员(其中一个软件设计师和两个程序员)。具体分工如下表:


成员


任务


输出文档


项目负责人


需求采集、控制进度、协调用户关系


学分制收费研究报告


测试工程师


集成测试、总体测试


测试报告


文档管理员


编写用户手册、编写操作手册、软件服务制定


用户手册、操作手册

软件服务说明书


编码员


软件设计师:需求分析、数据库设计、软件架构、核心代码编写、配合集成测试和总体设计、任务划分、编码质量控制


需求分析报告、系统设计书、详细设计、软件规范说明书


其他两个编码员:单元代码的编码、单元测试

       

很荣幸我担任的是软件设计师的职务,在此感谢项目组对我的信任。另外在项目研讨的时候,根据项目开发时间紧迫、需求不好把握、需不断的构造软件原型等特点,我们打破常规,将原本属于编码员完成的集成测试任务全部划分给了测试工程师,测试工程师也只需将每次测试结果当做一种需求的方式返回给我们,我们再根据返回的需求微调程序,微调后的程序就基本上能满足要求。但这样做有个很大的前提就是测试工程师要对需求相当成熟。

①项目负责人通过与各部门领导沟通和软件演示的方式来采集用户需求。                               

工作流程以时间安排

        项目负责人通过与各部门领导的沟通和实际调查,初步确定了软件需求,并提交学分制收费研究报告,同时把软件的核心功能定位于“计算学生的预缴费用,并将这些数据提供给财务收费系统(以.XLS文件导入、导出)”。随后经各部门领导协商,定于4.20日正式提交软件,如果软件能满足要求则立即投入使用。时间很紧迫,为保证第二次原型开发具有充足的时间,经项目组讨论决定制定了以下的工作安排。

项目名称:学分制收费管理系统       任务安排表


任务代码 / 名称


交付的文档


人员


计划


开始


结束


工期(天)


学分制收费管理系统


 


 


2009.2.9


2009.4.19


69


 T1 确定初步需求


学分制收费研究报告


项目负责人


2009.2.14


2009.2.28


14


 T2 项目研讨会


 


项目组成员


2009.2.28


2009.3.1


1


 T3系统设计


需求分析、系统设计、详细设计、系统规范说明


软件设计师


2009.3.2


2009.3.9


7


 T4第一次原型构建


 


编码员


2009.2.9


2009.2.16


7


 T5集成测试


测试报告


测试工程师


2009.3.16


2009.3.17


1


 T6程序微调


 


编码员


2009.3.17


2009.3.18


1


 T7软件演示


需求分析报告


项目负责人


2009.4.18


2009.4.19


1


 T8项目研讨会


 


项目组全体成员


2009.3.19


2009.3.20


1


 T9需求调整


 


软件设计师


2009.3.20


2009.3.21


1


T10第二次原型构建


 


编码员


2009.3.21


2009.4.4


14


T11集成测试


测试报告


测试工程师


2009.4.4


2009.4.5


1


 T12程序微调


 


编码员


2009.4.5


2009.4.6


1


 T13第二次演示


需求分析报告


项目负责人


2009.4.6


2009.4.7


1


 T14项目研讨


 


项目组全体成员


2009.4.8


2009.4.9


1


 T15软件完善


 


编码员


2009.4.9


2009.4.14


5


 T16集成测试


测试报告


测试工程师


2009.4.14


2009.4.15


1


 T17程序微调


 


编码员


2009.4.15


2009.4.16


1


 T18总体测试


测试报告


测试工程师


2009.4.16


2009.4.18


2


 T19测试微调


 


编码员


2009.4.18


2009.4.19


1


 T20文档整理


用户手册、操作手册、软件服务说明书


文档员


2009.3.22


2009.4.12


21


 T21软件提交


 


项目负责人


2009.4.19


2009.4.20


1

在具体的实施的工程当中,我们依照任务安排表严格执行,经过两个多月的开发,学分制收费管理系统终于完成,并在第二次软件演示的时候得到了各部门领导的一致好评。

【存在的不足】

虽然开发的系统得到了各部门领导的好评,但在整个开发工程当中仍然存在很多不足。我总结了主要有以下几点:

①某些关键的细节在最开始就被忽略,这导致了后期为弥补这个细节花费了大量的时间,同时影响了队员的信心。

②程序员经验不足,对需求的理解能力稍差,有时候开发出来的某些复杂的模块根本不能满足要求,这无形中增加了需求沟通和程序修改的时间。

③对捕捉程度不够清晰,有时候需求过大,需要的开发时间较长,很难在预定时间内完成,只得加班加点。但有时需求较少,需要的开发时间较少,预先安排的时间有空余。这种情况使得程序员作息正常的作息时间被打乱,虽然开发进度能被很好的把握,但其实开发效率并不高。

 ④第一次原型开发初期,由于时间比较紧,对编码质量没有进行很好的控制,这导致后期的开发当中常常出现一些莫名其妙的错误(比如某个模块运行时间过长)。

⊕数据表中的某一个字段不清楚到底该如何处理时将其忽略。

  【后期总结】

虽然在开发的过程当中存在一些不足,但我仍然学到了很多东西,同时也第一次正真的体验了快速原型开发模式在实践当中的应用,这次的经验在我今后的工作当中也都将产生深远的影响。在项目结束时,关于快速原型开发模式在实践当中的应用,我总结以下几点值得参考性的意见。

①在选择项目组成员时,应该本着“少而精”的原则。

②在软件开发之前,必须提出核心需求,进而确定软件的核心功能。

③在软件开发之前,对开发需时进行认真评估,制定一张符合实际的任务安排表,保证队员正常作息时间。

④在软件开发的过程当中,应严格控制原型的构建次数(建议只构建三次),一般在第一次软件演示后就应该基本确定用户需求,第二次软件演示的时就应该基本满足用户需求,第三次软件演示后再通过一些细节方面的修改就可以交付。

⑤对于某些暂时模糊的关键性细节应予以认真记录和分析,影响力大、需及时解决的细节必须及时解决,暂时不忙解决的应将涉及到这个细节的所有功能模块放在下一次原型构造时才进行开发与解决。

⑥如果开发时间很紧迫,测试工程师应跟踪测试,确保测试与开发同步。

时间: 2024-10-31 09:38:18

快速原型开发模式在实际开发过程中的应用的相关文章

不错的一篇面向对象的PHP开发模式(简写版)_php技巧

我看到有人在批判PHP,什么这地方不好用,那地方不好用的.其实严格地说起来,没有一门语言好用,也没有一门语言有一个严格的标准,凡事都有一个发展的过程,我们总不能等这些标准呀什么的都很完善了再用吧?我觉得不管用什么语言,写程序都要靠自己,一个程序员要有好的风格,思路等等.最近我在整理一些资料,现在发出一些,希望大家多提意见,多多扶持啊哈 ====================================== 面向对象的PHP开发模式(待完善中...) ====================

垂直化开发模式在支付宝无线测试平台建设中的实践

摘要:支付宝无线统一测试平台承载着整个支付宝无线应用研发的质量控制体系,提供字节码测试.monkey测试.遍历测试.UI自动化测试.适配测试.设备管理.真机访问.性能监测.安全扫描等. 一.引言 无线应用的浪潮已经掀起,无线测试质量保障体系的建立步伐步步紧逼,在这样的背景下,支付宝无线统一测试平台应运而生,结合支付宝无线应用的特性,定制开发一套统一无线测试平台迫在眉睫,本平台主要涵盖monkey测试.遍历测试.UI自动化测试.适配测试.设备管理.真机访问.性能监测.安全扫描等,研发团队采取垂直化

移动应用开发过程中的迭代式原型设计

主要结论 移动应用原型创建过程中采用迭代式快速开发方法的重要性. 可以从对手身上学到什么,如何从他们的失误中获益. 如何为你的应用定义USP,如何通过故事板(Storyboarding).用户场景和故事图(Story-mapping)为自己挑选出最理想的用户. 如何使用纸面原型匹配团队的预期,并专注于共享的最终交付成果. 如何使用原型工具收集.管理和验证需求,进而在无需进行太多文案工作的情况下让产品解决方案具象化. 根据Yahoo Flurry提供的数据,消费者使用手机的时间中有超过90%用于各

Android应用中MVP开发模式

所谓MVP(Model-View-Presenter)模式.是将APP的结构分为三层: view - UI显示层 view 层主要负责: 提供UI交互 在presenter的控制下修改UI. 将业务事件交由presenter处理.注意. View层不存储数据,不与Model层交互. presenter - 逻辑处理层 presenter 层主要负责: 对UI的各种业务事件进行相应处理.也许是与Model层交互,也许自己进行一些计算,也许控制后台Task,Servic 对各种订阅事件进行响应,修改

微信公众平台快速上手教程Part5 开发模式讲解

中介交易 SEO诊断 淘宝客 云主机 技术大厅 这部分主要讲解微信公众平台的开发模式,首先说明一下我不是程序员,所以本篇并非讲编程代码之类的,也并非开发模式的说明书,毕竟微信官方已经有一份详细的技术说明文档(在文章尾部提供文档地址),但是由于我们正在开发微信POP营销系统,所以我对开发模式有一定了解,这些了解应该会对准备尝试做微信开发的朋友会有一定帮助,少走部分弯路吧.如果对本篇教程有任何疑问或错漏之处欢迎留言或直接联系我进行更正修改. 首先我们要明确开发模式什么可以做,什么不可以做: 一.开发

理解javascript中的MVVM开发模式

          MVVM的全称是Model View ViewModel,这种架构模式最初是由微软的MartinFowler作为微软软件的展现层设计模式的规范提出,它是MVC模式的衍生物,MVVM模式的关注点在能够支持事件驱动的UI开发平台,例如HTML5,[2][3] WindowsPresentation Foundation (WPF), Silverlight 和 t ZK framework,Adobe Flex.           对这种模式的实现,大部分都是通过在view层声

C#中 使用CodeFirst开发模式有什么好处,和先建数据库有什么区别

问题描述 C#中 使用CodeFirst开发模式有什么好处,和先建数据库有什么区别 C#中 使用**CodeFirst**开发模式有什么好处,和先建数据库有什么区别 解决方案 谈不上什么好处坏处,萝卜白菜各有所爱,你能说萝卜比白菜好在哪里,萝卜白菜有什么区别么? 如果你感受不到codefirst的好处,那说明对于你来说,codefirst没有好处.这很正常.就像有些开发者偏好于通过代码来进行领域建模而不是数据库他们觉得cf比通过数据库建模要好一样.这只是一种偏好(perference),

后端开发-在开发过程中,用List<Map>好,还是List<POJO>好?

问题描述 在开发过程中,用List<Map>好,还是List<POJO>好? 或者说这两者的分别适用在不同的地方~ 或者说这两者的分别适用在不同的地方~ 解决方案 List> 优点: 省略了POJO类,返回字段不受POJO类的限制了. 缺点: 看起来不明朗,没有文档的话根本不知道MAP里面有什么属性. List 优点: 从类名就可以知道是什么类型的数据,方面代码里面操作属性. 缺点: 需要写POJO类,并且维护字段的增减. 不过通常情况还是会使用List. 解决方案二: 一半

软件开发模式

        软件的开发模式包括:大棒开发法.边写边改法.瀑布法.快速原型法和螺旋模式法,它们的定义及特点如下: 第一,大棒开发法.        它是源于能量爆发创造宇宙,万物都由能量和物质积聚而成的理论,但如果不是遵循某种正确的排列和组合,形成的将不是预先期望的事物:大棒模式与上述理论一样:一大堆能量(这里指开发软件所需的人力和物力)放在一起,巨大的能量进行释放,通常的结果可能是产生了优秀的软件产品或成为一堆"废品"(不成功的软件).其优点为:思路简单,通常可能是开发者的&quo