第四章节常用系统开发方法

　第四章

　常用系统开发方法

　 信息系统的开发是一个庞大的系统工程，它涉及到组织的内部结构、管理模式、生产加工、经营管理过程、数据的收集与处理过程、计算机硬件系统的管理与应用、软件系统的开发等各个方面。这就增大了开发一个信息系统的工程规模和难度，需要研究出科学的开发方法和过程化的开发步骤，以确保整个开发过程能够顺利进行。这正是信息系统开发方法的任务。

　信息系统开发方法学研究的主要对象是信息系统开发的规律、开发过程的认知体系、分析设计的一般理论以及具体的开发工具和技术等。

　本章拟从方法论的角度，介绍创建 MIS 所需的规划方法,包括结构化开发和设计方法（SSA&D），面向对象的开发方法（OO），原型方法（Phototyping）及 CASE 方法。

　本章重点 本章小节

　本章难点

　系统开发的过程、常用方法，SSA&D、原型法、面向对象方法等系统开发方法分类

　结构化分析与设计方法

　各种开发方法基本思想的理解、特点及适用范围，面向对象(Oriented

　基本思想、开发过程、特点及其优缺点，各种方法比较

　原型方法

　面对对象开发方法

　计算机辅助开发方法

　各种开发方法比较

　本章小结

　习题四

　Object)方法的有关基本概念及开发过程

　§4.1 系统开发方法的分类

　一、系统开发过程的管理

　 系统开发过程是用于管理和维护信息系统和软件的一系列活动、方法和工具，这些活动、方法和工具有：

　IT 项目管理，软件产品的质量管理、开发方法选择等。关于 IT 项目的管理可以参考有关的文献，本课件不再详细论述。这里着重介绍如何衡量计算机软件产品质量的方法，即一个称为"软件能力成熟度"的模型，它是提高信息系统软件产品质量的一种重要的框架，通过这种模型来加强计算机软件系统的开发过程管理，以提高软件的开发质量，该模型又称能力成熟度模型，英文写成 Capability Maturity Model, 简称 CMM。

　 能力成熟度模型 CMM 提供了一个系统过程改进框架，该框架与软件生命周期无关，与所采用的开发技术也无关。根据这个框架制定企业内部具体的系统开发过程，可以极大程度地提高按计划的时间和成本提交有质量保证的系统产品的能力。

　CMM 认为保证系统质量的根本途径就是提升企业的系统开发生产能力，而企业的系统开发生产能力又取决于企业的系统开发过程能力，特别是在系统开发和生产中的成熟度。企业的系统开发过程能力越成熟，其系统生产能力就越有保证。

　 所谓系统开发过程能力，是指企业从事系统产品开发和生产过程本身透明化、规范化、和运行强制化。企业在执行系统开发过程中可能会反映出原定过程的某些缺陷，这时可以根据反映的问题来改善这个过程。周而复始，这个过程逐渐完善、成熟。这样一来，项目的执行不再是一个黑盒，企业可以清楚地知道项目是按照规定的过程进行的。系统开发及生产过程中成功和失败的经验教训也就能够成为今后可以借鉴和吸取的营养，从而可以大大促进信息系统生产的成熟度的提高。

　 CMM 模型描述和分析了系统开发过程能力的发展程度，确立了一个系统开发过程能力成熟度的分级标准，如图 4-1-1 所示。随着能力成熟度逐步提高，企业的竞争力也在不断地提高，系统开发的风险则逐步下降，系统产品的质量稳步上升。

　 图 4-1-1 能力成熟程度的分级标准

　 在 CMM 中等级的特征为：

　 初始级：系统开发过程的特点是无序的，有时甚至是混乱的。系统开发过程定义处于几乎毫无章法和步骤可循的状态，系统产品所取得的成功往往依赖于极个别人的努力和机会。

　 可重复级：已经建立了基本的项目管理过程，这些过程可以用于对成本、进度和功能特性进行跟踪。对于类似的工程项目，有章可循并能重复以取得成功的经验。

　 已定义级：用于管理的和工程的系统开发过程均已文档化、标准化，并形成了整个系统开发组织的标准系统开发过程。全部项目均采用与实际情况相吻合的、适当修改后的标准系统的开发过程来进行操作。

　 可管理级：系统开发过程和产品质量有详细的度量标准。系统开发过程和产品质量得到了定量的认识和控制。

　 优化级：通过对来自系统开发过程、新概念和新技术等方面的各种有用信息的定量信息，能够不断地、持续性地对系统过程进行改造。

　CMM 以具体实践为基础，是一个系统开发实践的纲要，以逐步演进的框架形态不断地完善系统开发和维护过程，成为软件企业变革的内在原动力，与静态的质量管理标准-例如ISO9001等，形成了鲜明的对比。ISO 9001 标准在提供一个良好的体系结构与实施基础方面能够很有效，而 CMM 是一个演进的、有动态尺度的标准，可以驱使企业在当前的系统开发实践中不断地改进和完善。

　 CMM 作为一个指南能够帮助企业选择、采纳和合理使用一些先进的管理方法，并在实践活动中不断提高和完善系统开发成熟度的能力。围绕这些实践活动逐步形成了一套制度，即在指定的成本和时间内，交付提高质量的软件产品所需要的、有纪律的、精确定义的并能有效度量的软件工程过程。

　 二、系统开发方法概述

　 管理信息系统的开发是一项复杂的系统工程工作。它涉及的知识面广、部门多。至今还没有一种完全有效的方法来很好的完成系统的开发。但也确有一些方法在系统开发很有帮助，这里就此进行一些介绍。

