过程：

●

●

●

● 用户需求调查 《新系统初步建议方案》 《可行性分析报告》 《初步项目开发和实施规划》 输出：

2、 系统基本需求分析 输入：

●

●

●

●

●

●

●

●

●

●

● 《可行性分析报告》 《新系统初步建议方案》 对现行系统进行详细的调查与分析 确定目标系统的基本需求，包括目标系统的基本功能需求、接口需求定义、目标系统的数据需求、确定开发软件运行环境 目标系统的逻辑模型初步设计，包括总体结构和子系统描述 系统可靠性设计 目标系统的物理结构设计 制定初步测试计划 《软件需求说明书》 《项目开发计划》 《测试计划》 过程： 输出：

3、 快速建造和运行系统模型 输入：

●

●

●

●

●

●

●

●

●

●

●

●

●

●

● 《软件需求说明书》 《软件接口需求说明书》 《初步的系统设计》 制定详细设计 明确软件开发工具和支持软件 快速建造原型 模块测试 集成测试 用户手册 《软件设计说明书》 《测试用例》 《软件系统源代码清单》 《测试报告》 《操作手册》 《用户手册》 过程： 输出：

4、 评审系统模型

输入：

●

●

●

●

●

●

●

● 原型系统 演示原型系统 确认测试与评价 提出评审意见 根据评审意见，确定下一阶段内容 《软件需求说明修改意见》 《项目计划修改意见》 《评审意见》 过程： 输出：

5、 系统原型完善化

输入：

●

●

●

●

●

●

●

●

●

●

●

●

● 《软件需求说明修改意见》 《评审意见》 重新设计或补充设计 修改或完善原型 测试 评审原型系统 修改操作手册和用户手册 修改后的《软件设计说明书》 修改后的《源代码清单》 《测试结果》 《评审意见》 修改后的《操作手册》 修改后的《用户手册》 过程： 输出：

6、 结束

输入：

●

●

●

● 评审通过的系统 系统投入运行 系统维护 系统鉴定与验收 过程： 输出：

《软件bug 修改报告》 《项目开发总结报告》

原型法开发的管理办法

XXXX 银行XX 分行

科技产品原型法开发管理办法

第一条 为了提高科技产品的需求质量、成功率和客户的满意度，特制定本办法。

第二条 本办法所指原型法是指在对用户需求初步提出的基础上，以快速的方法先制作为“软件样机”，以可视化的形式展现给用户，及时征求用户意见，经过几次反复，可以达到用户与开发者之间的完全沟通，形成明确的系统定义及用户界面要求，最终确定用户需求，在此基础上，才进入下一步的开发工作。

第三条 本办法适用于基于WEB 开发的软件项目的开发过程管理。

第四条 对原型的基本要求包括：

一、 提供基本的界面风格；

二、 体现主要的功能；

三、 可运行的，至少在各主要功能模块之间能够建立相互连接。

第五条 原型法开发的流程：

一、需求的提出

（1）参加人员：规划科或业务部门、开发组

（2）提供成果：《需求说明书》，要求：主要功能或功能要点；

（3）负责人员：产品技术经理

二、软件原型的制作

（1）参加人员：开发组成员；

（2）提供成果：原型软件和《简要操作说明》，原型软件要求：提供基本界面、体现主要功能、可运行，简要操作说明，功能性测试人员能快速上手的操作要点；

（3）负责人员：项目经理

三、原型的功能性测试

（1）参加人员：规划科或业务部门、开发组、其他相关成员

（2）提供成果：《测试结果反馈》，要求：根据功能测试结果，充分收集反馈意见，需求提出人员和开发组成员充分沟通和交流

（3）负责人员：产品技术经理、项目经理

四、原型的修改和修改后的原型的功能性测试

（1）根据《测试结果反馈》开发组对原型进行修改，具体要求同二；

（2）对修改后的原型进行再次的功能性测试，具体要求同三；

（3）该过程可以反复进行，到需求提出人员和开发人员认同一致为止。

五、需求的确定

（1）参加人员：规划科或业务部门、开发组；

（2）提供成果：《需求分析说明书》，要求：确定界面、功能具体说明；

（3）负责人员：产品技术经理、项目经理

（4）其他要求：确定的《需求说明书》需求提出部门、产品技术经理、项目经理签字确认。

六、开发计划的制定

（1）参加人员：开发组成员；

（2）提供成果：《项目计划表》，要求分阶段、参加人员、时间范围，并提出总的工作量；

