办公文档范本系统开发过程.docx

《办公文档范本系统开发过程.docx》由会员分享，可在线阅读，更多相关《办公文档范本系统开发过程.docx（18页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

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

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

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

4、是必要的。该初步设计是第H阶段一系统分析和设计的直接 输入。将系统的初步设计并入可行性研究的依据是，多数可行性研究是以概念而不是以设计为 基础的。如果在描述系统目标上花的时间太少，那么成本估计，甚至利润估计将是错误的。 用概念来指导可行性研究注定会导致成本过高，而且用户不满意。在系统初步设计上所花费 的时间是值得的，即使拒绝可行性研究也是如此。因为所编写的资料将必然会被证实其他相 关本次项目中是有价值的。下述编号的活动与表20. 9. 2的系统开发责任矩阵相对应。（1）提交服务请求图20. 5.1说明了包括对受拒绝的请求再次请求处理的一种方法。所请求的服务毕竟是 用户做的，因此，应该由用户着手

5、进行。我们鼓励用户管控管理管控相关有关人员请求信息 服务相关有关人员的帮助，但是应该再一次强调，业务领域的管控管理管控相关有关人员应 该对各种大小的服务请求都提供合适的资料。 （2）估价服务请求正如在责任矩阵中所注释的那样，信息服务管控管理管控相关有关人员只能承诺小的相 关本次项目（由公司的方针所确定的小相关本次项目）。（3）指定可行性研究组信息服务经理和用户经理共同来指定适当的混合的人选以组成可行性分析研究组。该组 至少由一名系统分析员和一名用户代表组成。可行性研究组的大小取决于可行性研究的范围 和时间限制。及业务领域的管控管理管控相关有关人员密切合作以保证在系统开发过程中在各关键点有 足够

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

7、了对具有阶段标志E的那些活动的一个详细的信息系统相关本次项目进度表。表20.9. 8信息系统相关本次项目进度表阶段+具有阶段标志完成的活动阶段标志活动 估计的开始时间 完成日期实际完A 1 2 3 4 5 .10. 1 198W. 10. 15实际的 开始时间 提前或 推迟的 天数 估计的 成的日期提前或推迟的天数B 6 7 8C 1112198X. 12. 259 10198W. 9. 1 198W. 9. 1 DS12B198W. 10. 1 198W. 10. 20198WB1314151617MB 18198W. 11. 1 198X. 12. 1 22B19198X. 9. 1519

8、8 Y. 9. 113AD E FG HI 1B20242830333421252931198X. 12. 20 3A22 23 198Y. 1. 15 198Y. 1. 1526 27 198Y. 3. 1 198Y. 6. 30198Y. 6. 1 198Y. 7. 1532 198Y. 6. 25 198Y. 9. 10198Y. 10. 1 198Y. 10. 3135 36 198Y. 11. 1 198Z. 2. 1二已开始的活动DS198Y. 2. 15X二已完成的活动0二不相关要求采取措施+对应于图20. 9. 3中的方法学*直到实现可行性研究之前，并不进行第II阶段活动V的估

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

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

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

12、降低估计的误差。估计是取中间值或（在适合时）取平均值。估计的误差是包含危险的一种标志。（15）与用户相关有关人员交谈与用户交谈的过程从本活动开始。为了解决问题和确定系统相关要求，相关本次项目组 成员定期与有关用户见面。与用户交谈及反馈的过程贯穿于系统开发的全过程。对于详细设计的基本输入是：（A）初始设计（来自可行性研究），（B）对现有系统及其成分 的评价（也是来自可行性研究）以及（C）输入、处理以及输出的相关要求（由用户提供）。相关本次项目组与有关的用户相关有关人员检查在可行性研究的初始设计中所描述 的输入/输出相关要求和频率，并根据需要及价值对每一种输入/输出进行评价。许多输出是 “有了更好