　 从 20 世纪 60 年代开始，人们已开始注意信息系统开发的方法和工具。70 年代，系统开发的生命周期（Life Cycle）法较好的给出了过程的定义，改善了开发的过程。然而，问题的累积，性能的缺陷，加深了系统开发的困难，80 年代以后，友好的语言和自动化编程工具的出现，使开发方法又有些进步，但维护费用很高。90 年代利用模

　块化和模块联接技术，大大降低了维护成本，提高了效率。90 年代中期，由于 Web 技术的出现，许多工作可以由用户去做，但系统工作仍然很多。下面我们根据时代的特点，介绍系统开发方法的演变。

　 1. 70 年代

　 以前系统开发工作好像在做手工艺品。编出各种各样的程序，程序难写、难懂，更难以维护。因而标准化成为用户和开发公司的愿望。当时的开发环境是：

　 · 第三代语言（如 COBOL）用于编程。

　 · 已有数据库管理系统，用于数据管理。

　 · 联机处理和批处理混合使用。

　 · 主要针对主干机开发。

　 · 只由专业程序员进行程序开发。

　 · 利用标准符号来说明过程。

　 · 用户只在定义需求阶段和安装阶段介入开发。

　 · 企图用结构化的程序设计方法和自动化的项目管理。

　这时系统开发方法依据著名的“瀑布模型”，见图 4-1-2。

　 图 4-1-2 瀑布模型

　结构化的意思是企图使开发工作标准化。结构化开发的目标是有序、高效、高可靠性和少错误。有序是按部就班，相同情况得出相同结构，达到标准化。结构化还要求建立标准的文档。当然结构化有其负面的影响，它可能妨碍程序员的创造性。但对一个大系统来说，只有纪律才能维持高的生产率。在每个开发阶段，加强检查是提高可靠性、减少错误的主要方法。

　 在 70 年代后期，人们开始强调“初期阶段”的重要性。差错产生得越早，纠正所花的成本越高。也就是说，纠正差错越早所花成本越低。为了较早的发现错误，当时方法主要有两种，一种是数据驱动开发，另一种是合作开发，这在当时起到一定作用。

　2.

　80 年代

　 80 年代初一些开发环境逐渐成熟，如第四代语言（4GL）。这使得有可能使用原型法（prototyping）。原型法和生命周期法是两种思路完全不同的方法。生命周期法企图在动手开发前，完全定义好需求，然后经过分析、设计、编程和实施，一次全面的完成目标；原型法则相反，在未定义好全局前，先实现局部，然后不断修改，最终实现全面满足要求。两种方法实现的最终系统应当是同功能的，但它们实现的途径却是完全不同的。一种是单次的，一种是多重循环的。

　 4GL 是一种面向问题的语言。它不只是一种语言，而且包含一种环境，这种环境包括：关系数据库系统、数据字典、非过程语言、交互查询机构、报告生成器、排序和选序处理和文本编辑、图形处理、数据分析和模型工具、宏命令库、程序界面、复用程序、软件库、支持和恢复、安全和保密以及与其它数据库的联系等。进行原型法开发要求 4GL 有很强的交互能力。越先进的交互方式，越是 prototyping的良好环境。

　 80 年代末期，计算机辅助软件工程（Computer Aided Software Engineering, CASE）和面向对象（Object-Oriented, OO)的开发方法得到很大的发展，90 年代初开始实际应用。对象是一组数据和一组操作的集合，这组操作可以存取和处理这组数据。对象还可以组成类（classes〕。面向对象的方法有以下特点：它把数据和操作绑扎在一

　起作为一个对象。这里数据是主动的，操作跟随数据。面向对象的方法很容易做到程序重用，重用也较规范；面向对象技术使新系统开发和维护系统很相似，因为均是重用己有部件。当用于企业管理时，面向对象的方法模拟企业的运行，这时开发者和企业管理者的沟通用的是企业语言，而不是技术术语。面向对象的方法特别适用于图形、多媒体和复杂系统。

　 如上所述，60--70 年代是结构化系统分析和设计时代，80 年代初是 Prototyping 时代，80 年代末是 CASE 和 OO 时代，那么 90 年代的特点是什么呢？可能是客户／服务器的时代，或基于 WEB的开发时代。这时客户宁愿买现成的软件包，甚至是整个系统，而不愿自己开发。用户买来许多软件部件，自己或请顾问公司把它们集成起来。这就是系统集成或基于部件的开发，在 90 年代中后期这种趋势越来越明显。

　三、系统开发方法的分类

　 下面我们对系统开发或系统分析与设计方法进行一下分类。按时间过程来分，开发方法分为生命周期法和原型法，实际上还有许多处于中间状态的方法。原型法又按照对原型结果的处理方式分为试验原型法和演进原型法。试验原型法只把原型当成试验工具，试了以后就抛掉，根据试验的结论做出新的系统。演进原型法则把试好的结果保留，成为最终系统的一部分。按照系统的分析要素，可以把开发方法分为

　三类：

　 ①面向处理方法（Processing Oriented ，简称 PO）。

　 ②面向数据方法（Data Oriented ，简称 DO）。

　 ③面向对象的方法（Object Oriented ，简称 OO）。

　 PO 就是指系统分析的出发点在于搞清系统要进行怎样的处理，分为两种：一种是面向功能，由企业的职能出发；一种是面向过程。由企业运营流程出发，划分成一些过程进行处理分析。而 DO 首先分析企业的信息需求，建立企业的信息模型，然后建立全企业共享的数据库。OO 是先分析企业的一些对象，把描述对象的数据和对对象的操作放在一起，如果多个对象共享某些数据和操作，共享的数据和操作就构成了对象类。