（3）负责人员：项目经理

（4）其他要求：项目计划表提交项目委员会审阅通过，并作为产品技术经理项目进度监管和项目考核的依据。

七、后台设计开发

（1）参加人员：开发组成员；

（2）依据：《需求分析说明书》；

（3）提供成果：完整的程序源代码和执行代码、《概要设计说明书》《详细设计说明书》、《数据库结构说明》、《用户说明书》，以上文档可以根据项目大小全部或部分提供，程序必须经过开发组内部技术测试通过；

（4）负责人员：项目经理

八、测试

（1）参加人员：规划科或业务部门、技术人员

（2）依据：《需求分析说明书》

（3）过程：测试结果反馈，开发组修改。

（4）提供成果：《测试报告》

（5）负责人员：产品技术经理或业务部门、项目经理

（6）其他说明：规划科提出的需求由规划科负责签字认可，业

务部门提出需求由也部门签字认可。 这个过程是反复过程。

九、上线试运行

（1）参加人员：规划科或业务部门、技术人员

（2）提供成果：《试运行方案》和《试运行报告》

（3）负责人员：产品技术经理或业务部门、项目经理

十、正式上线

根据需求来源确定规划科或业务部门审批上线运行。

第六条 开发组原型制作和修改结果根据原型的基本要求必须每天在网上进行公布。

第七条 项目组开发成员和产品技术经理必须每周一在网上公布自己的工作内容和进度、项目经理每周二上报项目整体进度。

第八条 原型法开发过程中，在需求确定后，提出的需求变更必须以书面形式同时提交项目经理和产品技术经理，并得到双方签字认可，并作为需求附件。

第九条 因需求变更，造成项目进度推迟超过10天以上，必须提交项目委员会审议。

第十条 对于采用原型法开发的项目工作量考核，总工作量有项目委员会核定，开发组成员由项目经理考核和核定。

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

结构化系统开发方法包括哪些步骤? 与原型法相比，有什么缺点

随着金融领域计算机应用的快速普及，软件规模越来越大，复杂程度越来越高，相应的项目风险也越来越高，尤其在管理信息系统项目面临需求不明确、性能要求比较高的情况下，仅仅依赖传统的基于瀑布模型的开发模式已无法满足实际需要。快速原型法通过构建一个含有目标系统主要特征的“软件样机”，实现产品设计的快速评价、优化改进、功能试验、性能试验，用户通过测试原型，可以亲身体会目标系统的大致功能、性能等，同时也可启发用户的思路，反馈给开发人员，使需求更台理、明确．使设计更符合应用需要。

一、选择

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 方法规划信息系统的缺点之一是，其规划的信息系统不能独立于企业的组织机构，

系统对环境变更的适应性较差。（错误）

三、问答

1．管理信息系统战略规划的作用和内容是什么？

[答] 管理信息系统的战略规划是组织关于MIS 目标及应用的长远计划和总体安排。由于MIS 的建设和应用是一项耗资大、历时长、技术复杂且涉及面广的系统工程，其规划的好坏往往是其成败的关键。MIS 战略规划的作用是：合理分配和利用信息、信息技术和信息生产者资源；促进企业信息化进程；指导工作和检查标准。MIS 战略规划的内容主要包括：系统的目标、约束和总体结构；现状（特别是业务流程）描述及重新设计；发展预测。

2．用BSP 方法进行管理信息系统规划的核心环节是什么？

[答] 定义业务流程是BSP 方法的核心。业务流程是逻辑上相关的一组决策和活动的集合，这些决策和活动是管理企业资源所需要的。整个企业的管理活动由许多业务流程所组成。识别业务流程可对企业如何完成其目标有个深刻的了解，识别业务流程可以作为信息识别构成信息系统的基础，按照业务流程所建造的管理信息系统，在企业组织变化时可以不必改变，或者说管理信息系统相对独立于组织。识别业务流程有两种方法：一种是由微观到宏观的枚举综合；另一种是由宏观到微观的分解方法。识别过程是BSP 方法成功的关键，输出应有以下文件：① 一个过程组及过程表。② 每一过程的简单说明。③ 一个关键过程的表，即识别满足目标的关键过程。④ 产品/服务过程的流程图。⑤ 系统组成员能很好了解整个企业的运营是如何管理和控制的。

3．试比较三种主要的信息系统规划方法（CSF 、SST 、BSP ）

