2023年-信息系统开发过程概述.docx

《2023年-信息系统开发过程概述.docx》由会员分享，可在线阅读，更多相关《2023年-信息系统开发过程概述.docx（19页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、系统开发过程口 五个阶段各种系统开发方法学在范围、复杂性、完善程度以及方法上有很大的不同。 尽管有的方法学分三个阶段，有的分15个阶段，但是每个方法学所描述的要完 成的活动基本上是相同的。本章要阐述的最重要的一点是：最好的方法学是那些 始终把用户考虑进去的方法学。过去的情况是，用户管理人员与信息服务开发组 合作来完成系统的一般功能说明书，然后，由信息服务人员来进行系统开发。现 在，系统开发是各占50%的比例；因此，用户管理人员应该非常熟悉系统开发的 大体过程，特别应该熟悉他们单位自己使用的方法学。系统开发过程可分为五个阶段来描述。这五个阶段是：1.第I阶段-系统开始和可行性研究2第n阶段-系统

2、分析和设计3 .第HI阶段-程序设计4 .第IV阶段-转换和实现5 第V阶段-实现后的评价第I阶段-系统开始和可行性研究是在为开发一个建议的系统提供人力和资 源之前完成的。第I阶段多数的工作和编写的资料是第n阶段的输入。在第n阶 段-系统分析和设计期间，系统分析员与用户一起工作以编写详细的功能和系统 的说明书。将这些说明书交给程序员，然后开始第ni阶段一程序设计。在第VI 阶段-转换和实现期间，一旦软件开发出来，则建立数据文件，转换现有系统， 并且实现新系统。第v阶段-实现后的评价。在开始了系统寿命期中的生产阶段 之后，提出(经常被忽略的)实现后的评价要求。具体开发过程下面将逐步地描述系统开发

3、过程。至于具体的细节、相互的影响、方法、形 式等，用户管理人员应该与信息服务经理联系，与他们讨论公司当前使用的方法 学，同时再看看公司内部描述方法学的手册。1.第I阶段-系统开始和可行性研究在第I阶段的活动中很少有与其他四个阶段的活动相一致的。此处所提供的 方法包括对于受拒绝后的再次服务请求的方法以及将技术转移可能性的研究合 并到诸过程中这些内容。第I阶段最终的产品有两个部分。第一部分是实际的可 行性研究报告，它包含对建议的或改进的系统的描述以及利润/成本分析。第二 部分是系统的初步设计。它对于估价成本和利润是必要的。该初步设计是第n阶 段-系统分析和设计的直接输入。将系统的初步设计并入可行性

4、研究的依据是，多数可行性研究是以概念而不 是以设计为基础的。如果在描述系统目标上花的时间太少，那么成本估计，甚至 利润估计将是错误的。用概念来指导可行性研究注定会导致成本过高，而且用户 不满意。在系统初步设计上所花费的时间是值得的，即使拒绝可行性研究也是如 此。因为所编写的资料将必然会被证实其他项目中是有价值的。下述编号的活动与表20. 9. 2的系统开发责任矩阵相对应。(1)提交服务请求图20. 5.1说明了包括对受拒绝的请求再次请求处理的一种方法。所请求的 服务毕竟是用户做的，因此，应该由用户着手进行。我们鼓励用户管理人员请求 数据和经验来估计中间和最后活动完成的日期。项目组组长必须与信息

5、服务人员 以及业务领域的管理人员密切合作以保证在系统开发过程中在各关键点有足够 的人员。系统开发过程本质上是线性的（一个活动接着一个活动），而且是不难用适当 的准则（方法学）和合理的估计来监视的。表说明了一个典型的信息系统 项目进度表。在活动点上加上三种标志之一以指出该活动的状态。如果情况表明 该活动是不必要的，则在活动号上加一个圆圈。如果一个特定的活动正在着手进 行，则在相应的活动号上划一个对角线。一旦活动完成则将对角线改成交叉线 “义:有时也用甘特表来给出项目进展的图形轮廊。在开始一组有阶段标识的活动之前，要准备一个更为详细的进度表，来单独 安排这些中间活动。对于要求多于两周时间的那些活动

6、将以两周为增量来安排进 度。表20. 9. 9说明了对具有阶段标志E的那些活动的一个详细的信息系统项目 进度表。表信息系统项目进度表+具有阶段标志完成的活动阶段标志活动估计的 开始时间 实际的 开始时间 提前或 推迟的 天数 估计的 完成日期 实际完 成的日期 提前或 推迟的 天数A 1 2 3 4 5 198W. 9. 1 198W. 9. 1 DS 198W .10. 1 198W. 10. 15 12BB678 910 198W. 10. 1198W. 10.20 14B 198W. 11. 1198X. 12. 122BC1112B1314 15 16 17 18 19 198X. 9