　现在十分流行的面向过程的系统分析方法，在概念上它是把功能与数据结合，从本质上可以认为是面向对象的方法。如果把面向对象的方法和面向过程的系统分析结合，将会对系统开发的方法注入新的活力。

　1. 以过程特点分类

　生命周期法

　（Life Cycle, LC）：进行系统分析与设计时，将系统开发过程划分为系统请求、规划、分析、设计、实施、运行等几个阶段，每个阶段首尾相连，形成系统的一个生命周期。

　演进原型法

　（Evolution，EV）：

　从一个初型系统不断改进，最后成为一个最终的应用系统。

　实验原型法

　（Expriment Prototyping, EP）：

　建立真实系统的模型，由局部模型不断实验改进，最后得到整个系统的模型。

　2. 以系统的立足点分类

　面向功能方法

　（Function Oriented, FO）：

　首先搞清系统功能，按功能收集系统要求，按功能划分子系统。

　面向数据方法

　（Data Oriented, DO）：

　首先分析企业的信息需求，然后建立全企业的数据库。

　面向对象方法

　（Object Oriented，OO）：

　首先分析系统的一些对象，把描述对象的数据和对对象的操作放在一起，共享的数据和操作构成对象类。

　原型法

　(Prototyping): 是借助于新一代自动化的程序生成工具和应用系统，快速模拟出一个原型系统，然后再经过开发者和用户反复评价、修改和逐步完善，最终形成用户满意的应用系统。

　3. 从方法体系上

　自顶向下方法:首先将整个系统作结构化划分，然后从高层到基层、从整体到局部、从一个组织的功能、机制、任务到内部每个经营管理活动的细节进行系统分析和设计。

　需求分析法:面对一个复杂的组织、信息需求时，把握系统的关健和需求进行分析的方法。常用的有：关键成功因子法（CSFs），企业系统规划法(BSP)。

　原型法 :

　 (同上)

　生命周期法 LC :

　(同上)

　面向对象 OO :

　(同上)

　四、常用系统开发方法的分类

　1. 基于自顶向下、结构化、生命周期思想的开发方法

　.结构化分析设计技术

　.约当结构化系统开发方法

　.中国的映射模型设计法

　.詹姆斯.马丁的战略数据规划法

　.企业系统规划法

　.杰克逊的结构化程序和设计 JSP、JSD

　2. 基于新一代系 统开发工具和快速开发方法

　 .原型法及其分支（瀑布型、快速型）

　.计算机辅助软件工程（CASE）

　3. 面向对象法的系统开发方法

　.面向系统设计 OO 法

　.面向数据库 OO 法

　.面向系统程序设计 OO 法

　.面向知识工程师 OO 法

　§4.3 原型方法 (Prototyping)

　原型方法是 80 年代随着计算机软件技术的发展，特别是在关系数据库系统（RDBS, Relational Data Base System）、第四代程序生成语言(4GL, 4th Generation Language)和各种系统开发生成环境产生的基础上，提出的一种从设计思想到工具、手段都是全新的系统开发方法。

　一、原型法概述

　1. 什么是原型方法

　传统的结构化开发方法强调系统开发每一阶段的严谨性，要求在系统设计和实施阶段之前预先严格定义出完整准确的功能需求和规格说明。然而，对于规模较大或结构较复杂的系统，在系统开发前期，用户往往对未来的新系统仅有一个比较模糊的想法。由于专业知识所限，系统开发人员对某些涉及具体领域的功能需求也不太清楚。虽然可以通过详细的系统分析和定义得到一份较好的规格说明书，却很难做到将整个管理信息系统描述完整，且与实际环境完全相符，很难通过逻辑推断看出新系统的运行效果。因此当新系统建成以后，用户对系统的功能或运行效果往往会觉得不满意。同时随着开发工作的进行，用户会产生新的要求或因环境变化希望系统也能随之作相应更改，系统开发人员也可能因碰到某些意料之外的问题希望在用户需求中有所权衡。总之，规格说明的难以完善和用户需求的模糊性已成为传统的结构化开发方法的重大障碍。

　原型方法(Prototyping)正是对上述问题进行变通的一种新的系统开发方法。

　在建筑学和机械设计学中，“原型”指的是其结构、大小和功能都与某个物体相类似的模拟该物体的原始模型。在管理信息系统开发中，用“原型”来形象地表示系统的一个早期可运行版本，它能反映新系统的部分重要功能和特征。“原型方法”则是利用原型辅助开发系统的一种新方法。

　原型方法要求在获得一组基本的用户需求后，快速地实现新系统的一个“原型”，用户、开发者及其他有关人员在试用原型的过程中，加强通信和反馈，通过反复评价和反复修改原型系统，逐步确定各种需求的细节，适应需求的变化，从而最终提高新系统的质量。因此可以认为原型方法确定用户需求的策略，它对用户需求的定义采用启发的方式，引导用户在对系统逐渐加深理解的过程中作出响应。

　2. 原型方法的运用方式

　原型方法虽然是在研究用户需求的过程中产生的，但更主要的是针对传统结构化方法所面临的困难，因而也面向系统开发的其它阶段和整个过程。由于软件项目的特点，运用原型的目的和开发策略的不同，原型方法可表现为不同的运用方式，一般可分为以下三种类型：

　(1)探索型(Exploratory

　Prototying)主要是针对开发目标模糊、用户和开发人员对项目都缺乏经验的情况，其目的是弄清对目标系统的要求，确定所期望的特性并探讨多种方案的可行性。