[答] 关键成功因素（CSF ）方法能抓住主要矛盾，使目标的识别突出重点；战略目标集转化法（SST ）从各种人的要求的角度识别管理目标，比较全面；企业系统规划法（BSP ）通过定义业务流程引出系统目标，可以定义出新的系统以支持业务流程，即把企业目标转化

为系统的目标。三种方法结合起来使用，叫CSB 方法。它首先用CSF 方法确定企业目标，然后用SST 方法补充完善企业目标，并将这些目标转化为管理信息系统目标，最后用BSP 方法校核两个目标，并确定管理信息系统的结构。但这也使整个方法过于复杂，灵活性降低。

4．什么是BPR ？你认为进行BPR 的主要主要障碍主什么？

[答] 根据 Hammer 与 Champy 的定义， BPR 就是“对企业的业务流程（Process ）进行根本性（Fundamental ）再思考和彻底性（Radical ）再设计，从而获得在成本、质量、服务和速度等方面业绩的戏剧性的（Dramatic ）改善”。20世纪90年代前半期进行的一系列调查显示，尽管业务流程重组形成了世界性的浪潮，并且有许多异常成功的案例，但是仍有超过一半的业务流程重组项目走向失败或是达不到最初设定的目标，实际上，70%或更多的重组实际上使企业运营更为恶化。它们引发了困惑、拖延、怨恨和混乱。重组项目引发的危机不断，同时许多职位通常未经仔细斟酌和考虑就被取消掉，哈默成为企业缩减规模（downsizing ）的象征，尽管他本人并不情愿，重组也在中层管理人员中引起强烈反弹。这中间最大的3个障碍是：缺乏高层管理人员的支持和参与；不切实际的实施范围与期望；组织对变革的抗拒。

5．你如何理解Hammer 与 Champy 给BPR 所下定义中的“根本性”、“彻底性”和“戏剧性”的含义？

“根本性”：就是要突破原有的思维定式，打破固有的管理规范，以回归零点的新观念和思考方式，对现有流程与系统进行综合分析与统筹考虑，避免将思维局限于现有的作业流程、系统结构与知识框架中去，以取得目标流程设计的最优。“彻底性”：就是要在“根本性”思考的前提下，摆脱现有系统的束缚，对流程进行设计，从而获取管理思想的重大突破和管理方式的革命性变化。不是在以往基础上的修修补补，而是彻底性的变革，追求问题的根本解决。“戏剧性”：是指通过对流程的根本思考，找到限制企业整体绩效提高的各种环节和因素，通

过彻底性的重新设计来降低成本，节约时间，增强企业竞争力，从而使得企业的管理方式与手段、企业的整理运作效果达到一个质的飞跃，体现高效益与高回报。

6．结构化系统开发方法的基本思想是什么？该方法具有哪些特点？

结构化系统开发方法的基本思想是：用系统工程的思想和工程化的方法，按用户至上的原则，结构化、模块化，自顶向下地对系统进行分析和设计。

结构化系统开发方法具有以下特点：

● 自顶向下整体性的分析与设计和自底而上逐步实施的系统开发过程；

● 用户至上；

● 深入调查研究；

● 严格区分工作阶段；

● 充分预料可能发生的变化；

● 开发过程工程化。

此外，结构化系统开发方法还具有以下优缺点：

优点：

● 开发过程的整体性和全局性；

● 严格区分开发阶段，分工明确，避免混乱。

缺点：起点太低，周期过长，工作繁琐，不大符合人们循序渐进的认识过程。

7．什么是原型法？用原型法开发信息系统有何优缺点？

原型法一开始就凭借着系统开发人员对用户需求的理解，在强有力的软件环境支持下，给出一个实实在在的系统原型，然后与用户反复协商修改，最终形成实际系统的方法。

原型法的主要优点是：

● 开发效率高；

● 开发工具先进，与用户交流直观；

● 符合人们认识事物的规律；

● 能及早暴露系统实施后潜在的一些问题；

● 能调动用户参与的积极性。

但原型法也有以下缺点：

● 不适合大型系统的开发；

● 对原企业基础管理工作要求较高；

● 容易走上机械模拟原手工系统的轨道。

8．开发管理信息系统应遵循哪些主要的原则？

开发管理信息系统应遵循以下一些原则：领导参加原则、优化与创新原则、使用和时效原则、规范化原则、发展变化原则。

结构化开发方法与原型化开发方法(原型法)之比较分析