7、. 15 198Y. 9. 1 13A198X. 12. 25 198X. 12. 20 3AD B2021 22 23 198Y. 1. 15 198Y. 1. 15 DS 198Y. 2. 15E24252627 198Y. 3. 1 198Y. 6.30F2829198Y. 6. 1 198Y. 7. 15G303132198Y. 6.25 198Y. 9.10H33198Y. 10.1 198Y. 10.31I343536198Y. 11. 1 198Z. 2.1 1二已开始的活动X二已完成的活动0二不要求采取措施+对应于图20. 9. 3中的方法学*直到实现可行性研究之前，并不进行第

8、n阶段活动v的估计A二提前的工作天数 B二推迟的工作天数口5二正在进行表20. 9. 9信息系统项目进度表具有阶段标志E的活动阶段标志E-细节活 动 估计的开始 时间 实际的 开始时间 提前或 推迟 天数估计的完成日期实际的完成日期提前或推迟天数24 指定程度组长198y, 3. 1 198y, 3. 825安排顺序和分配 程序198y, 3. 5198y, 3. 1226安排程序准备 进度198y, 3. 15 198y, 3. 2527aKG*2编定、27b KG*2同上27c KG*2同上27d KG*2同上27eKG*2同上27f KG*2同上测试程序 并编与程序资料198y, 4.

9、1198y, 4. 11198y, 4. 15198y, 4. 30198y, 5. 1 198y, 5. 14198y, 5. 15198y, 5.31198y, 6.198y, 6. 14198y, 6. 15 198y, 6. 30*以阶段标志D的活动 A二提前的工作天数B二推迟的工作天数实际开始时间为准 os二正在进行下面的方法可以用来估计价格、人员以及相应的时间要求。这种循环使用的 方法使得一组人能意见一致，而且对于信息服务项目特别合适。我们假定参与估 计的那些人能够提出问题或具有任务方面的知识，而且能够提出支持自己意见的 重要的理由。参与建立信息系统项目进度表的人可以包括项目组长、

10、起作用的用 户经理以及其他有经验的信息服务人员（他们不一定与本项目有关）。我们通过以 下几个步骤来描述进行合理估价的方法。项目组长介绍任务（例如，确定项目进度表的阶段标志的日期）和相应的背 景信息。每一个参加者提交一个书面估计（成本、人员要求或时间）。项目组长（以线性比例）绘出该组每个成员的估计。计算上、下四分点和中点，并且标上迟度。要求其估计低于上、下四分点的那些参加者解释他们低或高估计的理由。项目组长就所标绘的估计召集一次公开的讨论会。重复步骤至，直到达到精确性要求不需要再循环为止。通过每一次循 环，将降低估计的误差。估计是取中间值或（在适合时）取平均值。估计的误差是包含危险的一种标 志。

11、（15）与用户人员交谈与用户交谈的过程从本活动开始。为了解决问题和确定系统要求，项目组成 员定期与有关用户见面。与用户交谈及反馈的过程贯穿于系统开发的全过程。对于详细设计的基本输入是：（A）初始设计（来自可行性研究），（B）对现有系 统及其成分的评价（也是来自可行性研究）以及（0输入、处理以及输出的要求（由 用户提供）。而目组与有关的用户人员检查在可行性研究的初始设计中所描述的输入/ 输出要求和频率，并根据需要及价值对每一种输入/输出进行评价。许多输出是 “有了更好”，但是却不值得去产生它们。还可以根据周期和时帧来估计输入/ 输出。通过估计频率/价值比的平衡来优化周期的输入和输出。例如，如果每

12、周 情况报告可以满足需要，那么就没有必要再产生每天的情况报告。在联机系统中, 检查响应时间要求以确定这种时间要求是否太紧迫，能否适当放宽要求而又致于 对运行效率产生较大的影响；或者确定这种响应时间的要求是否不能满足。目前系统的资料对设计提供了有价值的输入。现有的报告、表格、原始资 料等等，实际上能够追踪最终用户以便确定该资料是否合适，是否及时等。如果 是，还能做哪些工作来改进它们?项目组负责对现有的所有输入和输出进行修改。 通过合并类似的输入和(或)输出以及消除多余的信息尽可能地减少重复。初步交谈的一个直接结果是对所建议的系统所有的输出一般的描述(报 告，显示或事务)。根据周期、初始用户、输出

