2.3 原型法

2.3.1 原型法简介

原型法（Prototyping Method）是20世纪80年代随着计算机技术的发展，特别是在关系数据库系统（Relational Database System，RDBS）、第四代程序生成语言和各种系统开发生成环境产生的基础上，提出的一种从设计思想、工具、手段都全新的系统开发方法。

原型法的基本思想是在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，用最经济的方法快速地建立一个可实际运行的系统模型，然后交给用户试用，用户在使用原型系统后对其进行评价并提出改进意见，开发人员修改原型系统得到新的系统，再交给用户试用，评价修改的过程反复进行，直至用户对系统完全满意为止。原型法的核心思想是用快速建立起来的、交互式的原型取代形式的、不允许修改的大部分规格说明，通过让用户在计算机上反复试用原型系统来收集修改意见，逐步形成完善的系统。

2.3.2 原型法的开发过程

利用原型法开发系统的过程主要分为四步（如图2-13所示）：首先快速分析，弄清用户的基本需求；然后构造原型，开发初始原型系统；之后用户和系统开发人员使用并评价原型；最后系统开发人员修改并完善原型系统。

（1）确定用户的基本需求

由用户提出对新系统的基本要求，如功能、界面的基本形式、所需要的数据、应用范围、运行环境等，开发者根据这些信息估算开发该系统所需的费用，并建立简明的系统模型。

（2）构造初始原型

系统开发人员在明确了对系统基本要求和功能的基础上，依据计算机模型，以尽可能快的速度和尽可能多的开发工具来建造一个初始原型。这一步骤要尽可能使用一些软件工具和原型制造工具，以辅助系统开发。

（3）运行、评价、修改原型

初始原型建造完成后，就要交给用户立即投入试运行，各类人员对其进行试用、检查分析效果。由于构造原型中强调的是快速，省略了许多细节，一定存在不合理的部分，因此在试用中开发人员要充分和用户进行沟通，尤其是要对用户提出的不满意的地方进行认真细致的修改、完善，直至用户满意为止。

（4）形成最终的系统

如果用户和开发者对原型比较满意，则将其作为正式原型。经过双方继续进行细致的工作，把开发原型过程中的许多细节问题逐个补充、完善、求精，最后形成一个适用的系统。

2.3.3 原型法的特点

原型法贯彻“从下到上”的开发策略，符合人们认识事物的规律，容易被用户接受。系统开发循序渐进，反复修改，确保较好的用户满意度，同时由于有用户的直接参与，系统更加贴近实际，且开发周期短，费用相对少，应变能力强，因此非常适合开发处理过程明确、简单、涉及面窄的小型系统。

但是，采用原型法开发的系统要经过“修改-评价-再修改”的多次反复，缺乏规范化的文档资料，对整个开发过程的管理要求很高，不适合大型、复杂系统的开发。如果初始原型构建不合适，会影响整个开发过程，且当用户过早看到系统原型时，会误认为系统就是这个模样，易对系统失去信心。另外，对于运算量大、逻辑性较强的程序模块，原型法也很难构造出初始模型来供用户评价。

以上三种开发信息系统的方法有各自的优缺点和适用情况，表2-1对它们进行了总结对比，对于特点鲜明的系统可以准确选择适用的开发方法。应当指出，这三种方法之间也有不少交叉的内容，分类并非在同一坐标维上进行，用结构化开发方法开发系统的时候，也可能部分采用原型法；用面向对象开发方法开发系统时，也可能采用结构化分析的内容。

在电子商务系统的开发中，使用较多的是结构化开发方法和面向对象开发方法，后续的章节将结合实例重点介绍这两种方法的开发过程。对于同一个系统的开发过程来说，这两种方法在具体的操作上是有区别的：如果用结构化开发方法来开发系统，其思路应该是先对问题进行调查，然后从功能和流程的角度来分析、了解和优化问题，最后实现系统；如果用面向对象开发方法来开发系统，其思路应该是先对问题进行调查，然后从抽象对象和信息模拟的角度来分析问题，将问题按其性质和属性划分成各种不同的对象和类，确定它们之间的信息联系，最后用面向对象的软件工具实现系统。

案例2-1

用原型法改进自动售检票系统

案例背景