结构化开发方法与原型化开发方法(原型法)之比较分析

题目:结构化开发方法与原型化开发方法(原型法)之比较分析

要求:

(1)基本思想

(2)优点

(3)缺点

(4)适用场合

答案:

1、结构化系统开发方法

基本思想

在系统建立之前信息就能被充分理解。它要求严格划分开发阶段，用规范的方法与图表工具有步骤地来完成各阶段的工作，每个阶段都以规范的文档资料作为其成果，最终得到满足用户需要的系统。

优点

(1)逻辑设计与物理设计分开

(2)开发过程中形成一套规范化的文档，便于后期的修改和维护

缺点

(1)开发周期长

(2)系统难以适应环境的变化

(3)开发过程复杂繁琐

适用范围

该方法适用于一些组织相对稳定、业务处理过程规范、需求明确且在一定时期内不会发生大的变化的大型复杂系统的开发。

2、原型法

基本思想

开发人员对用户提出的问题进行总结，就系统的主要需求取得一致意见后，开发一个原型(原型是由开发人员与用户合作，共同确定系统的基本要求和主要功能，并在较短时间内开发的一个实验性的、简单易用的小型系统。原型应该是可以运行的，可以修改的。)并运行之，然后反复对原型进行修改，使之逐步完善，直到用户对系统完全满意为止。

优点

(1)需求表示清楚，用户满意度较高

(2)降低开始风险和开发成本

点

(1)原型法不适用于开发大型的信息系统

(2)系统难于维护

(3)如果用户合作不好，盲目纠错，会拖延开发进程

适用范围

(1)用户需求不清，管理及业务不稳定，需求经常变化

(2)规模小，不太复杂

(3)开发信息系统的最终用户界面

1、结构化系统开发方法(亦称“生命周期法”)

(1)优点:从系统整体出发，强调在整体优化的条件下“自上而下”地分析和设计，保证了系统的整体性和目标的一致性;遵循用户至上原则;严格区分系统开发的阶段性;每一阶段的工作成果是下一阶段的依据，便于系统开发的管理和控制;文档规范化，按工程标准建立标准化的文档资料。

(2)缺点:用户素质或系统分析员和管理者之间的沟通问题;开发周期长，难于适应环境变化;结构化程度较低的系统，在开发初期难以锁定功能要求。

(3)适用范围:主要适用于规模较大、结构化程度较高的系统的开发

2、原型法

(1)优点:符合人们认识事物的规律，系统开发循序渐进，反复修改，确保较好的用户满意度;开发周期短，费用相对少;由于有用户的直接参与，系统更加贴近实际;易学易用，减少用户的培训时间;(2)缺点:不适合大规模系统的开发;开发过程管理要求高，整个开发过程要经过“修改—评价—再修改”的多次反复;用户过早看到系统原型，误认为系统就是就是这个模样，易使用户失去信心;开发人员易将原型取代系统分析;缺乏规范化的文档资料

(3)适用范围:处理过程明确、简单系统;涉及面窄的小型系统

不适合于:大型、复杂系统，难以模拟;存在大量运算、逻辑性强的处理系统;管理基础工作不完善、处理过程不规范;大量批处理系统

3、面向对象开发方法

(1)优点:a、分析、设计中的对象和软件中的对象的一致性

b、实现软件复用，简化程序设计

c、系统易于维护

d、缩短开发周期

(2)缺点:不易于大系统的开发

原型法

原型法(Prototyping )

2010-2-25 10:15:20

1 引子

太多了!终于签下合同 -->得到了“正式”的客户提供的“需求书”的几片 纸 -->凭借自己的理解立即投入开发 -->“木已成舟”,生米终于熬成粥 -->用户 拒绝接受? -->艰难地修改,反复修改,开发人员厌倦了,而用户对系统用之无 味,弃之可惜,遂成鸡肋。 -->由此后期收款遥遥无期,软件公司不再和用户保 持沟通 -->互相埋怨,扯皮由此而生。或者,一个项目拆成为多期,从而收取一 部分款项,而很多的开发都作废。这样的案例真是何其多也!

究其主要原因, 与其说是没有搞定关键客户, 或者项目管理不当, 不如说是 没有帮助客户解决其问题, 对客户真正的需求研究不够。 实际上, 原型方法是解 决此类问题、 确保项目成功的最佳途径。 我在写此文的同时, 也试图寻找资料, 不知道是本就没有, 还是自己所不幸而未找到。 看来原型并没有明确的标准, 而 目前不同软件公司的理解和做法各不相同也就不奇怪了。 但从软件过程的角度来 考察, 原型法仍有着通用的优化的做法。 本文试图从作者的实践经验出发, 对原 型方法进行思考与探讨。

