网络开发人员工作细则.doc

网络开发人员工作细则附件1：网络开发人员工作流程图综合副总信息系统开发综合信息中心经理网络开发人员岗位职责系统开发责任系统开始与可行性研究系统分析和设计系统开发责任程序设计系统审查评价转换和实现实验后评价附件2：系统开发的责任在系统开发的过程中何时涉及到个人、小组和部门以及涉及到的限度，并针对每一种活动提出了所涉及的人员和机构。其中：对于那些有较大失败危险的非结构化的项目，则需要设立更多的阶段标志。下面描述一个人员和机构的含义。1、可行性研究组。这个组由指定来完毕可行性研究的用户和信息服务人员组成。2、项目组。由指定来开发和实现计算机信息系统或对现有系统作重要改善的用户和信息服务人员组成。3、住处服务管理部门。该机构涉及到信息服务管理组，而不一定指某个具体人。在一个小单位中，它也许局限于信息服务的一些高级负责人。在一个大单位中，经理最适合于承担机构所涉及的特定的任务。4、未指派的程序员和分析员，涉及未指派到所讨论的可行性研究组和项目组的他的信息服务专职人员。5、业务领域管理人员。所有影响到建议开发项目的或者受该项目的业务领域的管理人员都涉及在本责任机构中。6、未指派的专业人员。涉及将影响到建议的开发项目或受该项目的影响的那些专业人员，但他们并未旨派到可行性研究组或项目组。7、住处系统政策委员会。信息系统政策委员会是对公司所有的信息服务的和一个高级指导委员会。8、信息系统审计组。信息服务审计组的一个重要职能是保证在开发过程中对计算机信息系统建立适当的控制。附件3：系统开发过程 五个阶段 各种系统开发方法学在范围、复杂性、完善限度以及方法上有很大的不同。尽管有的方法学分三个阶段，有的分15个阶段，但是每个方法学所描述的要完毕的活动基本上是相同的。本章要阐述的最重要的一点是:最佳的方法学是那些始终把用户考虑进去的方法学。过去的情况是，用户管理人员与信息服务开发组合作来完毕系统的一般功能说明书，然后，由信息服务人员来进行系统开发。现在，系统开发是各占50%的比例;因此，用户管理人员应当非常熟悉系统开发的大体过程，特别应当熟悉他们单位自己使用的方法学。 系统开发过程可分为五个阶段来描述。这五个阶段是: 1第一阶段一系统开始和可行性研究 2第二阶段一系统分析和设计 3第三阶段一程序设计 4第四阶段一转换和实现 5第五阶段一实现后的评价 第一阶段一系统开始和可行性研究是在为开发一个建议的系统提供人力和资源之前完毕的。第一阶段多数的工作和编写的资料是第二阶段的输入。在第二阶段一系统分析和设计期间，系统分析员与用户一起工作以编写具体的功能和系统的说明书。将这些说明书交给程序员，然后开始第三阶段程序设计。在第二阶段一转换和实现期间，一旦软件开发出来，则建立数据文献，转换现有系统，并且实现新系统。第五阶段一实现后的评价。在开始了系统寿命期中的生产阶段之后，提出(经常被忽略的)实现后的评价规定。 具体开发过程 下面将逐步地描述系统开发过程。至于具体的细节、互相的影响、方法、形式等，用户管理人员应当与信息服务经理联系，与他们讨论公司当前使用的方法学，同时再看看公司内部描述方 学的手册。 第1阶段一系统开始和可行性研究 在第I阶段的活动中很少有与其他四个阶段的活动相一致的。此处所提供的方法涉及对于受拒绝后的再次服务请求的方法以及将技术转移也许性的研究合并到诸过程中这些内容。第I阶段最终的产品有两个部分。第一部分是实际的可行性研究报告，它包含对建议的或改善的系统的描述以及利润，成本分析。第二部分是系统的初步设计。它对于估价成本和利润是必要的。该初步设计是二阶段一系统分析和设计的直接输入。 将系统的初步设计并入可行性研究的依据是，多数可行性研究是以概念而不是以设计为基础的。假如在描述系统目的上花的时间太少，那么成本估计，甚至利润估计将是错误的。用概念来指导可行性研究注定会导致成本过高，并且用户不满意。在系统初步设计上所花费的时间是值得的，即使拒绝可行性研究也是如此。由于所编写的资料将必然会被证实其他项目中是有价值的。 (1)提交服务请求 对受拒绝的请求再次请求解决的一种方法。所请求的服务毕竟是用户做的，因此，应当由用户着手进行。我们鼓励用户管理人员请求信息服务人员的帮助，但是应当再一次强调，业务领域的管理人员应当对各种大小的服务请求都提供合适的资料。 (2)估价服务请求 正如在责任矩阵中所注释的那样，信息服务管理人员只能承诺小的项目(由公司的方针所拟定的小项目)。 (3)指定可行性研究组 信息服务经理和用户经理共同来指定适当的混合的人选以组成可行性分析研究组。该组至少由一名系统分析员和一名用户代表组成。可行性研究组的大小取决于可行性研究的范围和时间限制。 用户代表应当熟悉当前专业领域的所有工作，用户经理、总经理助理，或专业领域分析员是合理的候选者，用户的系统分析员，具有计算机信息解决基础知识的情况己经越来越普遍了。 必须指定一个人担任可行性研究组的组长，哪怕只是两个人的可行性研究组也需要一个组长。直到1980年为止，多数的可行性研究组和项目组是由一个高级系统分析员或一个项目负责人来领导的。在信息服务部门中，这两种人是固定分工做这项工作的。目前越来越多的公司采用这样一种政策，即由用户担任项目组组长。这种将重要责任下放给最终用户的做法将进一步鼓励用户参与系统设计。在这种政策上取得成功经验的那些公司己经指派了一些具有杰出管理经验和具有某些计算机和信息解决知识的用户人员担任项目组组长。在任何情况下，组长必须对该组的工作有一个总的安排。假如规定一个用户代表既作为可行性研究组或项目组的组长而同时又规定他继续履行业务领域的职责，那么该项目是肯定要失败的。有好些公司己经采用了一种政策，即自动地指派受系统影响最大的业务领域的经理作为可行性研究组和项目组的领导以后该经理将从本来的工作职责中解脱出来，而用他(她)的所有时间管理可行性研究(或项目)组。这种人事安排己经成为当今的主流，其困难是用户经理需要离开本来主管的业务部门少则两个月多则三年后才干回他本来的工作岗位上。 (4)标列约束条件 在系统开发的过程一开始，可行性研究组与信息服务人员和用户经理密切合作标列出设备、成本、进度、规程、软件以及操作上的约束条件。它们也许限制建议的系统的定义和设计。 (5)整理现有系统的资料 整理现有系统资料的重要理由是:假如可行性研究组不充足了解现有系统，那么他们就不也许有效地完毕所建议的系统的初始设计。已经建立起来的多数人工系统并没有通过真正的设计。在这些系统中，必须从手稿整理出资料。假如一个建议的系统是改善一个现有的计算机信息系统，那么可行性研究组只需要保证现有资料的完整性和保持最新版本就行了。 现有系统所形成的任何资料将给设计阶段提供有价值的输入(假如批准开发该系统)。 即便建议的系统遭到拒绝，也能对现有系统提供基本的资料，并且也许透彻地理解理有系 统。现有系统的资料由四部分组成:0系统报告和资料;0系统数据文献;0系统数据元以及说明现有系统的数据、信息和工作流程的图表。前三部分(报告、文献和数据元)可分类 如下: 0当前使用的，并且在建议的系统中以目前的形式保存下来; 0当前使用的，但是修改后才在建议的系统中使用; 0当前使用的，但是在建议的系统中将被删除而不再保存的。 例如，列出所有现有的报告和标准的资料，并按上述分类给定一种状态。在报告上将标明相对周期(如，天天，每周)以及分发范围。 对于现有系统的所有数据文献都标明有关的存储介质(如，3x5的卡片，磁带，马尼拉折纸机，磁盘等等)以及存储方式。例如，一个名字一地址文献可以存储在许多张3x5的卡片上，并且按名字的字母顺序排列。一个人工系统所保存的文献数总是令人吃惊的，即便对于业务领域管理人员也是如此。为了完善现有文献的资料，将每个文献的记录的样式和简朴描述附在文献表中。 系统数据元(即，社会保险号，顾客名，货号等等)是直接列出的，而不必关系有关的文献。数据元经常在几个文献中反复出现。除了状态指示符之外，假如数据的名字不能自我说明，则必须对每个数据数据元进行描述。有关数据元的其他信息还涉及更新规定(如，天天，每周，每月，或根据需要更新等等)、来源(如，代办处，资料，系统，工作人员等等)以及职责(如，部门名和负责更新者的职务)。说明在整理现有系统资料时数据元也许采用的一种典型格式。 我们通过将系统简化为输入、解决和输出等几个基本组成部分来表达整理现有系统资料的工作过程。然后用图形描绘出各部分之间的逻辑关系。有多种图像表达技术来做这件事。最为流行的(尽管不一定是最佳的)是流程图。其他的更为结构化的技术尚有:数据、信息和工作流程的一个概貌。它着重强调系统申控制工作流程的那些数据元。这些图应当刻划人工和计算机的解决环节，并且以适当的顺序安排每一解决环节。通常以能最佳地显示出工作过程的方式来组织和提供这些图。它们可以是由一些随机事件、功能或按小的和大的周期来驱动的子系统，也可以是若干子系统;既可以是层次的，也可以是混合的。很少有几个系统是完全顺序的，因此，在多数情况下可以应用模块方法。 (6)调查研究技术转移的也许性 为了更好地运用现有的技术，许多公司正在进行将有关技术转移到他们的系统开发方法学中也许性的调查。鼓励调查技术转移的也许性和(或)可行性的政策必将带来人力资源的大量节省。特别对程序员和分析员更是如此，合适的技术转移将使这些人的工作集中于还没有现成软件的特定行业的应用领域。 技术转移也许性的调查是从走访那些己经实现的，并且与所建议的系统有类似规模和工作的系统。可行性研究组还应当调查商品软件目录，以便找到适合的可应用的软件。假如认为技术转移是可行的，则可行性研究组说明如何使用这些技术以及为适应现有环境所规定的修改范围。 假如使用标准的方法来进行技术转移潜力调查，那么提出规定的公司应当采用与具有类似规定的其他公司合作的政策。 (7)完毕建议系统的初步设计 可行性研究组要走访专业人员以获得一般的系统规定，然后，将这些规定转换成初步的系统设计。设计过程是交互的，用户经理和可行性研究组需要经常就设计思想和方法等互换意见，用生动的文字和图形说明来形成建议的系统初步设计的资料，这些生韵的文字(用非技术词汇)描述了所建议的系统的基本工作过程，并且经常同时附有图形说明。这些文字图表也将列举出那些大大违反现有工作方式而建议的系统所盼望的手续、手段和方法。这些文字图像也将描述建议的系统与人工系统以及建议系统必须与之兼容的自动系统之间的关系。 (8)拟定项目范围 可行性研究组与信息服务人员以及用户管理人员合作估计初步设计中所刻划的系统的复杂限度。并对开发项目此后的每一个阶段进行人力资源规定的估计(用户，信息服务人员及其别人员)。此外，还注意到培训和计算机机时规定。 (9)准备利润，成本分析报告 一旦完毕初步设计并且拟定了项目的范围，则可以开始利润，成本分析。不幸的是，由于用户和信息服务管理人员都希望加快可行性研究阶段，所以，一些关键的环节被省略了，因此导致在利润、成本估计上的错误。仅仅根据一种概念是不也许精确的反映出利润和成本的。设计中的某些环节是必不可少的。 另一种在形成公司决策过程中所隐含的错误将不可避免地把那些难以拟定的利润也算成资金收入。当今许多复杂的，综合的系统为公司的利益做出了重大的奉献，而做到这样限度是由于它们经历了漫长的、不可捉摸和难以预见的道路。评价信息服务项目的好处和价值是一个主观的过程，它规定具有成本和利润方面的实际的知识。此外，决策者对于正的和负的不拟定的利润要有透彻的理解。使用美元作为所有成本和利润的统一的计量标准大大地简化了评价工作。那种把不拟定的利润引人赚钱图表(为了建立更好的顾客关系或提高威信)的作法会导致在底线中复合的错误。底线经常被盲目地接受作为一种信条。事实上，在那种情况下，估价是取最佳的情况(抱负的)和最坏的(荒唐的)情况之间。然而假如将不拟定的利润化成美元，那么决策者将以更好的判断代替那种不准确的估计。 估价建议的信息系统的最佳途径是针对系统净值(收入减去成本)估量正的和负的不拟定利润。为了便于理解不拟定利润(例如，增长服务;减少发票上的错误，加快周转期等)，应当产生一个成本和收人的一览报表。 如下表说明使用最少的成本类别来表达一次性的和反复使用的成本。这些成本可由预算中心提出，并且把公司作为一个整体来考虑。成本类别有:劳力，材料和设备，旅差以及其他各种成本。对于每一类，在第一列指出一次性成本估计(开发)，而在系统寿命期的水平线上指出可反复使用的成本估计(生产)。公司项目在净值可以从估计收人中扣除成本计算出来，并且根据公司政策对流动钞票打折扣。预算中心项目的题和编号成本项一次性成本第年反复使用的成本年第1 年第2 年第3 年第4年第5年第6年第7 年第8年劳力材料和设备材料设备每日开销交通费其他开支总成本（10）根据可行性研究做出决策完毕可行性研究后，除了技术补充之外所有报告和资料所有交给信息解决政策委员会以使实行。技术补充涉及准备可行性研究所规定的背景信息。它还涉及一般的系统设计和开始第二阶段的一个框架。信息服务政策委员会感觉的重要是初始服务请求、范围、图解说明和利润成本分析。住处服务政策委员会能对可行性研究施加影响。信息服务政策委员会可以：A拒绝建议。B批准建议并对该建议的开发和实现指定一个最高先数。C批准系统并给它指定一个比最高优先数小的优先数，同时将请求放在所有建议的系统队列的适当。系统分析与设计很少有几个项目能在批准可行性研究后立即实现。在得到批准和项目开始之间的估计时间也许是两年或两年以上。一旦项目获准通行，则开始第二阶段一系统分析和设计。在第二阶段，将描述所有输入输出的格式和内容，并且完毕具体的系统设计。第二阶段的最后一步活动是准备程序说明，其中涉及各种程序模块的说明书。重要的是牢记在第一阶段和第二阶段不编制程序。一个普遍容易犯的错误是压缩第二阶段，使它提前完毕以使开始第三阶段一程序设计。粗糙的系统设计必将成倍、甚至三倍地增长项目所规定的程序设计量。（1）指定项目组与可行性研究组同样，项目组也应当有一个或多个系统分析员和一至多个来自所建议的系统范围内各业务方面的用户代表。假如也许的话，还要给项目组指派一名住处服务审计员，他不作为专职人员，而作为安全和控制方面的顾问。由于在第二阶段结束之前程序员事实上并不参与进来，所以可以将指定的程序员一事推迟到第二阶段开始之间的这一段时间里，通常委派他们到其他项目去。然而我们建议，只要也许则昼将原有可行性研究组的人员指派到项目。项目组的组长可以是住处服务人员，也可以是用户。某些单位有按业务领域组织的固定的项目组。究竟如何组成项目组为好，显然要进行权衡。按专业组成的项目组很难预料在任务过多时或更多的机会积累一切专业领域应用的经验。信息服务项目组组织的最佳方式或许是既按专业领域组织而同时又保持一定的灵活性，使得项目组成员能在各项目组织之间流动，以使达成饱满的工作负荷。根据项目的复杂限度和涉及范围的大小，每个项目组都有不同的最佳人数。项目组长的能力是一个重要的因素。在某拟定的数目之前，每增长一个指派到项目组的人员都增大了对项目的。在这之后，每增长一人事实上养活了项目组第一个人对项目工作的。与项目有前的扔有经理和公司行政人员都应当很好地掌握这样一个格言：与其过度地扩大项目组织规模。赞成欲速则不达的局面，还不如推迟项目的实现时间。（2）估计人员规定并进行人员委托一个项目的成功与否在很大限度上依赖于用户与公司经理、其他专业人员以及某些范围内信息服务人员。由于某人忘掉或不认可以前的口头上的委托，会使得许多紧急项目被延误。因此有必要签署一个局面的人员委托书。没有书面人员委托而进行的项目肯定会产生不必要的延误，甚至也许失败。本书把项目开发的重要性放到一个恰当的位置。在项目中所涉及到的许多人并不在项目组内。由于这些的多数都理解他们的例行活动比项目所涉及的任何外部事物更为重要，所以一个局面委托是必不可少的。（3）人员培训为了在系统开发过程中进行有效的交流，也许规定对于在设计数据库时所涉及的用户以及在生产调度中所涉及的信息服务人员进行培训。根据经验。信息服务部人员负责信息系统方面的培训，而用户则负责专业领域的培训。这个活动的产品是一榄表，表中列出规定某种培训的人员的名字和所担任职务。每行表中都那种培训的简朴描述，涉及地点、负责人以及计划的时间等。有些培训将规定立即进行，而另一些培训将推迟到项目接近实现时进行。（4）建立具体进度表通过使用一种标准的系统开发方法，管理人员可以建立阶段标志然后，运用历史记录数据和经验来估计中间和最后活动完毕的日期。项目组组长必须与信息服务人员以及业务领域的管理人员密切合作以保证在系统开发过程中在各关键点有足够的人员。系统开发本质上是线性的，并且是不难用适当的准则和合理的估计来监视的。下面的方法可以用来估计价格、人员以及相应的时间规定。这种循环使用的方法使得一组人能意见一致，并且对于信息服务项目特别合适。我们假定参与估计的那些人可以提出问题仅具有任务方面的知识，并且可以提出铁重要的理由。参与建立信息系统项目进度表的人可以涉及项目组长、起作用的用户经理以及其他有经验的信息服务人员。我们通过以下几个环节来描述进行合理估价的方法。A项目组长介绍任务和相应的背景信息。B第一个参与者提交一个书面估计。C项目组长绘出该且每个成员的估计。D计算、上下四分点和中点，并且标上迟度。E规定其估计低于上、下四分点的那些参与者解释他们低或高估计的理由。F项目组长就所标绘的估计召集一次公开的讨论会。G反复环节B、F，直到达成精确性规定不需要再循环为止。通过每一循环，将减少估计的误差。H估计是取中间值或取平均值。估计的误差是误差危险的一种标志。（5）与用户有员交谈与用户交谈的过程从本活动开始。为了解决总是和拟定系统规定，项目级成员定期与有关用户见面。与用户交谈及反馈的过程贯空于系统开发的全过程。对于具体设计的基本输入是：初始设计、对现有系统及其成分的评价 以及输入、解决以及输出的规定（由用户提供）。A项目组与有关的用户人员检查在可行性研究的初始设计中所描述的输入输出规定和频率，并根据需要及价值对第一种输入输出进行评价。 B目前系统的资料对设计提供了有价值的输入。C初步交谈的一个直接结果是对所建议的系统所有的输出一般的描述。（6）说明数据库规定数据库用来支持系统的解决，特别是支持系统的输出。在目前系统的资料中包含了可继续使用的数据元。许多现有数据元的格式肯定是需要改变的，还需要将支持系统功能规定所需要的其他数据元标列出来。（7）建立控制和后援的方法为了保证住处的对的性、可行性和完整性，在设计时就要考虑加进控制手段。项目组将说明在系统设计时要嵌入所有物理上的行政管理上的控制。在系统的输入、解决和和以控制系统的技术的范围是广泛的。（8）完毕具体设计具体的系统设计是分析输入输出解决控制和后援规定的结果。系统初步设计或系统一般设计只描绘了各重要解决活动之间的关系，而系统具体设计则扩展到涉及所有解决活动和有关的输入输出。这是系统一开发过程的基础活动。（9）指导用户或信息服务部门预演。结构预演是一种预测评价方法，它能有效地养活某些被的或作错的事情。它也给预测者提供一个机会来评价那些业已建议的事情，从而有也许给出一些建设性的建议。预演的目的是给项目组提供有价值的反馈信息，而不是对系统的质量下判决性的结论。项目组长应考虑何时开始结构预演。通常预演是在系统设计以及系统开发过程中其他一些关键点完毕之后才进行。（10）选择硬件假如正在开发的系统规定额外的硬件支持，则需要选择适当的硬件并进行订货。获得硬件的过程通常是信息服务经理的责任。（11）准备输出格式在系统开发过程中，到目前这一阶段为止，我们已经了输出并描述了其有关的内容，但是程序员需要知道具体的输出形式。这种具体的输出说明称之为输出格式。项目组产生出显示屏格式，这种格式规定了诸如题、标题、输出形式等项，有时还应涉及输入形式。某些硬拷贝报告和资料规定事先打印好的表格纸，项目组与表格纸厂商的代表合作设计这种事先打印好的表格纸。项目组还负责设计和满足在系统范围内所有人工产生的报告和资料，同时与受有影响的用户经理相配合进行修改、增长或删除。（12）描述数据项的说明书数据项的说明书具体规定了什么数据将输入到系统以及它们如何被输入到系统中。 （13）准备程序描述系统开发进展到目前这一步，我们已经以现有的系统作了详尽的分析。它的功能已经并入建议的系统的设计中，我们已经完毕了建议的6主其支持的数据库的设计，并且还准备了所有输入输出具体的说明书。现在项目组可以着手标列和拟定所有的程序，而这些程序是使得建议的信息系统运转所规定的。对第一个程序，项目组编辑下述的资料：（1）程序语言的种类（2）程序解说词的描述一描述要执行的任务。（3）由程序所产生的各种输出的描述和格式（4）解决频率 （5）界线和限制（6）具体说明书 程序设计形式来进行的，而这些指令被编进计算机程序中。这些计算机程序涉及系统运转所必需的软件。在第三阶段一程序设计阶段将开发支持信息系统所规定的所有软件。用户的介入集中在系统开发的过程前段(第二阶段)和后段几个阶段。假如对的地完毕了第二阶段并且用户与项目组的协作是有成效的，那么用户将很少介入程序设计阶段，甚至完全不用介入。用户介入最多的情况将反复出现在系统设计需要澄清的时候，有时也出现为第四阶段(转换与实现)，作一些初始计划的时候。 不幸的是，有时用户管理人员也较深地卷进了程序设计阶段。这是第二阶段进行得很糟糕，并且当开始程序设计时还没完毕的一种标志。这种情况是经常发生的，特别是在时间紧迫时，项目组经常收到一些强制性的命令规定产生尚未完毕的产品。由于系统开发过程的最终产品是软件，所以有时过早地开始程序设计。这种系统开发方式必然导致产生质量低劣的系统。这种系统并不能满足用户的规定，并且维护的代价很高。这种系统整个寿命期的成本也许是一个高质量的系统的两到三倍。 (1)指定程序员组长通常项目组长是一个系统分析员或是一个用户，他并不直接参与程序设计工作。管理程序设计工作的人应当是程序设计工作实际的参与者，因此，对于规定两个人以上的程序设计工作，将由信息服务经理指定一个程序员组长。当然，项目组长仍然对整个项目负有责任。程序员组长有时也称作为主程序员。他(或她)也许只花10%的时间在产品的程序设计上。假如只需要管理一个下属程序员，那么主程序员也许花80%的时间在产品的程序设计上。 (2)安排顺序和分派程序一个信息系统的软件包，也许规定几百个程序。并不需要按照这些程序最终执行的顺序来编写它们，在建立程序开发进度表时，必须考虑到许多变化的因素。在安排程序编制顺序时，主程序员应考虑如下问题， 0建立和维护测试文献的需要 0程序的依赖性(此处一个程序依赖于另一个程序的部分或所有的输出) 0程序的长度和复杂性根据程序员专业知识的水平、工作效率以及对系统熟悉的程序分派程序。由于经常将程序员分派到其他项目组，从而对专业知识和经验的规定非常广泛，所以使程序员与程序相匹配并非易事。 (3)安排准备程序的进度主程序员可以运用程序进度表来安排和监督下属程序员的活动以及任一给定程序的状态。由于程序开发有一个基本的模式，所以一种类似于用来监督项目进度的技术可以用来监督完毕二个特定程序的进度。并且它是在公告板上可以看到的一种通用的管理工具。几乎所有的主程序员和项目组长都经常使用这种公告板。 (4)编制、测试程序和编写程序资料。 通常一个程序员在一给定的时间里将同时编制25个程序。开发任一给定的程序的一般的方法本质上是相同的。转换和实现尽管在第四阶段已经分别测试了系统的各个成分(程序)，但这并不能保证把它们结合成一个整体时系统将正常工作。因此，在第四阶段来完毕整个系统的测试。在第四阶段期间，项目组将培训用户运营信息系统，转换现有文献以及建立数据库。在并行工作之后，系统转变到业务领域。(1)完毕转换计划转换系统的解决自身就是一个系统，并且应当像最佳的结果那样来解决。项目组与用户管理人员以及信息服务审计组合作，共同研究以设计出一项转换计划。该计划涉及:系统验收测试，文献或数据的转换，用户培训以及并行工作(假如必要的话)的细节。转换计划具体地细述了用户及信息服务人员的义务和责任，同时还规定了进行这些事情的时间限制。(2)指导系统验收测试虽然已经测试了各个单独的程序模块，但是还没有把它们结合成一体作为一个系统来解决。一个信息系统也许有100个以上的程序和一打以上的文献，必须把它们作为一个整体来解决以保证使工作协调并使用户满意。整体的测试将验证所有系统软件和应用软件、输入/输出，文献和数据库以及各种过程。在测试期间用户人员是实际的参与者。在测试过程中，有也许发现错误(忽略了系统的某些方面)，某些过程的缺陷将会暴露出来。可以肯定，一部分验收测试过程必须在系统设计和程序设计方面进行较小的修改。假如系统是对的开发的，那么任何这种修改将只是微小地调整系统。任何重大的修改应当推迟到系统实现之后，并且至少在进行生产性工作一年之后再进行。这种推迟避免了通常敲打膝部那种反作用引起的改变而提交可观的资源。这是由于为了减少重大修改的规定，项目组长和受影响的用户管理人员将要停止信息系统的每一方面。这时，重大修改的规定才是一种分界清楚的标志，它表白有人忽略了他们对项目的责任。整个系统的测试事实上是分两个部分完毕的。一方面运用测试数据来验证每一个子系统。一旦证实所有子系统的功能是适合的，则有生存的数据来测试整个系统。测试数据是为了测试特定的环境而产生的，而生存的数据通常是来自过去解决使用的实际的数据。在测试联机系统时(此时响应时间是关键问题)，为了测试系统的能力，涉及了用几种生存数据的测试会话。系统也许运营良好，但是由于计算机能力不够大或是程序的效率不高，也也许导致不可接受的响应时间。(3)设计用户手册 项目组设计一套用户手册，并且在对系统验收测试的同时指导用户的培训活动。每个信息系统都应当有一套用户手册，它们提供有关系统运营的命令和解释。用户手册和有关的培训对于系统的最后成功是至关重要的。光有一套用户手册是不够的，这些用户手册还必须是一种高质量的资料，它们能对系统的每一方面提供快速和容易的参照。用户手册至少涉及: 系统的目的 系统的描述 工作流程和一般的操作方法 完毕和理解输入/输出的命令 数据收集和更新的方法 控制 其他(例如，术语唯一的词汇表，硬件的描述和用法，性能的界线，等等)用户手册的内容来自系统资料。然而，在编写和编译这种手册时必须考虑到能为预期的用户所理解，并且不会被错误地解释。(4)提供用户培训大纲 假如不能跟培训相关联，那么用户手册的价值就很小。项目组的成员指导一系列的培训课程以使得用户熟悉系统。用户培训大纲的一般内容涉及: 系统的用途和目的 现有系统与新系统的差别 系统工作概述 如何使用用户手册 与系统有关的信息服务人员和用户人员的义务和责任 一个有各地分号的大型百货商店实现了一个联机销售点(P05)系统并将用户手册分发给每一个POS终端地点。假如没有正规的培训，销售员将丢下他们自己的工作而去揣摹用户手册(有100页以上)以了解系统的用途。由于销售人员不能解决基本领务，于是使得顾客不再等待，而跑到其他地方买货。在他们结识到问题不在于市场、产品质量或地点之前，百货商店的这些分号几乎要关闭。问题在于缺少对系统用户的训练。(5)建立和转换文献或数据库很难找到一个已实现的系统而不需要修改原有的文献或数据库。有些文献和数据库需要新建，而其他一些则需要从现有的转换成适合的格式。用户部门负责将手写的数据统一格式并变成机器可谈的形式。用户部门也也许负责誊录和录入数据的工作。假如数据不是现成可用的或没有用人工存储起来(例如，存放在3XS的卡片上)，那么数据的准备工作也许花费相称长的时间。在项目组的指导下，用户负责新产生的和转换的那些文献的一致性。数据的校对是将人眼现场检查与计算机自动校验结合起来进行的。随机抽样检查可以有效地用于非常大的文献或数据库。在建立和转换解决期间掌握时间是很重要的，由于一旦建立了一个文献或数据库，此后就必然要对它们进行连续地更新。因此，最佳的策略是:在并行工作开始之前(或者在不规定并行操作的情况下，在系统实现时)正好完毕建立和转换工作。(6)完毕并行工作并行工作意味着同时运营原有的系统和新的信息系统。并行工作是常用的手段，特别是当系统故障相称大地影响到公司的运营时更是如此，在并行工作期间，用户和信息服务人员被分散开了，由于两个系统都需要维护。完毕并行工作是十分困难的，由于参与的人员仍然处在开始阶段。通常安排并行工作连续一个重要的系统周期(一般是一个月)。项目组长和受影响的用户管理人员以及有关的信息服务经理监督并行工作的进程。某些单位己经接受了并行工作至少要进行一个重要周期的方针，而另一些单位则决定维持原有系统直到经理认为新系统已经所有运营时为止。 假如在并行工作期间出现了一次较大的故障，则应中断并行工作并进行有关的修复工作。由于必须维护文献和数据库，所以及时性是十分重要的;假如公司改善他们的系统测试方法，那么信息服务和用户人员就会自信他们有能力去实现一个系统。有些公司放弃并行工作，尽管这种做法有很大的危险，但是这样将把力量集中在成功地实现一个新系统上。在某些情况下，由于时间和人力有限，不能进行并行工作，因而经理的代替办法是直接实现新系统，并且规定进行充足的系统测试。 实现后评价由于其他紧急的信息系统项目需要人员，往往进行很少的，甚至不进行实现后的评价，不管好坏，系统就被接受了。实现后的评价或定期系统评价应当是系统开发过程的组成部分。任何信息系统在刚刚实现之后都将规定做某些“微小的调整”。为此，必须在系统投入生产前，对它进行评价。由于一旦系统投入使用，即便实现前的测试设计得很好，也不也许完全暴露出某些在系统投入运营时必将出现的问题。委托并进行评价活动的好处是获得更高质量的系统并且使用户更为满意。（1） 指导系统实现后的评价项目组长高速项目的成本以如实反映一、二、三、四阶段的最终系统开发成本。此外还将成本汇总以反映出维持系统运营的成本。直到系统实现至少一个月之后，才有也许算出精确的、符合实际的成本数据。（2） 指导系统实现后的评价系统实现后的评价，由从项目组和受影响的用户部门挑选出的人员来指导进行。在系统运营的头几个月，由于存在着对改革的阻力，对系统的把握不够以及非预期的问题等，因此，不宜立即进行系统实现后的评价。通常在第四阶段完毕后的36个月之间进行系统实现后的评价。项目组和用户部门挑选和人员并指导系统实现后的评价以决定：实际的与预期的性能的比较。运用在系统设计时已建立起来的某些标准，将实际的性能与的性能进行比较。系统目的实现的限度。针对在可行性研究中建立的那些目的来评价系统。例如，系统能否给审计员提供非常及时的信息以进行更好的决策。非预期的利润或花费。几乎任何基于计算机的系统都将导致非预期的利润和花费。这些利润或负荷提供了评价整个信息系统效率的直接输入数据。坦率地计论错误。很少有在系统开发过程中不犯错误而实现一个系统的。应当将项目组、用户经理、用户人员、其他信息服务人员或信息服务对策委员坦率、具体地讨论的错误编写成资料。列举这些错误并非用来追究某个人或某团队的责任，而只是着重强调为什么会产生这些错误以及可以做些什么努力以便在此后的项目中消除这些错误。系统实现后的评价被提交给信息服务经理和用户经理以便采用适当的措施。（3） 准备系统检查的计划很多数据解决系统和信息系统在实现之后都保持，而没有作出任何共同的努力去显著地提高它们。在这些系统中，所谓的改善工作是不超过例行维护的范围的，并且是由于用户的反映才作的。这种被动地改善系统的方法其效率远比由定期的系统检查来保证的积极的方法要差得多。有很多因素会导致忽视定期检查，因此，应当通过一个正式的书面检查为督促进行检查。两次检查之间的间隔时间是根据系统的复杂性和易变性来决定的。定期系统检查是业务领域管理人员的责任。由检查所产生的各种建议将最终反映在由用户管理人员提交的一个服务请求中。附件4：系统审查评价安排定期的系统评价一般在系统实现后三个月，但不能超过一年。信息服务人员和用户都要积极地参与系统评价。全面的评价也许要化费一个周到几个月的时间，这取决于系统的规模。评价小组负责审定下列内容。1、系统效率2、系统有效性3、解题周期4、响应时间5、信息的关联6、输入输出的分派及控制7、输入输出的格式和内容8、文献、记录和数据库的结构9、更新和后备的措施10、系统资料的通用性善于需要进一步改善的局限性之处和建议都要编制成文献。并提交给相应的业务领域的管理人员。信息系统审查第一个公司都应当设立一个公司内部的信息系统审查小组，由该小组向高级的中立办公室报告。信息系统审查工作人员的职责是保证生产信息系统的完整性。有三种不同的信息系统审查，它们是系统开发审查。一、 系统开发审查就系统开发审查而论，信息系统审查工作人员要担任开发项目组