13、介质、内容以及分布来描述每一 种输出。(16)说明数据库要求数据库用来支持系统的处理，特别是支持系统的输出。在目前系统的资料中 包含了可继续使用的数据元。许多现有数据元的格式肯定是需要改变的，还需要 将支持系统功能要求所需要的其他数据元标列出来。项目组设计和编制数据字典，在一部数据字典中所列出的数据具有维持每个 数据元的基本信息，而它们与数据库或文件的组织形式无关。在表20. 9. 10给出 的数据字典的例子中，包括对每个数据元指定了一个各自的前后参照号、标题、 描述(如果必要的话)、是否被编码、程序设计标识、存储单元(字符)数、格式和 存储器大小(程序最初使用的)以及职责等。用户必须给出负责

14、的人或部门、存储 单元以及是否对数据元编码等事项。表20. 9. 10的数据字典形式，也可以用来交 叉引用在所有原始资料、报告、文件以及数据库中出现的每一个数据元。 在 标列出所有的数据元之后，项目组与数据库管理员合作来进行记录格式和文件的 设计，或者，在数据库环境下，他们设计数据库的模式。此活动的输出是数据字 典以及有关文件和(或)数据库模式的一份详细的技术描述。表数据字典报告标题数据字典日期系统标题标识编号标题描述编码否标记字符数字形/格式存储职责原始资料(S)、报告(R)、文件(F)、或数据库(D)工资支票(R)工资登记簿(R)工资主文件(F)会计文 件(F)工时卡(S)1社会保险号职工

15、否99999 P 人事X X X X2姓否LNAME 13 X (13) E 人事X X X X3名字职工否ENAME 10 X (10) E 人事 XXX4名字首字母职工否MI 1 X E 人事 XXX5部门职工亲属是DEPT 3 XXX E 人事X X X X6性别男或女是SEX 1 XE 人事 X7工资月工资否SAL 6 9999 P 人事 XXX（17）建立控制和后援的方法为了保证信息系统的正确性、可靠性和完整性，在设计时就要考虑加进控制 手段。项目组将说明在系统设计时要嵌入所有物理上的和行政管理上的控制。在 系统的输入、处理和输出阶段用以控制系统的技术的范围是广泛的。在处理之前 核对

16、输入，在处理期间使用诸如合理性检查以及数字位检查等技术以便最小化或 消除在计算或处理中的过失误差，记录计数和长度核对是用来保证输出正确性的 许多技术的代表。为了避免在系统故障期间造成破坏，需要确定后援（备份）和校验点/重新启 动的方法。这些方法描述了包含在系统中的克服故障的额外处理，在系统故障的 情况下，利用备份文件和（或）备份事务日记从上一个“校验点”来重新建立处理o 在上一个校验点“重新启动”系统，并重新开始正常的运行。在系统处理周期期 间，定期地建立校验点将会使系统及时地保留在该点的所有处理，而且不会被破 坏。（18）完成详细设计详细的系统设计是分析输入/输出、处理、控制和后援要求的结果

17、。系统初 步设计或系统一般设计只描绘了各主要处理活动之间的关系，而系统详细设计则 扩展到包括所有处理活动和有关的输入/输出。这是系统开发过程的基础活动。 正是这一步，将功能说明书与技术上和方法上的新设施结合一起以实现一个系 统。详细设计是前面所有工作的归宿。此外，它也是该项目今后所有活动的一张 蓝图。在活动5中提到了用图形说明系统设计所使用的若干技术（但没有详细讨 论）。这里我们简单地讨论其中三种技术一流程图。HIPO以及渥宁（Warnier）图。 用来形象地描述工作流程和总的系统设计的最流行的技术是流程图。流程图使用 刻画系统逻辑的一些专用符号并通过流线把这些符号相互连接起来以说明工作 流程

18、和数据流程。图20.9. 11给出了系统流程图符号的一个子集。在图20.9.12 中，用流程图描绘了一个已投入运行的工资系统的一部分。 流程图有一定的 缺点。不像前面所讨论的其他两种技术，流程图并不鼓励分析员使用系统设计的 自上而下或模块化的方法。因此，用流程图方法来设计系统，不仅难于设计，而 且设计出的系统也难于理解和维护。流程图之所以较为流行，主要是由于它是最 早出现的设计方法。层次式输入-处理-输出法（又称HIP0法）是在一层次体系中将系统设计按其 详细程度分层，依次地说明所有的输入、处理和输出的一种方法。图20. 9.13 说明了一个工资系统的HIPO卷内容表（VTOC）。VTOC是在