另外,本文是发散型的,在研究原型的同时,也讨论了原型相关的内容。原 型本质上有些象是抛砖引玉, 而本文也旨在抛砖引玉, 但无意于一概地论定什么。

2 什么是原型

2.1 原型的定义

原型 (prototype)即把系统主要功能和接口通过快速开发制作为“软件样 机”,以可视化的形式展现给用户,及时征求用户意见,从而明确无误地确定用 户需求。同时,原型也可用于征求内部意见,作为分析和设计的接口之一,可方 便于沟通。

2.2 原型的主要价值

原型法主要价值是可视化,强化沟通,降低风险,节省后期变更成本,提高 项目成功率。 一般来说, 采用原型法后可以改进需求质量; 虽然投入了较多先期 的时间, 但可以显著减少后期变更的时间; 原型投入的人力成本代价并不大, 但 可以节省后期成本; 对于较大型的软件来说, 原型系统可以成为开发团队的蓝图; 另外,原型通过充分和客户交流,还可以提高客户满意度。

2.3 基本要求

对原型的基本要求包括:

* 体现主要的功能;

* 提供基本的界面风格;

* 展示比较模糊的部分,以便于确认或进一步明确,防患于未然。

* 原型最好是可运行的,至少在各主要功能模块之间能够建立相互连接。 2.4 处理方法

原型的处理方法基本上有 2种不同类型, 即抛弃型和演化型 (不同的软件工 程书籍称发不同,实质意义则类似)。可以抛弃原型,在取得的明确需求基础上 重新开始设计与开发; 也可在原型的基础上继续开发。 一般小项目不采用抛弃型 原型,否则成本和代价似乎会偏高。

2.5 表达工具

原型的表达工具可以有很多, 如果是演化型的原型, 当然优先选用软件本身 的开发工具。否则还可以应用各种快速显示的工具,例如, HTML , Powerpoint 等等,只要能够充分而形象地表达就可以了。

根据笔者的经验,在原型系统中,可以采用一些与常规不同的做法,例如, 可以在界面上比较显著的地方写明当前模块或界面的主要目的,由哪些角色操 作, 能解决其什么问题。 这么做可以使得用户或开发团队成员一开始就有非常清 楚的概念;又如,对于决策分析,你可以直接把一些分析结果画成图,并且配上 一些文字说明,这样可以避免输入大量初始数据,等等。

3 原型在软件过程的地位

软件的根本目的是实现用户的需求, 提供用户日常使用, 解决用户工作中有 所不便的问题,提高其工作效率,改进质量,加强管理控制,最终直接或间接地 提高其效益。 因此软件开发本质上就是需求的处理和实现, 而软件原型对需求确 定来说具有非常重要的意义。 原型方法包括 2个基本过程, 即原型制作和原型评 价。

如果从需求角度看软件过程,我们不妨可以把软件过程这样划分:

3.1 需求收集和分析

搜集需求得到需求说明书, 了解软件要做什么, 做成什么样, 解决用户什么 问题。 这时候软件公司以书面文档方式提出,例如需求问询表等。

3.2 提供原型并进行评价

制定原型开发计划, 根据用户需求及不确定的高风险部分进行原型开发, 在 内部进行原型评价,请客户进行原型评价,以保证确实反映了用户的真正想法。

3.3 实现需求

当前的软件开发过程常常采用迭代方式进行开发, 逐步求精, 以降低风险和 成本。对迭代的次数,每次迭代的里程碑,要实现的目标,及可提交的成果必须 有可验证的清晰的计划。 项目管理是一种艺术, 迭代规划及里程碑定义都是一种 挑战、一种艺术,但项目管理不在本文讨论范围。

3.4 需求变更

需求变更是正常的, 也是难免的, 应允许用户和开发团队自身对需求进行变 更。 变更处理的关键在于跟踪和控制, 如何使产生的影响应得到控制, 这属于配 置管理的内容,也不在本文讨论范围。

原型在软件过程中的定位如下图所示:

图 1 软件原型的定位