　(2)实验型(Experimental Prototying)用于大规模开发和实现之前考核、验证方案是否合适，规格说明是否可靠。

　 (3)演化型(Evolutionary Prototying) 其目的不在于改进规格说明和用户需求,而是将系统改造得易于变化，在改进原型的过程中将原型演化成最终系统。它将原型方法的思想贯穿到系统开发全过程，对满足需求的改动较为适合。

　3. 原型法基本思想

　原型法 凭借着系统分析人员 对用户要求的理解，在强有力的软件环境支持下，快速地给出一个实实在在的模型（或称原型、雏形）

　，然后与用户反复协商修改, 最终形成实际系统。这个模型大致体现了系统分析人员对用户当前要求的理解和用户想要希望实现后的形式。

　二、原型定义策略

　1. 需求定义的要求

　需求定义是管理信息系统开发过程中的关键一环，它对最终系统的成功与否绝对重要。一般说来，需求定义必须满足以下的要求：

　(1)正确性

　 所规定的需求必须是用户所需要的。

　(2)完整性

　 需求应是完整、准确的，所有需求必须加以适当说明。

　(3)可理解性

　 用户和开发者双方应能以一种共同的方式来解释和理解所规定的需求。

　(4)一致性

　 各需求之间不能有逻辑上的矛盾。

　(5)非冗余性

　 不应有含混不清的、多余的需求和说明。

　(6)可测试性

　 需求应该能够验证，相应的文档应当易读和可修改。

　通过以上需求定义的特性可以看出，需求定义工作是一项严肃和艰巨的工作。在管理信息系统开发的需求定义中，应包括以下基本内容。

　2. 需求定义的基本内容

　(1)系统约束

　业务环境对最终系统的某些限制，例如计算机资源的限制，企业有关法则、政策的约束等等。

　(2)系统输入／输出

　每个子系统或功能模块中输入／输出数据的特征及定义。例如数据元素的内容、来源、数量、频数输出的媒介等。

　(3)系统数据需求和数据元素

　系统中数据定义以及数据间的关系，数据元素的属性与特征的定义。例如格式、名字、类型等。

　(4)功能

　确切指定系统应完成的操作和逻辑转换。

　 图 4－3－1

　改动--费用曲线

　(5)性能与可靠性

　明确系统的性能特征和耐故障能力。

　如果需求定义工作完成的不好，则在以后的各开发阶段中势必要进行各种纠错、补救工作，这将大大影响系统开发的时间和质量。另一方面，软件开发的实践表明，在系统开发后期引入一个变动，要比在早期引入相同变动所需付出的代价高 2～3 个数量级，图 4-3-1 的改动—费用曲线定性地描绘了在系统开发的不同时期引入一个变动需要付出的代价的变化趋势。图 4-3-2 是美国贝尔实验室统计得出的定量结果。

　图 4-3-2

　改正一个问题需要付出的代价

　此外，研究还表明，在传统的结构化系统开发中(SDLC)，百分之六十到八十的错误来源于需求定义阶段，如图 4-3-3 所示。

　 4-3-3

　SDLC 中系统错误的来源

　以上充分说明，系统开发中需求定义是系统成败的关健一步，对确定需求定义的技术和方法必须有足够的重视。

　3. 结构化的严格定义策略

　严格定义(预先定义)是目前采用较多的一种需求定义方法。在采用严格定义的传统的结构化开发方法中，各个工作阶段排列成一个理想的线性开发序列，在每一工作阶段中，都用上一阶段所提供的完整、严格的文档作为指导文件，因此它本质上是一种顺序型的开发方法，图4-3-4 所示。

　 4-3-4

　结构化方法的开发顺序

　在传统的结构化开发中，需求的严格定义建立在以下的基本假设上：

　(1)所有需求都能够被预先定义

　假设意味着，在没有实际系统运行经验的情况下，全部的系统需求均可通过逻辑推断得到。这对某些规模较小、功能简单的系统是可能的，但对那些功能庞大、复杂的较大的系统则显然是困难的。即使事

　先做了深入细致的调查和分析，当用户见到新系统的实际效果时，也往往会改变原先的看法，会提出修改或更进一步增加系统功能的要求，所以再好的预先定义技术也会经常反复。这是因为人们对新事物的认识与理解将随着直观、实践的过程进一步加深，这是与人类认识世界的客观规律相一致的。

　所以，能够预先定义出所有需求的假设在许多场合是不能成立的。

　(2)开发人员与用户之间能够准确而清晰地交流

　假设认为，用户与开发人员之间，虽然每人都有自己的专业、观点、行话，但在系统开发过程中可以使用图形／文档等通信工具进行交流，进行清晰、有效的沟通,这种沟通是必不可少的。

　可是在实际开发中，往往对一些共同的约定每个人都可能会产生自己的理解和解释。即使采用结构化语言、判定树、判定表等工具，仍然存在精确的、技术上的不严密感。这将导致人们有意无意地带有个人的不同理解而各行其事，所以在多学科、多行业人员之间进行有效的通信交流是有一定困难的。

　(3)采用图形／文字可以充分体现最终系统

　在使用严格定义需求的开发过程中，开发人员与用户之间交流、通信的主要工具是定义报告，包括叙述文字、图形、逻辑规则和数据字典等技术工具。它们的一个共同特点，都是静止的、被动的，不能实

　际表演，很难在用户头脑中形成一个具体的形象。因此，要静止的图形／文字描述来体现一个动态的系统是比较困难的。