13、”，但是却不值得去产生它们。还可以根据周期和时帧来估计输入/输出。通过估 计频率/价值比的平衡来优化周期的输入和输出。例如，如果每周情况报告可以满足需要， 那么就没有必要再产生每天的情况报告。在联机系统中，检查响应时间相关要求以确定这种 时间相关要求是否太紧迫，能否适当放宽相关要求而又致于对运行效率产生较大的影响；或 者确定这种响应时间的相关要求是否不能满足。目前系统的资料对设计提供了有价值的输入。现有的报告、表格、原始资料等等，实 际上能够追踪最终用户以便确定该资料是否合适，是否及时等。如果是，还能做哪些工作来 改进它们?相关本次项目组相关相关本次项目对现有的所有输入和输出进行修改。通过合并

14、 类似的输入和（或）输出以及消除多余的信息尽可能地减少重复。初步交谈的一个直接结果是对所建议的系统所有的输出一般的描述（报告，显示或事 务）。根据周期、初始用户、输出介质、有关内容以及分布来描述每一种输出。（16）说明数据库相关要求数据库用来支持系统的处理，特别是支持系统的输出。在目前系统的资料中包含了可继 续使用的数据元。许多现有数据元的格式肯定是需要改变的，还需要将支持系统功能相关要 求所需要的其他数据元标列出来。相关本次项目组设计和编制数据字典,在一部数据字典中所列出的数据具有维持每个数 据元的基本信息，而它们与数据库或文件的组织形式无关。在表20. 9.10给出的数据字典的 例子中，包

15、括对每个数据元指定了一个各自的前后参照号、标题、描述（如果必要的话）、是 否被编码、程序设计标识、存储单元（字符）数、格式和存储器大小（程序最初使用的）以及职 责等。用户必须给出相关相关本次项目的人或机构部门机构、存储单元以及是否对数据元编 码等事项。表的数据字典形式，也可以用来交叉引用在所有原始资料、报告、文件 以及数据库中出现的每一个数据元。 在标列出所有的数据元之后，相关本次项目组与数 据库管控管理管控员合作来进行记录格式和文件的设计，或者，在数据库环境下，他们设计 数据库的模式。此活动的输出是数据字典以及有关文件和（或）数据库模式的一份详细的技术 描述。表数据字典报告标题数据字典日期系

16、统标题标识编号标题 描述 编码否标记字符数 字形/格式存储 职责原始资料(S)、报告(R)、文件(F)、或数据库(D)工资支票(R)工资登记簿(R)工资主文件(F)会计文件(F)工时卡(S)1社会保险号职工否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)建立控制和后援的方法为了保证

17、信息系统的正确性、可靠性和完整性，在设计时就要考虑加进控制手段。相关 本次项目组将说明在系统设计时要嵌入所有物理上的和行政管控管理管控上的控制。在系统 的输入、处理和输出阶段用以控制系统的技术的范围是广泛的。在处理之前核对输入，在处 理期间使用诸如合理性检查以及数字位检查等技术以便最小化或消除在计算或处理中的过 失误差，记录计数和长度核对是用来保证输出正确性的许多技术的代表。为了避免在系统故障期间造成破坏，需要确定后援(备份)和校验点/重新启动的方法。 这些方法描述了包含在系统中的克服故障的额外处理，在系统故障的情况下，利用备份文件 和(或)备份事务日记从上一个“校验点”来重新建立处理。在上一

18、个校验点“重新启动”系 统，并重新开始正常的运行。在系统处理周期期间，定期地建立校验点将会使系统及时地保 留在该点的所有处理，而且不会被破坏。(18)完成详细设计详细的系统设计是分析输入/输出、处理、控制和后援相关要求的结果。系统初步设计 或系统一般设计只描绘了各主要处理活动之间的关系，而系统详细设计则扩展到包括所有处 理活动和有关的输入/输出。这是系统开发过程的基础活动。正是这一步，将功能说明书与 技术上和方法上的新设施结合一起以实现一个系统。详细设计是前面所有工作的归宿。此外, 它也是该相关本次项目今后所有活动的一张蓝图。在活动5中提到了用图形说明系统设计所使用的若干技术(但没有详细讨论)