19、HIPO设计方法中所使 用的几种标准形式之一。整个系统被划分成由若干逻辑模块所组成的一个层次体 系，并用VT0C来描绘。此后，利用粗框图和细框图还可以将这些模块进一步划 分成更细小一层的输入-处理-输出的细目。通常由若干个VT0C将设计的层次体 系统推进到依次的细目层。从HIPO结构化方法所得到的好处往往被编写系统资 料所需要的大量繁琐的文书工作所抵消了。Warnier框图（在图中说明）可以用来设计整个系统、数据结构、报 表内容以及数据元的编码。使用Warnier框图的依据是：应该围绕着数据结构来 设计系统。Warnier框图的最大优点是对各种环境的适用性。图20. 9. 15中的例 子是一个

20、扩展项判定表，它是许多判定表中的一种，一个判定表有一个条件分叉 （在表的左上方）和活动分叉（在表的左下方），一个条件项（右上方）以及一个活动 项（右下方）。判定表并不是一个说明数据流和工作流的有效的工具，最好把它作 为其他设计方法的补充。判定表的主要好处是必须考虑到每一种可能的替换者、 选择、条件、变元等。与流程图，HIP0图以及其他设计方法不同使用Warnier 框图法，系统分析员不必考虑细节。图20. 9.11部分系统流程图符号图20. 9.12简化的工资支付系统流程图工资系统 系统开始 每月处理 月初 每周处理 提交时间卡片 数据录入 按工时处理职工记录工资支票工资联单更新工资文件月末按

21、月薪 处理职工记录 工资支票 工资联单 更新工资文件 系统结束图 20.9. 14 Warnier 框图图20.9. 13 HIP0：卷内容表上面讨论的分析工具代替了一大段解说词，而通常对解说词的理解容易产生 混淆。然而，精心设计的解说词可以而且应该用来支持图形设计技术。没有一种分析和设计的技术是最好的，最好的分析和设计技术是适合一个公 司具体情况的各种技术的组合。总之，模块化的自顶向下方法是当今必不可少的。 按自顶向下方法进行设计时，通过最高一级的管理者来建立基本的系统目标，然 后根据在公司每一级收集的输入数据，在设计中增加后继的细目层。由于作为一 个整体概念多数系统过于复杂，所以将系统分成

22、若干个更容易理解的模块。模块 化的主导思想是“各个击破”，而这是行之有效的。（19）指导用户或信息服务部门预演。表20.9.15 一张判定表支付类型 工资 按工时处理 佣金时帧周末月末周末月末周末月末打印工资支票X X X X X打印工资联单 X X X X结构预演是一种预测评价方法，它能有效地减少某些被忽略的或作错的事 情。它也给预测者提供一个机会来评价那些业已建议的事情（如系统设计），从而 有可能给出一些建设性的建议。预演的目的是给项目组提供有价值的反馈信息， 而不是对系统的质量下判决性的结论。项目组长应考虑何时开始结构预演。通常预演是在系统设计以及系统开发过程中其他一些关键点（如，测试计

23、划、程 序描述等）完成之后才进行。参与结构预演中的人有：若干项目组成员，一个协调员，参加者，一位秘书, 或许还包括一位不属双方的“中立的”经理。项目组的某个成员或所有成员扮演 “推荐者”的角色，并且解释他们所承担设计的系统的那一部分。协调员负责组 织预演和协调“推荐者”与“参加者”之间的相互配合。根据对所提出的课题的 知识和兴趣来选择“参加者:这些人应该是没有直接参与本项目的。秘书将对 一些要点作书面记录。通常邀请一个“中立的”经理参加第一次预演。中立经理 的出席将促使参与预演的每一个人专心于他的工作（这一点有时是预演的一个问 题）。结构预演的方法是简单的。在进行预演的前几天将需要审查的材料（

24、即系统 设计）分发给参加者，协调员负责跟参加预演的所有人联系和通信。在实际的预 演期间，推荐者解释系统设计以及有关的资料。这是通过一步一步地预演系统来 进行的，有时可能还借助于某种设计工具。参加者提供出讨论的建议，而秘书则 记录下来以形成资料。通常一次预演持续的时间不应超过一个半小时。如果超过 了这个时间限制，那么一次预演会议将变得没有实际效果。如果必要，可以安排 几次会议来完成预演。项目组评价所有的建议，并且把所有价值的建议并入到系统设计中。预演是 有价值的，它使得设计者在系统实现之前获得重要的反馈信息。（20）选择硬件如果正在开发的系统要求额外的硬件支持，则需要选择适当的硬件并进行订 货。