　除了所论述的情况外，上述基本假设还将导致严格定义的结构化开发方法存在以下缺陷。

　首先是 文档量大，由于在结构化方法的每个阶段都必须写出规范、严密的各种文档，这些文档虽然有助于开发人员之间、用户与开发人员间的通信交流，有助于开发过程的规范化，但由于编写文档花费大量人力和时间，导致系统开发周期增大。

　其次是 开发 过程可见性差，来自用户的反馈太迟。由于在需求定义、系统设计阶段都不能在用户终端显示新系统的实际效果，一直到系统实现阶段结束，用户才有机会通过对新系统的实际操作和体会，来提出他们对新系统的看法和意见，但此时整个开发已近尾声，若想修改前几段的工作或修改需求定义，都将付出较大的代价，有时这种修改甚至会导致整个系统的失败。

　综上所述，需求的严格定义的基本假设在许多情况下并不成立，传统的结构化方法面临着一些难以跨越的障碍。为此，需要探求一种变通的方法。

　4. 原型定义的策略

　原型方法以一种与严格定义法截然不同的观点看待需求定义问题。原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始，允许用户在开发过程中提出更好的要求，根据用户的要求不断地对系统进行完善，它实质上是一种迭代的循环型的开发方式，如图 4－3－5所示。

　 图 4－3－5

　原型法的开发过程

　采用原型方法时需要注意的几个问题：

　(1)并非所有的需求都能在系统开发前被准确地说明。

　事实上，要想严密、准确地定义任何事情都是有一定难度的，更不用说是定义一个庞大系统的全部需求。用户虽然可以叙述他们所需最终系统的目标以及大致功能，但是对某些细节问题却往往不可能十分清楚。

　一个系统的开发过程，无论对于开发人员还是用户来说，都是一个学习和实

　践的过程，为了帮助他们在这个过程中提出更完善的需求，最好的方法就是提供现实世界的实例——原型，对原型进行研究、实践并进行评价。

　(2)项目参加者之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。用户和开发人员通过屏幕、键盘进行对话和讨论、交流，从他们自身的理解出发来测试原型，一个具体的原型系统，由于直观性、动态性而使得项目参加者之间的交流上的困难得到较好的克服。

　(3)需要实际的、可供用户参与的系统模型。虽然图形和文字描述是一种较好的通信交流工具，但是其最大缺陷是缺乏直观的、感性的特征，因而不易理解对象的全部含义。交互式的系统原型能够提供生动的规格说明，用户见到的是一个“活”的、实际运行着的系统。实际使用在计算机上运行的系统，显然比理解纸面上的系统要深刻得多。

　(4)有合适的系统开发环境。随着计算机硬件、软件技术和软件工具的迅速发展，软件的设计与实现工作越来越方便，对系统进行局部性修改甚至重新开发的代价大大降低。所以，对大系统的原型化已经成为可能。

　(5)反复是完全需要和值得提倡的，但需求一旦确定，就应遵从严格的方法。对系统改进的建议来自经验的发展，应该鼓励用户改进他们

　的系统，只有做必要的改变后，才能使用户和系统间获得更加良好的匹配，所以，从某种意义上说，严格定义需求的方法实际上抑制了用户在需求定义以后再改进的要求，这对提高最终系统的质量是有害的。

　另一方面，原型方法的使用，并不排除严格定义方法的运用，当通过原型并在演示中得到明确的需求定义后，即应采用行之有效的结构化方法来完成最终系统的开发。

　三、原型法（Prototyping ）开发过程

　首先用户提出开发要求，开发人员识别和归纳用户要求，根据识别、归纳结果，构造出一个原型（即程序模块），然后同用户一道评价这个原型。如果不行，则再对原型进行修改，直到用户满意为止。

　1. 原型法工作流程(动画)

　 2.原型法生命周期(动画)

　原型法生命周期有 10 个阶段:

　(1)方法选择

　从下述诸因素进行考虑，决定该需求定义工作是采用原型方法还是严格定义方法。

　系统结构

　原型法较适宜于相互联系程度较大的系统，如联机事务处理，而对批处理、批编辑等批结构则不适合。

　逻辑结构

　原型法较适合于管理信息系统等结构化系统，面对基于大量算法的问题则不适合。

　用户特征

　对于难于肯定详细需求，且准备积极参与新系统开发工作的用户，采用原型法方法是适宜的，反之则不然。

　应用约束

　原型法不适合于对已经运行的系统进行扩充。

　要对上述所有因素都得出完全肯定的结论是困难的，有时必须根据具体情况作出权衡。当对确定原型法是本项目最合适的开发方法达成比较一致的意见时，即可进入下一阶段工作。

　(2)识别基本需求

　为了设计、建立初始的原型，首先必须识别基本的需求。原型方法与传统的严格定义方法主要不同在于，原型法所识别的需求不必是完善的，而只是一种“好的”设想。

　识别用户的基本需求是一件较为困难的工作，没有捷径可走，而必须仔细对当前系统进

　行调查，与用户交互、做业务性研究等。传统的需求调查方法和本章介绍的方法都可作为识别基本需求阶段的工具。

　基本需求的识别对原型法生命周期的成败是至关重要的。一般地说，由基本需求导出的初始原型，其在需求方面的准确性至少应达 60%，否则会打击用户对原型法的积极性，使用户失望。在原型方法中，迭代只是为了修改和部分完善，而不能成为建立初始原型前逃避分析的借口。

　(3)开发原型