19、。这里我们 简单地讨论其中三种技术一一审批相关流程图。111Po以及渥宁(W.nier)图。用来形象地描 述工作审批相关流程和总的系统设计的最流行的技术是审批相关流程图。审批相关流程图使 用刻画系统逻辑的一些专用符号并通过流线把这些符号相互连接起来以说明工作审批相关 流程和数据审批相关流程。图20. 9.11给出了系统审批相关流程图符号的一个子集。在图 20. 9. 12中，用审批相关流程图描绘了一个已投入运行的工资系统的一部分。审批相关 流程图有一定的缺点。不像前面所讨论的其他两种技术，审批相关流程图并不鼓励分析员使 用系统设计的自上而下或模块化的方法。因此，用审批相关流程图方法来设计系统，

20、不仅难 于设计，而且设计出的系统也难于理解和维护。审批相关流程图之所以较为流行，主要是由 于它是最早出现的设计方法。层次式输入一处理一输出法（又称HIPO法）是在一层次体系中将系统设计按其详细程度 分层，依次地说明所有的输入、处理和输出的一种方法。图说明了一个工资系统的 HIP0卷有关内容表（VTOC）。VT0C是在HIP0设计方法中所使用的几种标准形式之一。整个系 统被划分成由若干逻辑模块所组成的一个层次体系，并用VT0C来描绘。此后，利用粗框图 和细框图还可以将这些模块进一步划分成更细小一层的输入一处理一输出的细目。通常由若 干个VT0C将设计的层次体系统推进到依次的细目层。从HIP0结构

21、化方法所得到的好处往往 被编写系统资料所需要的大量繁琐的文书工作所抵消了。Warnier框图（在图中说明）可以用来设计整个系统、数据结构、报表有关内容 以及数据元的编码。使用Warnier框图的依据是：应该围绕着数据结构来设计系统。Warnier 框图的最大优点是对各种环境的适用性。图20. 9.15中的例子是一个扩展项判定表，它是许 多判定表中的一种，一个判定表有一个条件分叉（在表的左上方）和活动分叉（在表的左下 方），一个条件项（右上方）以及一个活动项（右下方）。判定表并不是一个说明数据流和工作 流的有效的工具，最好把它作为其他设计方法的补充。判定表的主要好处是必须考虑到每一 种可能的替换

22、者、选择、条件、变元等。与审批相关流程图，HIP0图以及其他设计方法不 同使用Waraier框图法，系统分析员不必考虑细节。图20. 9.11部分系统审批相关流程图符号图20. 9.12简化的工资支付系统审批相关流程图工资系统系统开始每月处理月初每周处理提交时间卡片数据录入按工时处 理职工记录 工资支票 工资联单 更新工资文件 月末 按月薪处理职工记录 工资支 票 工资联单 更新工资文件 系统结束图 20.9. 14 Warnier 框图图20.9. 13 HIP0：卷有关内容表上面讨论的分析工具代替了一大段解说词，而通常对解说词的理解容易产生混淆。然而, 精心设计的解说词可以而且应该用来支持

23、图形设计技术。没有一种分析和设计的技术是最好的，最好的分析和设计技术是适合一个公司具体情况 的各种技术的组合。总之，模块化的自顶向下方法是当今必不可少的。按自顶向下方法进行 设计时，通过最高一级的管控管理管控者来建立基本的系统目标，然后根据在公司每一级收 集的输入数据，在设计中增加后继的细目层。由于作为一个整体概念多数系统过于复杂，所 以将系统分成若干个更容易理解的模块。模块化的主导思想是“各个击破”，而这是行之有 效的。（19）指导用户或信息服务机构部门机构预演。表20. 9. 15 一张判定表支付类型工资按工时处理佣金时帧周末月末周末月末周末月末打印工资支票XXXXX打印工资联单XXXX结

24、构预演是一种预测评价方法，它能有效地减少某些被忽略的或作错的事情。它也给预 测者提供一个机会来评价那些业已建议的事情（如系统设计），从而有可能给出一些建设性的 建议。预演的目的是给相关本次项目组提供有价值的反馈信息，而不是对系统的质量下判决 性的结论。 相关本次项目组长应考虑何时开始结构预演。通常预演是在系统设计以及系 统开发过程中其他一些关键点（如，测试计划、程序描述等）完成之后才进行。参与结构预演中的人有：若干相关本次项目组成员，一个协调员，参加者，一位秘书, 或许还包括一位不属双方的“中立的”经理。相关本次项目组的某个成员或所有成员扮演“推 荐者”的角色，并且解释他们所承担设计的系统的那