实际上我们可以把原型看得更为广义一些。任何用户或者内部演示的材料, 都可以看作为原型。 例如, 如果你的产品是某种通用的或者行业解决方案, 虽然 你其实还没有产品, 但先做出一个原型, 再加一个漂亮的白皮书, 就可以在市场 上进行预销售了。

对于抛弃型和演化型原型来说, 也不是绝对的。 演化型原型中必然会不断抛 弃一些内容, 而抛弃型原型, 尽管在完成历史使命后不再使用, 但很多思想以及 部分设计还是可以继承的。

4 原型方法的一般过程

基于原型方法在整个需求过程中的地位, 我们需要把原型法和需求处理放在 一起进行讨论。采用原型法的一般过程如下图所示:

图 2:原型法的处理过程

在上图中已经清楚地描述了原型的处理过程, 值得一提的是, 原型不仅用于 给用户或者最终用户进行评议, 同时完全可以在公司内部组织评议, 看看我们周 围吧, 多数程序员对技术的兴趣远远高于对需求的兴趣, 因此其对系统的理解并 不会比市场人员或者项目经理理解的深多少。 这里的公司内部人员角色可以包括 很多,系统分析员 /程序员自身、项目经理、部门经理、用户代表、领域专家、 测试人员等等,不同的角色往往会在其不同立场对系统提出中肯的意见来。

另外值得注意的是界面设计的引入。 我们认为将界面风格在原型阶段即进行 基本确定是一种优化的做法, 因为软件前期对界面的确定可以避免后期开发时对 界面进行统一调整所带来的不必要的成本花费, 良好的界面也可以使客户增加对 系统的好感, 当然, 但愿用户不要只是欣赏界面而忽略了他们对系统功能的思考。 要知道,如果仅仅是让用户看到美观的界面,那么整个原型几乎是白做了。

5 使用原型方法的相关问题探讨

5.1 为什么要采用原型法?

原型对一个项目取得成功具有重要的意义。 俗话说:隔行如隔山, 实际上软 件公司很难保证其制作的软件正好就是用户所需要的, 用户也很难一次性把其真

实的要求完全提交, 开始阶段提出的往往只是对系统的期望, 和比较模糊的设想 而已。 而原型系统为用户提供了一个靶子, 看着原型系统, 用户往往就能进一步 提出他们的真正想法。 显然软件公司明确用户需求的最佳方式就是为用户提供原 型并由用户进行评价。

也许, 跳过原型可以节省时间和前期成本, 但你应该注意到, 跳过原型的话, 后期变更的成本会明显增加。

5.2 为什么在需求说明书之外需要原型?

1)眼见为实,文字具有歧义性,不同的人理解都不相同;

2)最终用户往往在看到一套可运行的系统的基础上,才可能提出其真实的 意见, 如果到最终提交时才看到这样的系统就为时太晚。 这也是以前无数软件开 发留下的教训;

3)便于发现问题,及时纠正;

4)便于进一步展开,并取得用户的细节需求;

5) 体现原型的其它功能:便于公司内部如经理、 市场部等对软件提出意见, 便于开发人员对整个产品达成统一认识,等等。对内部人员来说,同样地,一套 形象的原型也远胜过一堆专业术语文字; 也就是说, 原型对软件公司内部也十分 重要。这些评价工作无形之中改进了项目质量。

5.3 原型方法有什么风险?

任何方法都是有利有弊, 在我们可以探讨一下原型方法可能存在的风险。 以 下是一般软件公司所担心的风险:需要付出前期进度和人力成本; 由于程序员对 问题的不了解而效率低下, 受客户牵制而在原型上反复修改; 因为仓促设计而做 不利于进一步在其基础上继续开发; 由于过早展示原型给客户, 使得客户可能提 高其期望值,并提出更多离谱的要求,等等。

值得一提的是原型方法的主要价值之一就是尽早揭示软件中可能存在的风 险及不确定因素,尤其是关于用户需求一致性方面的风险。

5.4 原型方法和其它方法或过程的关系如何,是否一致?

生命周期法中并不包括原型, 或者说没有明确提供原型的概念和定义。 原型 可以认为是需求分析中的一个子部分。 另外, 应该说原型方法是对生命周期法的 有益补充和完善。

RUP 中是最优化的统一软件过程,但 RUP 中似乎没有提到原型, RUP 的核心 过程是在迭代中精化。 我个人的见解是, 原型非常类似于第一次迭代的过程和结

果。实际上,如果把原型看作为第一轮交付的成果,那么原型的很多不利之处, 诸如花费前期成本等等,这些担心都将变得不复存在。