　本阶段的目的是建立一个有一定深度和广度的初始原型，以便由它开始进行迭代、修改和完善。原型开发人员可由 2 人(或另 1 人进行补充功能的辅助工作)组成，因为随着小组规模增大，通信上的困难将导致开发效率下降，而两人小组甚至不需要写出说明文件就可进行通信和交流。开发一个初始原型所需的时间随系统规模的大小、复杂性和完整程度而不同，最好应在 3～6 周时间内完成，这样既有较充分的开发时间，又可保持用户对原型法和最终系统的兴趣。一般认为，开发初始原型的时间最长不得超过两个月。初始原型的质量对原型法生命周期其它各阶段有着重大影响，因此，初始原型必须是最终系统的核心部分，今后的迭代都将建立在它的基础之上。如果原型过于简单，则会增加以后的迭代而浪费时间和人力。反之，如果为了追求完整而将原型建得过大，则会降低响应速度，并且今后势必要对其中大量功能进行修改同样也会降低系统开发的效果。

　(4)原型验证

　上一阶段所建成的系统原型为用户和开发人员提供了一个发展系统方案和功能的机会，本阶段的目的则是具体验证系统原型的正确程度，进而开发新的需求并修改原有需求。

　原型迭代初期的主要工作是：用户对原型进行熟悉和操作； 总体检查，找出隐含的错误； 用户实际操作和熟悉原型系统。

　原型迭代后期的主要工作是：发现不正确的或者漏掉的功能； 提出进一步的建议； 改善系统/用户界面。

　开发人员不能认为绘出原型就已大功告成。事实上，即使开发过程完全正确，也只是为用户进一步提出一些有意义的修改创造条件，这是原型系统开发的主要目的。

　原型法的目标是鼓励改进和创造，为此，开发人员应充分向用户解释所建成的原型的合理性，但不要为它辩护。系统的原型应该在人/机交互和用户/开发者交互的过程中逐步完善。

　(5)修正和改进

　在上一步工作的基础上，根据发现的问题和用户提出的要求对原型进行修正和改进。

　在极个别情况下，当发现初始原型的绝大部分功能都与用户要求相违背，或者由于其它原因使得该原型不能成为继续迭代的模型时，则应果断地放弃而不能继续凑合。

　更多的情况是在现有的原型基础上做进一步的改进。这时最好能保留

　改进前后的两个原型的版本，从而既可并存地演示两个不供选择的对象以帮助用户决策，又可在必要时，放弃本次修改退回原来的版本。

　(6)判断原型是否完成

　判断最终系统的需求是否已被掌握，原型迭代过程是否可以结束，以便决定下阶段的工作内容，即进行细部说明或继续验证原型。

　(7)判断是否需要细部说明

　在原型方法中，对那些不能通过原型进行说明的项目，如果有必要的话，应该提供详细的文字或其它形式的说明。本阶段的任务就是判断是否需要进行该项说明。

　(8)严格说明细部

　对那些不能通过原型说明的项目，用文字和图形等方式进行严格、详细的描述，写入需求说明的文本中。例如，系统的输入、输出、系统的逻辑功能、数据库组织、系统可靠性等项目均为需要进行严格说明的。

　在原型方法中，可借助屏幕和原型来进行讨论和确定，从而帮助进行严格的细部说明。

　(9)判断原型效果

　检查在上一阶段对某些项目进行严格说明后，是否会引起原型的失效。这时如果原型出现问题，则需对上述严格说明进行修改。

　(10)整理原型、提供文档

　把原型进行整理 、编写，以便为下一步开发服务。象任何其它软件系统一样，原型法也必须提供文档，包括最终系统的需求文档和原型本身的说明文档等。

　从上面所讲的各阶段内容可以看出，采用原型生命周期提供的技术和方法，能使最终系统的需求定义合理化。原型法通过动态演示，能使以用户为中心的需求得到检验和认可。

　四、原型法的特点

　原型法从原理到流程都是十分简单的，且倍受推崇，有着传统方法无法比拟的优越性，它有如下特点：

　1.原型法符合人们认识事物的规律

　人们认识事物不可能一次就完全了解；

　认识和学习的过程是循序渐进的；

　人们对事物的描述都是受环境的启发不断完善的；

　人们改进一些事物比起创造来要容易；

　2.原型法有利于项目的开发者和用户之间的交流

　原型提供了具体的、看得见、摸得着的模型，减少误解和不确定性；

　原型启发了人们的认识，其直观性使之能准确描述需求；

　原型通过具体的系统，能够缩小开发者和用户对问题的理解与认识的差距；

　原型模型能够及早暴露系统存在的问题；

　3.实际的原型为准确认识问题创造了条件

　原型的直观性、感性特征易使用户理解系统的全部含义；

　讨论的原型是开发者与用户共同确认的；

　讨论问题的标准是统一的；

　信息的反馈是及时的；

　4.能充分利用最新的系统开发环境

　利用最新的软件工具，建立系统的开发、生成环境；

　计算机技术发展使系统局部修改或重新开发成为可能；

　新技术加快了速度，减少了费用，提高了效率；

　5.原型法将系统的调查、分析、设计融为一体

　 用户一开始就能看到系统实现以后的具体样子，消除了心理负担，打消了对系统是否可实现、是否适用等的疑虑；为用户参与开发过程创造了一个良好的条件；提高了用户参与系统开发的积极性。

　五、原型法的开发环境

　由于计算机硬件的迅速发展，目前硬件已经能够满足原型化开发的需要。下面我们对原型方法所需的软件和工作环境基本要求进行介绍。

　1．对软件的基本要求

　在原型开发方法中，由于需要迅速实现原型、投入运行并不断修改，所以对开发工具提出了更高的要求。一般认为，采用原型法需要以下的基本开发工具：