25、一部分。协调员相关相关本次项目组织 预演和协调“推荐者”与“参加者”之间的相互配合。根据对所提出的课题的知识和兴趣来 选择“参加者:这些人应该是没有直接参与本相关本次项目的。秘书将对一些要点作书面 记录。通常邀请一个“中立的”经理参加第一次预演。中立经理的出席将促使参与预演的每 一个人专心于他的工作（这一点有时是预演的一个问题）O结构预演的方法是简单的。在进行预演的前几天将需要审查的材料（即系统设计）分发给 参加者，协调员相关相关本次项目跟参加预演的所有人联系和通信。在实际的预演期间，推 荐者解释系统设计以及有关的资料。这是通过一步一步地预演系统来进行的，有时可能还借 助于某种设计工具。参加者

26、提供出讨论的建议，而秘书则记录下来以形成资料。通常一次预 演持续的时间不应超过一个半小时。如果超过了这个时间限制，那么一次预演会议将变得没 有实际效果。如果必要，可以安排儿次会议来完成预演。相关本次项目组评价所有的建议，并且把所有价值的建议并入到系统设计中。预演是有 价值的，它使得设计者在系统实现之前获得重要的反馈信息。（20）选择硬件如果正在开发的系统相关要求额外的硬件支持，则需要选择适当的硬件并进行订货。获 得硬件的过程通常是信息服务经理的责任。（21）准备输出格式在系统开发过程中，到目前这一阶段为止，我们已经提及了输出并描述了其有关的有关 内容，但是程序员需要知道具体的输出形式（即应该怎

27、样在输出设备上出现）。这种详细的输 出说明称之为输出格式。相关本次项目组产生出显示屏（VDU）格式，这种格式规定了诸如题 目、标题、输出形式等项，有时还应包括输入形式。某些硬拷贝报告和资料相关要求事先打印好的表格纸，相关本次项目组与表格纸厂商的 代表合作设计这种事先打印好的表格纸（例如，工资支票和短线）o相关本次项目组还相关相关本次项目设计和满足在系统范围内所有人工产生的报告和 资料，同时与受有影响的用户经理相配合进行修改、增加或删除。（22）描述数据项的说明书数据项的说明书详细规定了什么数据将输入到系统以及它们怎样被输入到系统中。（23）准备程序描述系统开发进展到目前这一步，我们已经对现有的

28、系统作了详尽的分析。它的功能已经并 入建议的系统的设计中，我们已经完成了建议的系统及其支持的数据库的设计，并且还准备 了所有输入/输出详细的说明书。现在相关本次项目组可以着手标列和确定所有的程序，而 这些程序是使得建议的信息系统运转所相关要求的。系统的图形表示（审批相关流程图、HIP0 图和其他）是标列所相关要求的程序的初始输入。对每一个程序，相关本次项目组编辑下述 的资料：程序语言的种类（例如，COBOL. BASIC、FORTRAN）程序解说词的描述一描述要执行的任务。由程序所产生的各种输出的描述和格式处理频率（例如，每天、每周、联机等）界限和限制（例如，输入数据的顺序，容量的限制，响应时

29、间，最大值，最小值等）详细说明书（例如，排序，编辑的标准，特殊的计算和逻辑操作，各种表格等）。3 .第HI阶段一程序设计相关本次项目组现在可以着手开始与计算机通信了。这种通信（或与计算机的接口）是采 取指令形式来进行的，而这些指令被编进计算机程序中。这些计算机程序包括系统运转所必 需的软件。在第III阶段一程序设计阶段将开发支持信息系统所相关要求的全部软件。用户的介入集中在系统开发的过程前段（第n阶段）和后段（第w和v阶段）o如果正确地 完成了第n阶段而且用户与相关本次项目组的协作是有“成效”的，那么用户将很少介入程 序设计阶段，甚至完全不用介入。用户介入最多的情况将反复出现在系统设计需要澄清