25、获得硬件的过程通常是信息服务经理的责任。（21）准备输出格式在系统开发过程中，到目前这一阶段为止，我们已经提及了输出并描述了其 有关的内容，但是程序员需要知道具体的输出形式（即应该怎样在输出设备上出 现）。这种详细的输出说明称之为输出格式。项目组产生出显示屏（VDU）格式，这 种格式规定了诸如题目、标题、输出形式等项，有时还应包括输入形式。某些硬拷贝报告和资料要求事先打印好的表格纸，项目组与表格纸厂商的代 表合作设计这种事先打印好的表格纸（例如，工资支票和短线）。项目组还负责设计和满足在系统范围内所有人工产生的报告和资料，同时与 受有影响的用户经理相配合进行修改、增加或删除。（22）描述数据项

26、的说明书数据项的说明书详细规定了什么数据将输入到系统以及它们怎样被输入到 系统中。（23）准备程序描述系统开发进展到目前这一步，我们已经对现有的系统作了详尽的分析。它的 功能已经并入建议的系统的设计中，我们已经完成了建议的系统及其支持的数据 库的设计，并且还准备了所有输入/输出详细的说明书。现在项目组可以着手标 列和确定所有的程序，而这些程序是使得建议的信息系统运转所要求的。系统的 图形表示（流程图、HIPO图和其他）是标列所要求的程序的初始输入。对每一个 程序，项目组编辑下述的资料：程序语言的种类（例如，COBOL. BASIC、FORTRAN）程序解说词的描述-描述要执行的任务。由程序所产

27、生的各种输出的描述和格式处理频率（例如，每天、每周、联机等）界限和限制（例如，输入数据的顺序，容量的限制，响应时间，最大值， 最小值等）详细说明书（例如，排序，编辑的标准，特殊的计算和逻辑操作，各种表 格等）。3 .第ni阶段-程序设计项目组现在可以着手开始与计算机通信了。这种通信（或与计算机的接口） 是采取指令形式来进行的，而这些指令被编进计算机程序中。这些计算机程序包 括系统运转所必需的软件。在第HI阶段-程序设计阶段将开发支持信息系统所要 求的全部软件。用户的介入集中在系统开发的过程前段（第n阶段）和后段（第w和v阶段）o 如果正确地完成了第n阶段而且用户与项目组的协作是有“成效”的，那

28、么用户 将很少介入程序设计阶段，甚至完全不用介入。用户介入最多的情况将反复出现 在系统设计需要澄清的时候，有时也出现为第w阶段（转换与实现），作一些初始 计划的时候。不幸的是，有时用户管理人员也较深地卷进了程序设计阶段。这是第n阶段 进行得很糟糕，而且当开始程序设计时还没完成的一种标志。这种情况是经常发 生的，特别是在时间紧迫时，项目组常常收到一些强制性的命令要求产生尚未完 成的产品。由于系统开发过程的最终产品是软件，所以有时过早地开始程序设计。 这种系统开发方式必然导致产生质量低劣的系统。这种系统并不能满足用户的要 求，而且维护的代价很高。这种系统整个寿命期的成本可能是一个高质量的系统 的两

29、到三倍。（24）指定程序员组长通常项目组长是一个系统分析员或是一个用户，他并不直接参与程序设计工 作。管理程序设计工作的人应该是程序设计工作实际的参加者，因此，对于要求 两个人以上的程序设计工作，将由信息服务经理指定一个程序员组长。当然，项 目组长仍然对整个项目负有责任。 程序员组长有时也称作为主程序员o他（或 她）可能只花10%的时间在产品的程序设计上。如果只需要管理一个下属程序员， 那么主程序员可能花80%的时间在产品的程序设计上。（25）安排顺序和分配程序一个信息系统的软件包，可能要求几百个程序。并不需要按照这些程序最终 执行的顺序来编写它们，在建立程序开发进度表时，必须考虑到许多变化的

30、因素。 在安排程序编制顺序时，主程序员应考虑如下问题：建立和维护测试文件的需要程序的依赖性（此处一个程序依赖于另一个程序的部分或全部的输出）程序的长度和复杂性根据程序员专业知识的水平、工作效率以及对系统熟悉的程序分配程序。由 于经常将程序员分配到其他项目组，从而对专业知识和经验的要求非常广泛，所 以使程序员与程序相匹配并非易事。（26）安排准备程序的进度主程序员可以利用程序进度表（表20. 9.17）来安排和监督下属程序员的活 动以及任一给定程序的状态。由于程序开发有一个基本的模式，所以一种类似于 用来监督项目进度的技术（表20. 9.8和4. 9. 9）可以用来监督完成一个特定程序 的进度。