自动售检票（Automatic Fare Collection，AFC）系统是城市轨道交通运营的核心系统之一，是一种由计算机集中控制的自动售票、自动检票及自动收费和统计的封闭式自动化网络系统，它是基于计算机、通信、网络、自动控制等技术，可以实现轨道交通售票、检票、计费、收费、统计、清分、管理等全过程的自动化系统。AFC应用系统软件是其中最具有代表性的技术，它要集成所有售检票设备信息，还要对车票和现金等实物进行管理，涉及车站管理、收益管理和车票管理等各个环节，数据关系较为复杂，需求难以把握，开发具有一定难度，是实现AFC系统的集成的关键环节。

某市地铁AFC系统建设是在探索中进行的，对于这样一个涉及面广、层次多的庞大系统，想一步到位地满足所有需求几乎是不可能的，这就对AFC项目使用维护方面提出了更高水平的要求，要求掌握第一线乘客需求、车站运作情况等，并在目前应用系统软件所实现功能的基础上，提出AFC系统改进方向。对项目开发方而言，用户需求多变是让开发人员头疼的问题，如何快速根据用户需求改进软件并尽量满足需求，给开发增加了难度。

两年来，该市地铁AFC系统在实际使用中也暴露出了不少问题，如管理信息不完整，部分统计数据不能满足实际运营需要、系统功能无法满足要求等，造成工作效率低下、人力资源浪费和运作成本提高。

解决方案

根据该地铁AFC系统运行的实际情况，相关部门选择采用原型法进行系统的改进以解决上述问题，AFC应用系统软件的改进和完善流程如图2-14所示。

在运用原型法改进AFC应用系统软件的过程中，开发人员与用户紧密联系，快速确定需求。用户可以把实际使用系统过程中发现的问题以及需要改进的地方以书面报告的形式提出来，开发人员根据报告的描述，同用户一起讨论具体需求。开发人员在初步获取用户需求后，利用高级软件工具可视化的开发环境，快速建立一个满足用户需求的模型（构建的模型是AFC应用系统软件需要改进的一个模块），模型经测试无误后交给用户使用。用户利用一定的测试平台测试系统功能和各部件接口，在测试的过程中，可以找出问题和不满足需求的地方，并与开发者重新定义需求，该过程一直持续到用户认为该模型能成功体现系统的主要功能需求为止。用户和开发人员一起对模型进行审查，确定无误后，就可以进入车站试用。开发人员在此过程中，也可以通过用户的体验加深对用户需求的了解。最后，将测试通过的模型转变为目标系统，小规模上线使用，观察一段时间后，实际运作确定不产生其他影响后，就可以全线铺开实施。

原型法强调用户的参与，在AFC应用系统软件改进过程中，整合了地铁票务人员、车站人员的意见和思想，开发人员通过与用户的交流，获取用户的需求，以少量的代价快速构建一个可执行的模型。这个模型是一个运行着的交互式的原型系统，用户可以通过使用这个模型，获得比阅读规格说明更深刻、更感性的认识，这样加深了用户与开发人员的沟通，缩短了两者之间的距离，节省了开发时间，从而能更快地开发出满足用户需求的系统。

总结与讨论

从这个案例中可以看出，对于需求带有很大不确定性的系统的开发，可以使用原型法来获取需求，尤其是当系统规模很大、要求复杂、系统服务不清晰时，在需求分析阶段先开发一个系统原型是很有必要的。当系统的性能要求比较高时，在系统原型上先做一些试验也是很必要的。

基于该市地铁AFC应用系统软件的复杂性，使用原型法对其进行改进，效果应该是比较显著的。用户和开发人员的深入沟通和了解，能缩短两者之间的距离，需求信息反映更及时、准确，这样就使得潜在的问题能尽早发现并得到解决，增强了系统的可靠性和适用性。

结构化开发方法强调分阶段的严谨性，比较适合于那些管理基础好、管理模式定型的信息系统的开发。在实际工作中，对于大型系统的开发，可以采用原型法与结构化开发方法相结合的方式，将原型法加入到结构化开发方法中，将结构化开发方法中定义的阶段进行放大，让用户通过一个在定义阶段的小生命周期中进行体会。这种体会对于发现最终的用户需求是很有帮助和非常必要的，通过正常迭代而避免非正常的反复，当定义结束时，所有参加者都会抱有信心，产品被满意地接受，这样可以使开发系统的费用、实现的进度以及项目的风险达到更为满意的程度。

资料来源：都市快轨交通，作者略有删改。

案例思考：上述地铁AFC系统为什么选择原型法来进行系统改进？在什么情况下可以将原型法与结构化开发方法相结合来开发系统？