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

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

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

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

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

【项目背景】

随着国家教育事业的发展，很多高校纷纷引进学分制教学体制模式。我所在的学校为跟上时代的步伐，经市教委批准，从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
 

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

【存在的不足】

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

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

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

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

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

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

  【后期总结】

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

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

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

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

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

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

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

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/xxxluozhen/archive/2010/10/17/5946410.aspx