31、表20. 9. 16绘出的甘特表是程序进度表（表20. 9.17）的一种图形表示， 而且它是在公告板上可以看到的一种通用的管理工具。几乎所有的主程序员和项 目组长都经常使用这种公告板。（27）编制、测试程序和编写程序资料。通常一个程序员在一给定的时间里将同时编制25个程序。开发任一给定 的程序的一般的方法本质上是相同的。它们是：图20. 9. 16程序的甘特进度表准备一般的程序逻辑框图准备详细的程序逻辑框图编写程序（写程序语句）测试和调试程序编写程序的资料4 .第IV阶段一转换和实现第w阶段的目标（转换和实现）是把在第I、n和ni阶段的工作结合成一个整 体，并将信息系统实现到业务领域。项目组和

32、受影响的用户部门大量地介入第w 阶段的全过程中（见图20. 9.段）。表20. 9. 17程序进度表报告标题程序进度表日期系统标题材料要求标识 MR程序标题 标记 程序号 时间 百分 比一般逻辑详细逻辑编写程序测试和调试形成资料估计的开始时间实际的开始时间提前或推迟天数估计的完成时间实际的完成时间提前或推迟的天数每日更新程序 007MR Lois James 50 X X X X X9. 15 9.20 5B 10.30 11.30 21B管理程序 006MR Phil Morrison 100 X X X X X9. 15 9. 15 0T 11. 15 调度程序008MR John 库存状

33、态程序042MR11. 1 10ASpeer 80 10. 1 1. 1Marylou Cummings 4010. 15 10.20 4B 11. 120 X X12. 1 312. 1011.材料清 单程序 102MR Lois James3 11. 15 10B 1. 15日审计程序 001MR Jim Jones 100 周审计程序 002MR John Speer 20 1. 15尽管在第W阶段已经分别测试了系统的各个成分（程序），但这并不能保证把 它们结合成一个整体时系统将正常工作。因此，在第IV阶段来完成整个系统的测 试。在第W阶段期间，项目组将培训用户运行信息系统，转换现有文件

34、以及建立 数据库。在并行工作之后，系统转变到业务领域。（28）完成转换计划转换系统的处理本身就是一个系统，而且应该像最好的结果那样来处理。项 目组与用户管理人员以及信息服务审计组合作，共同研究以设计出一项转换计 划。该计划包括：系统验收测试，文件或数据的转换，用户培训以及并行工作（如 果必要的话）的细节。转换计划详细地细述了用户及信息服务人员的义务和责任, 同时还规定了进行这些事情的时间限制。（29）指导系统验收测试虽然已经测试了各个单独的程序模块，但是还没有把它们结合成一体作为一 个系统来处理。一个信息系统可能有100个以上的程序和一打以上的文件，必须 把它们作为一个整体来处理以保证使工作协

35、调并使用户满意。整体的测试将验证 全部系统软件和应用软件、输入/输出，文件和数据库以及各种过程。在测试期 间用户人员是实际的参加者。在测试过程中，有可能发现错误（忽略了系统的某 些方面），某些过程的缺点将会暴露出来。可以肯定，一部分验收测试过程必须 在系统设计和程序设计方面进行较小的修改。如果系统是正确开发的，那么任何 这种修改将只是微小地调整系统。任何重大的修改应该推迟到系统实现之后，并 且至少在进行生产性工作一年之后再进行。这种推迟避免了通常敲打膝部那种反 作用引起的改变而提交可观的资源。这是因为为了减少重大修改的要求，项目组 长和受影响的用户管理人员将要停止信息系统的每一方面。这时，重大

36、修改的要 求才是一种分界清楚的标志，它表明有人忽略了他们对项目的责任。整个系统的测试实际上是分两个部分完成的。首先利用测试数据来验证每一 个子系统。一旦证实所有子系统的功能是适合的，则有“生存的”数据来测试整 个系统。测试数据是为了测试特定的环境而产生的，而“生存的”数据通常是来 自过去处理使用的实际的数据。在测试联机系统时(此时响应时间是关键问题)，为了测试系统的能力，包括 了用几种生存数据的测试会话。系统可能运行良好，但是由于计算机能力不够大 或是程序的效率不高，也可能导致不可接受的响应时间。(30)设计用户手册项目组设计一套用户手册，并且在对系统验收测试的同时指导用户的培训活 动。每个信