　(1) 集成化的数据字典

　用来保存全部有关的系统实体(例如数据元素、程序、屏幕格式、报告等)的定义和控制信息。它可以辅助生成系统的某些部件。

　(2) 高性能的数据库管理系统

　它使文件的设计、数据的存贮和查询更为方便，并简化了程序的开发。

　(3) 超高级语言

　例如第四代语言(4GLS)，它能支持结构化程序技术，交互性能强，以减轻复杂的编码过程。

　(4) 报告生成器

　与数据字典融为一体，允许原型开发人员使用非过程化的语言，快速生成自由格式的用户报表。

　(5) 屏幕格式生成器

　能够快速建成用户所需的屏幕格式。

　(6) 自动文档编写机制

　与数据字典相联系，随着原型化开发的进行，能够自动保存和维护所产生的文档。

　前面所说的第四代语言(4GLS)，与我们通常使用的过程式语言(也称第三代语言一 3GLS)相比，其主要的特点是：面向结果而不是面向过程；用户界面友善；编码行要比 3GLS 少得多；高度交互地解释执行；或有某些编译性的特征。

　在原型化开发中，开发工具的集成化是相当重要的，图 4－3－6描述了一个集成化的软件开发环境。其中一个集成化的数据字典将各种资源和开发工具加以联系，所有的工具都通过数据字典进行通信，形成一体化的开发环境，从而使得高效率的原型开发成为可能。

　 图 4－3－6

　集成化的软件开发环境

　以上论述的软件要求是比较理想的情况。然而，国外近年来的几个开发实例说明，在上述条件不能全部满足时，仍然可以进行小规模的原型化开发。

　在大多数常规软件中，执行速度是衡量软件质量的重要标准。而对原型软件来说，运行速度则是次要的。在原型软件开发中首先考虑的是原型化开发人员的最佳生产率。

　2．对工作环境的基本要求

　为了提高原型开发的生产率，需要提供一个合适的工作环境，例如：

　(1)系统开发工作室，一个自封闭式的工作环境，有利于促进合作、减少约会时间以及提高数据和资料的利用率。

　(2)快速响应的环境在原型演示过程中是很有必要的。一般的要求是：交互式过程，响应不得超过 5s；批处理方式中，响应不能超过 15min。如果用户在屏幕前等待时间过长，将会削弱对原型的兴趣和信心。

　(3)规范的原型构成过程，必要的规范和标准能加快原型的建立和向最终系统的转换。利用规范的开发技术，将使现有程序“切割和粘贴”出新程序成为可能，从而加快开发速度。

　(4)演示设施是审查和评价原型的重要手段。有条件时可将显示器与大屏幕投影机相连，只要有必要，就可对任何屏幕形式展开讨论。

　六、原型法的开发原则

　下面将要讨论的原型方法原则为系统提供了一套原型开发的思想方法，对于大多数原型化过程来说，只需分析最终系统的某些特殊部分，而大量的功能、结构和用户界面，都能从其它现有的模型得到借鉴和重用。系统可以灵活地运用原型法的这些原则，将有助于整个原型开发过程。

　原型方法的原则如下：

　1．多数系统的结构都能从一个基本系统结构的集合导出

　一个系统中的大多数业务应用，都可从下述八个基本的系统模型结构中进行修改和补充后得到。

　(1)成批编辑／修改，把用户输入的数据汇集成批，定期输入给系统。

　(2)成批生成报表，以成批方式定期从数据库中产生标准或非标准的报表。

　(3)成批转换，一批程序应用多种转换规则定期对指定的数据库进行修改。

　(4)成批对接，在系统之间定期进行成批输入／输出对接。

　(5)联机修改／查询，定期产生于用户和系统之间的事务。

　(6)联机特殊查询，用户对系统的随机的特殊查询。

　(7)联机界面，在实时应用情况下，在系统之间定期进行对接。

　(8)联机报表生成，立即打印或推迟成批打印报表。

　图 4－3－7 是上述基本系统结构的一个示意

　 图 4－3－7

　基本系统结构

　2．多数系统都包括一个常用的功能集合

　大多数系统具备如下基本功能：

　(1)对数据库记录的增加、删除和修改。

　(2)对文件(包括数据库和其它文件)的显示。

　(3)用户表格的打印。

　以上功能是实现一个系统的基础。对于不同的系统，对这些基本功能会有个别的具体的要求，这正是我们在建立原型前要研究的内容。

　3．报表功能可用统一的报表模型实现

　从数据库生成报表的过程可分成三步:

　从数据库中选择和组合数据；

　定义报表格式和表头内容；

　打印该报表。

　因此，可事先建立一个具有“记忆”功能的报表生成器，由用户决定数据库名称、报表格式、表头内容等，系统自动将上述信息保存起来，需要时可方便地打印出相应报表。这样用户就能在原型化过程中直接参与、帮助开发报表功能。

　在原型建立的过程中，如果对系统中的每个功能都要分别从头调查，同时又必须快速地建立这个不熟悉的系统模型，几乎是不可能的。根据上面讲的原则，原型开发者在工作中应充分利用那些成熟的基本结构、基本功能模块或程序。虽然用户提出的是一个新的系统需求，但对于有经验的原型开发人员，都能很快从中找出系统的基本功能和共性，从而利用他们曾经多次开发过的现

　成的模型进行“裁剪”和“粘接”并进行必要的增补。因此，快速地建立一个新的原型是完全可能的。

　六、原型构造的修改控制

