系统开发过程（第八部分）
|
1.15 尽管在第Ⅳ阶段已经分别测试了系统的各个成分(程序)，但这并不能保证把它们结合成一个整体时系统将正常工作。因此，在第Ⅳ阶段来完成整个系统的测试。在第Ⅳ阶段期间，项目组将培训用户运行信息系统，转换现有文件以及建立数据库。在并行工作之后，系统转变到业务领域。 (28)完成转换计划 转换系统的处理本身就是一个系统，而且应该像最好的结果那样来处理。项目组与用户管理人员以及信息服务审计组合作，共同研究以设计出一项转换计划。该计划包括：系统验收测试，文件或数据的转换，用户培训以及并行工作(如果必要的话)的细节。转换计划详细地细述了用户及信息服务人员的义务和责任，同时还规定了进行这些事情的时间限制。 (29)指导系统验收测试 虽然已经测试了各个单独的程序模块，但是还没有把它们结合成一体作为一个系统来处理。一个信息系统可能有100个以上的程序和一打以上的文件，必须把它们作为一个整体来处理以保证使工作协调并使用户满意。整体的测试将验证全部系统软件和应用软件、输入/输出，文件和数据库以及各种过程。在测试期间用户人员是实际的参加者。在测试过程中，有可能发现错误(忽略了系统的某些方面)，某些过程的缺点将会暴露出来。可以肯定，一部分验收测试过程必须在系统设计和程序设计方面进行较小的修改。如果系统是正确开发的，那么任何这种修改将只是微小地调整系统。任何重大的修改应该推迟到系统实现之后，并且至少在进行生产性工作一年之后再进行。这种推迟避免了通常敲打膝部那种反作用引起的改变而提交可观的资源。这是因为为了减少重大修改的要求，项目组长和受影响的用户管理人员将要停止信息系统的每一方面。这时，重大修改的要求才是一种分界清楚的标志，它表明有人忽略了他们对项目的责任。 整个系统的测试实际上是分两个部分完成的。首先利用测试数据来验证每一个子系统。一旦证实所有子系统的功能是适合的，则有"生存的"数据来测试整个系统。测试数据是为了测试特定的环境而产生的，而"生存的"数据通常是来自过去处理使用的实际的数据。 在测试联机系统时(此时响应时间是关键问题)，为了测试系统的能力，包括了用几种生存数据的测试会话。系统可能运行良好，但是由于计算机能力不够大或是程序的效率不高，也可能导致不可接受的响应时间。 (30)设计用户手册 项目组设计一套用户手册，并且在对系统验收测试的同时指导用户的培训活动。每个信息系统都应该有一套用户手册，它们提供有关系统运行的命令和解释。用户手册和有关的培训对于系统的最后成功是至关重要的。光有一套用户手册是不够的，这些用户手册还必须是一种高质量的资料，它们能对系统的每一方面提供快速和容易的参照。用户手册至少包括： ·系统的目标 (31)提供用户培训大纲 如果不能跟培训相关联，那么用户手册的价值就很小。项目组的成员指导一系列的培训课程以使得用户熟悉系统。用户培训大纲的一般内容包括： ·系统的用途和目标 一个有各地分号的大型百货商店实现了一个联机销售点(POS)系统并将用户手册分发给每一个POS终端地点。如果没有正规的培训，销售员将丢下他们自己的工作而去揣摹用户手册(有100页以上)以了解系统的用途。由于销售人员不能处理基本事务，于是使得顾客不再等待，而跑到其他地方买货。在他们认识到问题不在于市场、产品质量或地点之前，百货商店的这些分号几乎要关闭。问题在于缺乏对系统用户的训练。 (32)建立和转换文件或数据库 很难找到一个已实现的系统而不需要修改原有的文件或数据库。有些文件和数据库需要新建，而其他一些则需要从现有的转换成适合的格式。用户部门负责将手写的数据统一格式并变成机器可谈的形式。用户部门也可能负责抄写和录入数据的工作。如果数据不是现成可用的或没有用人工存储起来(例如，存放在3×5的卡片上)，那么数据的准备工作可能耗费相当长的时间。 在项目组的指导下，用户负责新产生的和转换的那些文件的一致性。数据的校对是将人眼现场检查与计算机自动校验结合起来进行的。随机抽样检查可以有效地用于非常大的文件或数据库。在建立和转换处理期间掌握时间是很重要的，因为一旦建立了一个文件或数据库，此后就必然要对它们进行连续地更新。因此，最好的策略是：在并行工作开始之前(或者在不要求并行操作的情况下，在系统实现时)正好完成建立和转换工作。 (33)完成并行工作 并行工作意味着同时运行原有的系统和新的信息系统。并行工作是常用的手段，特别是当系统故障相当大地影响到公司的运营时更是如此，在并行工作期间，用户和信息服务人员被分散开了，因为两个系统都需要维护。完成并行工作是十分困难的，因为参加的人员仍然处于开始阶段。 通常安排并行工作持续一个主要的系统周期(一般是一个月)。项目组长和受影响的用户管理人员以及有关的信息服务经理监督并行工作的进程。某些单位已经接受了并行工作至少要进行一个主要周期的方针，而另一些单位则决定维持原有系统直到经理认为新系统已经全部运行时为止。 如果在并行工作期间出现了一次较大的故障，则应中断并行工作并进行有关的修复工作。由于必须维护文件和数据库，所以及时性是十分重要的。 如果公司改进他们的系统测试方法，那么信息服务和用户人员就会自信他们有能力去实现一个系统。有些公司放弃并行工作，尽管这种做法有很大的危险，但是这样将把力量集中在成功地实现一个新系统上。在某些情况下，由于时间和人力有限，不能进行并行工作，因而经理的代替办法是直接实现新系统，并且要求进行充分的系统测试。 5.第Ⅴ阶段-实现后的评价 第Ⅴ阶段(实现后的评价)常常被忽略。由于其他紧急的信息系统项目需要人员，往往进行很少的，甚至不进行实现后的评价，不管好坏，系统就被接受了。实现后的评价或定期系统评价应该是系统开发过程的组成部分。任何信息系统在刚刚实现之后都将要求做某些"微小的调整"。为此，必须在系统投入生产前，对它进行评价。因为一旦系统投入使用，即便实现前的测试设计得很好，也不可能完全暴露出某些在系统投入运行时必将出现的问题。委托并进行评价活动的好处是获得更高质量的系统并且使用户更为满意。 (34)调整成本 项目组长调整项目的成本以如实反映Ⅰ、Ⅱ、Ⅲ、Ⅳ阶段的最终系统开发成本。此外还将成本汇总以反映出维持系统运行的成本。 (35)指导系统实现后的评价 系统实现后的评价(系统的一个关键检查步骤)，由从项目组和受影响的用户部门挑选出的人员来指导进行。在系统运行的头几个月，由于存在着对改革的阻力，对系统的把握不够以及非预期的问题等，因此，不宜立即进行系统实现后的评价。通常在第Ⅳ阶段完成后的3～6个月之间进行系统实现后的评价。 项目组和用户部门挑选和人员并指导系统实现后的评价以决定： 实际的与预期的性能的比较。利用在系统设计时已建立起来的某些标准(例如，在峰值工作负荷时的响应时间)，将实际的性能与预期的性能进行比较。 系统目标实现的程度。针对在可行性研究中建立的那些目标来评价系统。例如，系统能否给审计员提供非常及时的信息以进行更好的决策。 非预期的利润或耗费。几乎任何基于计算机的系统都将导致非预期的利润和耗费。这些利益或负荷提供了评价整个信息系统效率的直接输入数据。坦率地计论错误。很少有在系统开发过程中不犯错误而实现一个系统的。应该将项目组、用户经理、用户人员、其他信息服务人员或信息服务对策委员会坦率、详细地讨论的错误编写成资料。列举这些错误并非用来追究某个人或某团体的责任，而只是着重强调为什么会产生这些错误以及可以做些什么努力以便在今后的项目中消除这些错误。 系统实现后的评价被提交给信息服务经理和用户经理以便采取适当的措施。 (36)准备系统检查的计划 很多数据处理系统和信息系统在实现之后都保持原样，而没有作出任何共同的努力去显著地提高它们。在这些系统中，所谓的改进工作是不超出例行维护的范围的，而且是由于用户的反映才作的。这种被动地改进系统的方法其效率远比由定期的系统检查来保证的主动的方法要差得多。有很多原因会导致忽视定期检查，因此，应该通过一个正式的书面检查计划来督促进行检查。两次检查之间的间隔时间是根据系统的复杂性和易变性来决定的。 定期系统检查是业务领域管理人员的责任。由检查所产生的各种建议将最终反映在由用户管理人员提交的一个服务请求中。 |