30、的时 候，有时也出现为第IV阶段（转换与实现），作一些初始计划的时候。不幸的是，有时用户管控管理管控相关有关人员也较深地卷进了程序设计阶段。这是第 n阶段进行得很糟糕，而且当开始程序设计时还没完成的一种标志。这种情况是经常发生的, 特别是在时间紧迫时，相关本次项目组常常收到一些强制性的命令相关要求产生尚未完成的 质量本协议合同支付资金服务。由于系统开发过程的最终质量本协议合同支付资金服务是软 件，所以有时过早地开始程序设计。这种系统开发正式正式合约生效必然导致产生质量低劣 的系统。这种系统并不能满足用户的相关要求，而且维护的代价很高。这种系统整个寿命期 的成本可能是一个高质量的系统的两到三倍。

31、（24）指定程序员组长通常相关本次项目组长是一个系统分析员或是一个用户，他并不直接参与程序设计工 作。管控管理管控程序设计工作的人应该是程序设计工作实际的参加者，因此，对于相关要 求两个人以上的程序设计工作，将由信息服务经理指定一个程序员组长。当然，相关本次项 目组长仍然对整个相关本次项目负有责任。 程序员组长有时也称作为主程序员。他（或 她）可能只花10%的时间在质量本协议合同支付资金服务的程序设计上。如果只需要管控管 理管控一个下属程序员，那么主程序员可能花80%的时间在质量本协议合同支付资金服务的 程序设计上。 （25）安排顺序和分配程序一个信息系统的软件包，可能相关要求几百个程序。并不

32、需要按照这些程序最终执行的 顺序来编写它们，在建立程序开发进度表时，必须考虑到许多变更修改的因素。在安排程序 编制顺序时，主程序员应考虑如下问题：建立和维护测试文件的需要程序的依赖性（此处一个程序依赖于另一个程序的部分或全部的输出）程序的长度和复杂性根据程序员专业知识的水平、工作效率以及对系统熟悉的程序分配程序。由于经常将程 序员分配到其他相关本次项目组，从而对专业知识和经验的相关要求非常广泛，所以使程序 员与程序相匹配并非易事。（26）安排准备程序的进度主程序员可以利用程序进度表（表20.9.17）来安排和监督下属程序员的活动以及任一 给定程序的状态。由于程序开发有一个基本的模式，所以一种类

33、似于用来监督相关本次项目 进度的技术（表和4.9. 9）可以用来监督完成一个特定程序的进度。表20.9. 16绘出 的甘特表是程序进度表（表20.9. 17）的一种图形表示，而且它是在公告板上可以看到的一种 通用的管控管理管控工具。几乎所有的主程序员和相关本次项目组长都经常使用这种公告 板。（27）编制、测试程序和编写程序资料。通常一个程序员在一给定的时间里将同时编制25个程序。开发任一给定的程序的一 般的方法本质上是相同的。它们是：图20. 9. 16程序的甘特进度表准备一般的程序逻辑框图准备详细的程序逻辑框图编写程序（写程序语句）测试和调试程序编写程序的资料4 .第W阶段一一转换和实现第w

34、阶段的目标（转换和实现）是把在第I、n和in阶段的工作结合成一个整体，并将信 息系统实现到业务领域。相关本次项目组和受影响的用户机构部门机构大量地介入第w阶段 的全过程中（见图20. 9. 17）0表20. 9. 17程序进度表报告标题程序进度表日期系统标题材料相关要求标识 MR程序标题标记程序号时间百分比一般逻辑详细逻辑编写程序测试和调试形成资料估计的开始时间实际的开始时间提前或推迟天数 估计的完成时间实际的完成时间提前或推迟的天数每日更新程序 007MR Lois James 50 X X X X X9. 15 9.20 5B 10.30 11.30 21B管控管理管控程序 006MR P

35、hil Morrison 100 X X X X X 9. 15 9. 15 0T 11. 15 11. 1 10A调度程序 008MR John Speer 80 10. 1 1. 1库存状态程序 042MR Mary 1 ou Cummings 40 X X /10. 15 10.20 4B 11. 1材料清 单程序 102MR Lois James 20 X X 11.3 11. 15 10B 1. 15日审计程序 001MR Jim Jones 100 12. 1 3周审计程序 002MR John Speer 20 12. 101. 15尽管在第IV阶段已经分别测试了系统的各个成分（