　在运用原型方法进行开发之前，必须明确运用原型的目的，从而决定分析与构造内容的取舍。由于原型不同于最终系统，它需要迅速实现，投入试运行。所以必须注意在功能和性能上的取舍。既要忽略暂时不太关心的部分，以便加快原型的要求。又要充分体现原型的作用，满足评价原型的要求。根据评价原型的目的，明确考核与评价的内容。例如针对人机界面形式、系统结构、功能或模拟性能等。所构造的原型可以是一个忽略细节的整体系统，也可以仅是一个局部，例如人机界面、部分程序系统或数据库模式等等。

　下面给出的功能和内容只有在开发最终系统中才需要，而不必在原型构造时去考虑:

　报表打印的具体格式；

　用户操作手册；

　人／机错误处理；

　系统测试计划；

　质量控制检查；

　数据库规模；

　系统转换过程；

　硬件和通信资源配置等。

　原型法的开发过程是一个不断地对系统原型进行使用、评价、修改的循环、迭代过程。一般说来，修改和迭代的次数越多，原型的质量就越高，但由于人力、物力和时间的限制，这种修改绝不可能无限地进行下去,必须用科学的方法加以控制和限制。

　控制原型修改次数的方法很多，在管理信息系统的开发中，通常可采用下列方法：

　(1)限制修改次数

　系统开发前，根据各原型或原型中各模块的重要性、复杂程度以及经费、时间限制情况等因素，分别约定各自的最大修改次数。如果修改次数达到该预定值时就停止修改，把原型固定下来。由于事先限制了修改的次数，因此采用该方法时可能还达不到要求最高用户的接受程度。

　 图 4－3－8

　用户原型接受程度的变化

　(2)限制用户接受的百分数

　在管理信息系统开发中，由于对某些性能、指标的认识不容易统一，所以不能期望用户百分之百的绝对满意。为了控制修改原型的次数，可事先定下用户接受原型的百分数标准，例如定为 80％，那么当用户接受程度达到该值时就可停止原型修改。在一个不稳定的用户环境下，用户对原型某些问题的想法经常在变，修改一次原型可能增加用户的接受程度，如图 4－3－8 所示。但是，试图通过一再修改原型来提高用户接受的百分数，有时也是行不通的。在实际开发时，也可将 1、 2 两点结合使用，即事先同时定下修改次数和用户接受百分数这两项指标的最大值，在原型修改过程中只要其中一个最大值被达到，就停止修改。

　八、从原型向最终系统的转换

　原型经过反复的使用、评价和修改以后，即可转入最终系统(或称正式系统)的开发，如图4-3-9 所示。从原型向正式系统的转换方式有三种。

　 图 4－3－9

　原型向最终系统的转换

　1. 程序一次性使用( 只利用需求和规格)

　该方法对原型研制限定在传统软件生命周期的某一阶段，例如，需求定义阶段，正如我们在本章第 3 节所介绍的那样。该阶段工作结束后，原型随之作废。该方式可用于验证、完善系统需求和人机接口的原型开发。

　2 ．程序嵌入( 作为核心部分利用)

　程序嵌入方式是将完成了的原型体作为正式系统的核心部分。事实上这是一种附加策略，对应于我们在本章所介绍的演化型的开发形式，把原型作为核心，逐步添加新功能，发展成为最终系统。在抛弃策略中，原型与最终系统的开发可以采用不同的高级语言。而在附加策略中，因原型将作为最终系统的一部分，所以必须采用与最终系统相同的开发语言。

　3. 程序自动变换

　采用该方法时，原型体用高级语言开发，并自动将原型体变换成比最终系统的语言更低的中间语言，使得嵌入在最终系统中的原型体的运行效率比变换前大大提高。

　程序自动变换法尚存在一些未解决的问题，例如不同语言之间的自动变换的困难，后程序的性能不能保障等。因此，该方法目前还处在研究阶段，并未达到实用化程度。

　九、原型法优缺点和适用范围

　通过前面的介绍可见，原型化方法通过对原型的反复使用、评价和修改，给用户和开发人员双方提供了一个学习和实践的机会，从而产生对系统需求的新认识，提出新的需求。该过程与人们的认识论相一致，这正是原型化方法能够克服严格定义层难以克服的困难的根本原因。

　1. 原型法主要有以下优点

　(1)原型法是以用户为中心来开发系统的，原型法提供了一个验证用户需求的环境

　原型法允许在系统开发生命期的早期进行人机交互测试， 原型法提高了人们对最终系统的安全感， 便于应用实例来建立新系统。

　(2)原型法加强了开发过程中的用户参与程度

　原型法可以接受需求的变动和风险。

　(3)原型法对用户具有强大的吸引力

　原型法可以缓和通信和交流的困难，原型法可以提供很好的系统说明和示范， 原型法可以简化开发过程的项目管理和文档编制。

　作为一种具体的开发方法，原型法不是万能的，有其一定的适用范围和局限性：

　2. 原型法局限性

　对于大型的系统，如果不经过系统分析来进行整体性划分，要想直接用屏幕一个一个进行模拟是很困难的。

　对于大量的运算、逻辑性较强的程序模块，原型法很难构造一个合适的模型来供人评价。

　对于原基础管理不善、信息处理混乱的问题，使用有一定困难。

　对于批处理系统，因其大部分是内部处理，用原型法有一定困难。

　 3. 适用范围

　适用于小型、局部系统

　适用于规模较小的系统

　适用于业务处理过程比较简单或不太复杂的系统

　适用于业务需求相对较为确定（不一定很明确）的系统

　适用于具有较丰富系统开发经验的...

推荐访问:常用 方法 章节