37、息系统都应该有一套用户手册，它们提供有关系统运行的命令和解释。 用户手册和有关的培训对于系统的最后成功是至关重要的。光有一套用户手册是 不够的，这些用户手册还必须是一种高质量的资料，它们能对系统的每一方面提 供快速和容易的参照。用户手册至少包括：系统的目标系统的描述 工作流程和一般的操作方法 完成和理解输入/输出的命令 数据收集和更新的方法 控制 其他(例如，术语唯一的词汇表，硬件的描述和用法，性能的界限，等等)用户手册的内容来自系统资料。然而，在编写和编译这种手册时必须考虑到 能为预期的用户所理解，而且不会被错误地解释。(31)提供用户培训大纲如果不能跟培训相关联，那么用户手册的价值就很小。

38、项目组的成员指导一 系列的培训课程以使得用户熟悉系统。用户培训大纲的一般内容包括：系统的用途和目标 现有系统与新系统的差别 系统工作概述 如何使用用户手册 与系统有关的信息服务人员和用户人员的义务和责任一个有各地分号的大型百货商店实现了一个联机销售点(P0S)系统并将用户 手册分发给每一个P0S终端地点。如果没有正规的培训，销售员将丢下他们自己 的工作而去揣摹用户手册(有100页以上)以了解系统的用途。由于销售人员不能 处理基本事务，于是使得顾客不再等待，而跑到其他地方买货。在他们认识到问 题不在于市场、产品质量或地点之前，百货商店的这些分号几乎要关闭。问题在 于缺乏对系统用户的训练。(32)

39、建立和转换文件或数据库很难找到一个已实现的系统而不需要修改原有的文件或数据库。有些文件和 数据库需要新建，而其他一些则需要从现有的转换成适合的格式。用户部门负责 将手写的数据统一格式并变成机器可谈的形式。用户部门也可能负责抄写和录入 数据的工作。如果数据不是现成可用的或没有用人工存储起来（例如，存放在3 X5的卡片上），那么数据的准备工作可能耗费相当长的时间。在项目组的指导下，用户负责新产生的和转换的那些文件的一致性。数据的 校对是将人眼现场检查与计算机自动校验结合起来进行的。随机抽样检查可以有 效地用于非常大的文件或数据库。在建立和转换处理期间掌握时间是很重要的， 因为一旦建立了一个文件或数

40、据库，此后就必然要对它们进行连续地更新。因此, 最好的策略是：在并行工作开始之前（或者在不要求并行操作的情况下，在系统 实现时）正好完成建立和转换工作。（33）完成并行工作并行工作意味着同时运行原有的系统和新的信息系统。并行工作是常用的手 段，特别是当系统故障相当大地影响到公司的运营时更是如此，在并行工作期间, 用户和信息服务人员被分散开了，因为两个系统都需要维护。完成并行工作是十 分困难的，因为参加的人员仍然处于开始阶段。通常安排并行工作持续一个主要的系统周期（一般是一个月）。项目组长和受 影响的用户管理人员以及有关的信息服务经理监督并行工作的进程。某些单位已 经接受了并行工作至少要进行一个

41、主要周期的方针，而另一些单位则决定维持原 有系统直到经理认为新系统已经全部运行时为止。如果在并行工作期间出现了一次较大的故障，则应中断并行工作并进行有关 的修复工作。由于必须维护文件和数据库，所以及时性是十分重要的。如果公司改进他们的系统测试方法，那么信息服务和用户人员就会自信他们 有能力去实现一个系统。有些公司放弃并行工作，尽管这种做法有很大的危险， 但是这样将把力量集中在成功地实现一个新系统上。在某些情况下，由于时间和 人力有限，不能进行并行工作，因而经理的代替办法是直接实现新系统，并且要 求进行充分的系统测试。5.第V阶段-实现后的评价第V阶段（实现后的评价）常常被忽略。由于其他紧急的信

42、息系统项目需要人 员，往往进行很少的，甚至不进行实现后的评价，不管好坏，系统就被接受了。 实现后的评价或定期系统评价应该是系统开发过程的组成部分。任何信息系统在 刚刚实现之后都将要求做某些“微小的调整”。为此，必须在系统投入生产前， 对它进行评价。因为一旦系统投入使用，即便实现前的测试设计得很好，也不可 能完全暴露出某些在系统投入运行时必将出现的问题。委托并进行评价活动的好 处是获得更高质量的系统并且使用户更为满意。（34）调整成本项目组长调整项目的成本以如实反映I、n、in、w阶段的最终系统开发成 本。此外还将成本汇总以反映出维持系统运行的成本。直到系统实现至少一个月之后，才有可能算出精确的