36、程序），但这并不能保证把它们结合成 一个整体时系统将正常工作。因此，在第IV阶段来完成整个系统的测试。在第IV阶段期间， 相关本次项目组将培训用户运行信息系统，转换现有文件以及建立数据库。在并行工作之后, 系统转变到业务领域。（28）完成转换计划转换系统的,理本身就是一个系统，而且应该像最好的结果那样来处理。相关本次项目 组与用户管控管理管控相关有关人员以及信息服务审计组合作，共同研究以设计出一项转换 计划。该计划包括：系统本协议合同支付资金服务测试，文件或数据的转换，用户培训以及 并行工作（如果必要的话）的细节。转换计划详细地细述了用户及信息服务相关有关人员的义 务和责任，同时还规定了进行这

37、些事情的时间限制。（29）指导系统本协议合同支付资金服务测试虽然已经测试了各个单独的程序模块,但是还没有把它们结合成一体作为一个系统来处 理。一个信息系统可能有100个以上的程序和一打以上的文件，必须把它们作为一个整体来 处理以保证使工作协调并使用户满意。整体的测试将验证全部系统软件和应用软件、输入/ 输出，文件和数据库以及各种过程。在测试期间用户相关有关人员是实际的参加者。在测试 过程中，有可能发现错误（忽略了系统的某些方面），某些过程的缺点将会暴露出来。可以肯 定，一部分本协议合同支付资金服务测试过程必须在系统设计和程序设计方面进行较小的修 改。如果系统是正确开发的，那么任何这种修改将只是

38、微小地调整系统。任何重大的修改应 该推迟到系统实现之后，并且至少在进行生产性工作一年之后再进行。这种推迟避免了通常 敲打膝部那种反作用引起的改变而提交可观的资源。这是因为为了减少重大修改的相关要 求，相关本次项目组长和受影响的用户管控管理管控相关有关人员将要停止信息系统的每一 方面。这时，重大修改的相关要求才是一种分界清楚的标志，它表明有人忽略了他们对相关 本次项目的责任。整个系统的测试实际上是分两个部分完成的。首先利用测试数据来验证每一个子系统。 一旦证实所有子系统的功能是适合的，则有“生存的”数据来测试整个系统。测试数据是为 了测试特定的环境而产生的，而“生存的”数据通常是来自过去处理使用

39、的实际的数据。在测试联机系统时（此时响应时间是关键问题），为了测试系统的能力，包括了用几种生 存数据的测试会话。系统可能运行良好，但是由于计算机能力不够大或是程序的效率不高, 也可能导致不可接受的响应时间。（30）设计用户手册相关本次项目组设计一套用户手册，并且在对系统本协议合同支付资金服务测试的同时 指导用户的培训活动。每个信息系统都应该有一套用户手册，它们提供有关系统运行的命令 和解释。用户手册和有关的培训对于系统的最后成功是至关重要的。光有一套用户手册是不 够的，这些用户手册还必须是一种高质量的资料，它们能对系统的每一方面提供快速和容易 的参照。用户手册至少包括： 系统的目标 系统的描述

40、 工作审批相关流程和一般的操作方法 完成和理解输入/输出的命令 数据收集和更新的方法 控制其他（例如，术语唯一的词汇表，硬件的描述和用法，性能的界限，等等）用户手册的有关内容来自系统资料。然而，在编写和编译这种手册时必须考虑到能为预 期的用户所理解，而且不会被错误地解释。（31）提供用户培训大纲如果不能跟培训相关联，那么用户手册的价值就很小。相关本次项目组的成员指导一系 列的培训课程以使得用户熟悉系统。用户培训大纲的一般有关内容包括：系统的用途和目标 现有系统与新系统的差别 系统工作概述 如何使用用户手册 与系统有关的信息服务相关有关人员和用户相关有关人员的义务和责任一个有各地分号的大型百货商

41、店实现了一个联机销售点（POS）系统并将用户手册分发给 每一个POS终端地点。如果没有正规的培训，销售员将丢下他们自己的工作而去揣摹用户手 册（有100页以上）以了解系统的用途。由于销售相关有关人员不能处理基本事务，于是使得 顾客不再等待，而跑到其他地方买货。在他们认识到问题不在于市场、质量本协议合同支付 资金服务质量或地点之前，百货商店的这些分号几乎要关闭。问题在于缺乏对系统用户的训 练。（32）建立和转换文件或数据库很难找到一个已实现的系统而不需要修改原有的文件或数据库。有些文件和数据库需要 新建，而其他一些则需要从现有的转换成适合的格式。用户机构部门机构相关相关本次项目 将手写的数据统一