XP 方法对原型非常推崇,这是因为 XP 方法非常强调需求的重要性,甚至要 求客户参与开发过程。但原型方法和 XP 也有区别。 XP 是分批交付,先做一个几 个功能点的版本, 完成后再每个开发周期往上面加其它功能点, 而原型法一般要 求做出比较完整,能覆盖主要功能点的粗略的版本。 XP 方法仁者见仁,智者见 智,不一而举。

5.5 如何避免项目团队做原型的时候出现部分人员闲置?

在项目管理中, 对人力资源的调配应和项目进展相匹配。 实际上在用户接触 到原型制作的同时, 可以进行项目计划、 架构设计、 技术培训以及技术难点攻关 等等。

如果从广义上理解原型的话, 架构设计者甚至可以设计出一种用户开发团队 使用的所谓框架原型,包含了主要的设计成分、模板和示例。

比较理想的结果是, 当原型完成后, 需求分析、 架构设计和界面风格设计都 趋于完成,从这一点可以看到,原型方法可以作为快速软件开发的重要手段。

5.6 如果避免项目在原型上停滞不前?

应使用有经验的开发人员, 避免因为程序员不熟悉业务而延误进度; 不要在 界面设计上犹豫不决而占据时间; 如果用户对原型提出了很多意见, 其中部分比 较明确的意见可以在开发过程中进行实现; 和客户的交流应该简洁明了, 而不是 似是而非; 另外, 原型方法在项目过程中占据的时间应该在项目计划中保留出来, 而不仅仅是隐含在需求调研与分析的一个部分。

5.7 如何避免用户看了原型后漫无边际地提要求?

首先, 应该充分尊重客户, 想想其它行业的服务质量吧。 有没有听说过这样 的说法,项目管理也是客户满意度的管理;软件是一种对客户的关怀,等等。确 实, 客户提出的思路可能和你已经形成的思路不同, 一下子打乱了你的思路, 也 许项目经理并不介意, 但这确是让设计者特别心烦的事情。 如果确有把握, 或者 你可以不做到原型中去。 有时候, 即使原型很完美, 用户也会额外地提出一些意 见,这也是人之常情。但不管怎样,你不能认为用户根本不懂软件,让他们到时 用就行了,抱这样想法的多半会付出代价。 其次应该进行坦诚协商,多数用户 其实都是通情达理的。 如果你在签订合同时答应满足任何要求, 而此时又无法忍 受用户的要求, 那么孰是孰非应是题外之意了。 一般来说, 比较合理的做法可以 通过增加费用、延长进度或者把需求实现分阶段来提交,以保持工作的延续性。 对有些软件, 尤其是信息管理系统来说, 客户的实施时间其实并不是主要的, 客 户最需要的不是及时,而是合用。

其实,客户有着很多种类型,确实,个别客户会参考同类产品来提要求,极

个别用户并不真正懂得计算机技术而对技术路线、 技术手段等提出其意见, 等等。 但我们为什么还可以反过来想一下, 如果是等到软件全部提交的时候, 这部分用 户仍有会提出同样的意见。 提早暴露并解决分歧, 对双方睹是有利的。 如果软件 公司明知可能存在矛盾, 仍然先做好, 然后等到用户提出反对后, 再提出补充收 费,如果喜欢,也无话可说。 总之,原型应本着对软件需求的基本理解来做, 这样才能预防不一致性的发生。 尤其应该针对不清楚的地方制作原型, 从而尽量 暴露问题,引发用户的联想,不能回避问题,掩盖问题(以免用户提出太多的想 法),很多问题虽然一时掩盖了,但最终还是要发生的。

5.8 如何避免在原型基础上继续开发时的可维护性降低?

问题是这样的, 制作原型时常希望快速提供原型, 往往不及对软件结构或者 数据库进行细致设计。 所以在此基础上继续设计和开发的话, 有必要在开发前先 进行调整。同时,在设计原型前就有必要确定,该原型是要抛弃的,还是要演化 要继承的。 对于要演化的原型, 其设计不能过于粗略, 显然这直接影响到今后的 开发成本。

6 小结

原型方法是可视化的方法, 已成为快速软件开发常用的手段。 软件公司或部 门一旦得到了原型方法的回报, 就会坚持使用。 原型不是绝对必要, 但非常有意 义。

转载请注明出处范文大全网 » 原型法开发过程框架