43、、符合实际的成本数据。（35）指导系统实现后的评价系统实现后的评价（系统的一个关键检查步骤），由从项目组和受影响的用户 部门挑选出的人员来指导进行。在系统运行的头几个月，由于存在着对改革的阻 力，对系统的把握不够以及非预期的问题等，因此，不宜立即进行系统实现后的 评价。通常在第W阶段完成后的36个月之间进行系统实现后的评价。项目组和用户部门挑选和人员并指导系统实现后的评价以决定：实际的与预期的性能的比较。利用在系统设计时已建立起来的某些标准（例信息服务人员的帮助，但是应该再一次强调，业务领域的管理人员应该对各种大 小的服务请求都提供合适的资料。（2）估价服务请求正如在责任矩阵中所注释的那样，信

44、息服务管理人员只能承诺小的项目（由 公司的方针所确定的小项目）。（3）指定可行性研究组信息服务经理和用户经理共同来指定适当的混合的人选以组成可行性分析 研究组。该组至少由一名系统分析员和一名用户代表组成。可行性研究组的大小 取决于可行性研究的范围和时间限制。用户代表应该熟悉当前专业领域的所有工作，用户经理、总经理助理，或专 业领域分析员是合理的候选者，用户的系统分析员，具有计算机信息处理基础知 识的情况已经越来越普遍了。必须指定一个人担任可行性研究组的组长，哪怕只是两个人的可行性研究组 也需要一个组长。直到1980年为止，多数的可行性研究组和项目组是由一个高 级系统分析员或一个项目负责人来领导

45、的。在信息服务部门中，这两种人是固定 分工做这项工作的。目前越来越多的公司采取这样一种政策，即由用户担任项目 组组长。这种将主要责任下放给最终用户的做法将进一步鼓励用户参与系统设 计。在这种政策上取得成功经验的那些公司已经指派了一些具有杰出管理经验和 具有某些计算机和信息处理知识的用户人员担任项目组组长。在任何情况下，组 长必须对该组的工作有一个总的安排。如果要求一个用户代表既作为可行性研究 组或项目组的组长而同时又要求他继续履行业务领域的职责，那么该项目是肯定 要失败的。有好些公司已经采用了一种政策，即自动地指派受系统影响最大的业 务领域的经理作为可行性研究组和项目组的领导以后该经理将从原来

46、的工作职 责中解脱出来，而用他（她）的全部时间管理可行性研究（或项目）组。这种人事安 排已经成为当今的主流，其困难是用户经理需要离开原来主管的业务部门少则两 个月多则三年后才能回他原来的工作岗位上。（4）标列约束条件在系统开发的过程一开始，可行性研究组与信息服务人员和用户经理密切合 作标列出设备、成本、进度、规程、软件以及操作上的约束条件。它们可能限制 建议的系统的定义和设计。（5）整理现有系统的资料整理现有系统资料的主要理由是：如果可行性研究组不充分了解现有系统， 那么他们就不可能有效地完成所建议的系统的初始设计。已经建立起来的多数人 工系统并没有经过真正的设计。在这些系统中，必须从手稿整理

47、出资料。如果一 个建议的系统是改进一个现有的计算机信息系统，那么可行性研究组只需要保证 现有资料的完整性和保持最新版本就行了。现有系统所形成的任何资料将给设计阶段提供有价值的输入（如果批准开发 该系统）。即便建议的系统遭到拒绝，也能对现有系统提供基本的资料，并且可 能透彻地理解理有系统。现有系统的资料由四部分组成：系统报告和资料； 系统数据文件;系统数据元以及说明现有系统的数据、信息和工作流程的图 表。前三部分（报告、文件和数据元）可分类如下：当前使用的，而且在建议的系统中以目前的形式保留下来；当前使用的，但是修改后才在建议的系统中使用；当前使用的，但是在建议的系统中将被删除而不再保留的。例如，列出所有现有的报告和标准的资料，并按上述分类给定一种状态。在如，在峰值工作负荷时的响应时间)，将实际的性能与预期的性能进行比较。系统目标实现的程度。针对在可行性研究中建立的那些目标来评价系统。例 如，系统能否给审计员提供非常及时的信息以进行更好的决策。非预期的利润或耗费。几乎任何基于计算机的系统都将导致非预期的利润和 耗费。这些利益或负荷提供了评价整个信息系统效率的直接输入数据。坦率地计 论错误。很少有在系统开发过程中不犯错误而实现一个系统的。应该将项目组、 用户经理、用户人员、其他信息服务人员或信息服务对策委员会坦率、详细地讨 论的错误编写成资料。列举这些错误并非用