42、格式并变成机器可谈的形式。用户机构部门机构也可能相关相关本次项目 抄写和录入数据的工作。如果数据不是现成可用的或没有用人工存储起来（例如，存放在3 X5的卡片上），那么数据的准备工作可能耗费相当长的时间。在相关本次项目组的指导下，用户相关相关本次项目新产生的和转换的那些文件的一致 性。数据的校对是将人眼现场检查与计算机自动校验结合起来进行的。随机抽样检查可以有 效地用于非常大的文件或数据库。在建立和转换处理期间掌握时间是很重要的，因为一旦建 立了一个文件或数据库，此后就必然要对它们进行连续地更新。因此，最好的策略是：在并 行工作开始之前（或者在不相关要求并行操作的情况下，在系统实现时）正好完成

43、建立和转换 工作。（33）完成并行工作并行工作意味着同时运行原有的系统和新的信息系统。并行工作是常用的手段，特别是 当系统故障相当大地影响到公司的运营时更是如此，在并行工作期间，用户和信息服务相关 有关人员被分散开了，因为两个系统都需要维护。完成并行工作是十分困难的，因为参加的 相关有关人员仍然处于开始阶段。通常安排并行工作持续一个主要的系统周期（一般是一个月）。相关本次项目组长和受影 响的用户管控管理管控相关有关人员以及有关的信息服务经理监督并行工作的进程。某些单 位已经接受了并行工作至少要进行一个主要周期的方针，而另一些单位则决定维持原有系统 直到经理认为新系统已经全部运行时为止。如果在并

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

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

46、后的评价系统实现后的评价(系统的一个关键检查步骤)，由从相关本次项目组和受影响的用户机 构部门机构挑选出的相关有关人员来指导进行。在系统运行的头几个月，由于存在着对改革 的阻力，对系统的把握不够以及非预期的问题等，因此，不宜立即进行系统实现后的评价。 通常在第W阶段完成后的36个月之间进行系统实现后的评价。相关本次项目组和用户机构部门机构挑选和相关有关人员并指导系统实现后的评价以 决定：实际的与预期的性能的比较。利用在系统设计时已建立起来的某些标准(例如，在峰值 工作负荷时的响应时间)，将实际的性能与预期的性能进行比较。系统目标实现的程度。针对在可行性研究中建立的那些目标来评价系统。例如，系统

47、能 否给审计员提供非常及时的信息以进行更好的决策。非预期的利润或耗费。几乎任何基于计算机的系统都将导致非预期的利润和耗费。这些 利益或负荷提供了评价整个信息系统效率的直接输入数据。坦率地计论错误。很少有在系统 开发过程中不犯错误而实现一个系统的。应该将相关本次项目组、用户经理、用户相关有关 人员、其他信息服务相关有关人员或信息服务对策委员会坦率、详细地讨论的错误编写成资 料。列举这些错误并非用来追究某个人或某团体的责任，而只是着重强调为什么会产生这些 错误以及可以做些什么努力以便在今后的相关本次项目中消除这些错误。系统实现后的评价被提交给信息服务经理和用户经理以便采取适当的措施。(36)准备系统检查的计划很多数据处理系统和信息系统在实现之后都保持原样，而没有作出任何共同的努力去显 著地提高它们。在这些系统中，所谓的改进工作是不超出例行维护的范围的，而且是由于用 户的反映才作的。这种被动地改进系统的方法其效率远比由定期的系统检查来保证的主动的 方法要差得多。有很多原因会导致忽视定期检查，因此，应该通过一个正式的书面检查计划 来督促进行检查。两次检查之间的间隔时间是根据系统的复杂性和易变性来决定的。定期系统检查是业务领域管控管理管控相关有关人员的责任。由检查所产生的各种建议 将最终反映在由用户管控管理管控相关有关人员提交的一个服务请求中。用户代表应该熟