网络开发人员的工作细则样本.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)编制、测试程序和编写程序资料。
通常一个程序员在一给定时间里将同时编制2~5个程序。开发任一给定程序通常方法本质上是相同。

转换和实现
尽管在第四阶段已经分别测试了系统各个成份(程序)，但这并不能确保把它们结合成一个整体时系统将正常工作。所以，在第四阶段来完成整个系统测试。在第四阶段期间，项目组将培训用户运行信息系统，转换现有文件和建立数据库。在并行工作以后，系统转变到业务领域。
(1)完成转换计划
转换系统处理本身就是一个系统，而且应该像最好结果那样来处理。项目组和用户管理人员和信息服务审计组合作，共同研究以设计出一项转换计划。该计划包含:系统验收测试，文件或数据转换，用户培训和并行工作(假如必需话)细节。转换计划具体地细述了用户及信息服务人员义务和责任，同时还要求了进行这些事情时间限制。
(2)指导系统验收测试
即使已经测试了各个单独程序模块，不过还没有把它们结合成一体作为一个系统来处理。一个信息系统可能有100个以上程序和一打以上文件，必需把它们作为一个整体来处理以确保使工作协调并使用户满意。整体测试将验证全部系统软件和应用软件、输入/输出，文件和数据库和多种过程。在测试期间用户人员是实际参与者。在测试过程中，有可能发觉错误(忽略了系统一些方面)，一些过程缺点将会暴露出来。能够肯定，一部分验收测试过程必需在系统设计和程序设计方面进行较小修改。假如系统是正确开发，那么任何这种修改将只是微小地调整系统。任何重大修改应该推迟到系统实现以后，而且最少在进行生产性工作十二个月以后再进行。这种推迟避免了通常敲打膝部那种反作用引发改变而提交可观资源。这是因为为了降低重大修改要求，项目组长和受影响用户管理人员将要停止信息系统每首先。这时，重大修改要求才是一个分界清楚标志，它表明有些人忽略了她们对项目标责任。
整个系统测试实际上是分两个部分完成。首先利用测试数据来验证每一个子系统。一旦证实全部子系统功效是适合，则有"生存"数据来测试整个系统。测试数据是为了测试特定环境而产生，而"生存"数据通常是来自过去处理使用实际数据。
在测试联机系统时(此时响应时间是关键问题)，为了测试系统能力，包含了用多个生存数据测试会话。系统可能运行良好，不过因为计算机能力不够大或是程序效率不高，也可能造成不可接收响应时间。
(3)设计用户手册
项目组设计一套用户手册，而且在对系统验收测试同时指导用户培训活动。每个信息系统全部应该有一套用户手册，它们提供相关系统运行命令和解释。用户手册和相关培训对于系统最终成功是至关关键。光有一套用户手册是不够，这些用户手册还必需是一个高质量资料，它们能对系统每首先提供快速和轻易参考。用户手册最少包含:
·系统目标
·系统描述
·工作步骤和通常操作方法
·完成和了解输入/输出命令
·数据搜集和更新方法
·控制
·其它(比如，术语唯一词汇表，硬件描述和使用方法，性能界限，等等)
用户手册内容来自系统资料。然而，在编写和编译这种手册时必需考虑到能为预期用户所了解，而且不会被错误地解释。
(4)提供用户培训纲领
假如不能跟培训相关联，那么用户手册价值就很小。项目组组员指导一系列培训课程以使得用户熟悉系统。用户培训纲领通常内容包含:
·系统用途和目标
·现有系统和新系统差异
·系统工作概述
·怎样使用用户手册
·和系统相关信息服务人员和用户人员义务和责任
一个有各地分号大型百货商店实现了一个联机销售点(P05)系统并将用户手册分发给每一个POS终端地点。假如没有正规培训，销售员将丢下她们自己工作而去揣摹用户手册(有100页以上)以了解系统用途。因为销售人员不能处理基础事务，于是使得用户不再等候，而跑到其它地方买货。在她们认识到问题不在于市场、产品质量或地点之前，百货商店这些分号几乎要关闭。问题在于缺乏对系统用户训练。
(5)建立和转换文件或数据库
极难找到一个已实现系统而不需要修改原有文件或数据库。有些文件和数据库需要新建，而其它部分则需要从现有转换成适合格式。用户部门负责将手写数据统一格式并变成机器可谈形式。用户部门也可能负责誊录和录入数据工作。假如数据不是现成可用或没有用人工存放起来(比如，存放在3XS卡片上)，那么数据准备工作可能花费相当长时间。
在项目组指导下，用户负责新产生和转换那些文件一致性。数据校对是将人眼现场检验和计算机自动校验结合起来进行。随机抽样检验能够有效地用于很大文件或数据库。在建立和转换处理期间掌握时间是很关键，因为一旦建立了一个文件或数据库，以后就肯定要对它们进行连续地更新。所以，最好策略是:在并行工作开始之前(或在不要求并行操作情况下，在系统实现时)恰好完成建立和转换工作。
(6)完成并行工作
并行工作意味着同时运行原有系统和新信息系统。并行工作是常见手段，尤其是当系统故障相当大地影响到企业运行时更是如此，在并行工作期间，用户和信息服务人员被分散开了，因为两个系统全部需要维护。完成并行工作是十分困难，因为参与人员仍然处于开始阶段。
通常安排并行工作连续一个关键系统周期(通常是30天)。项目组长和受影响用户管理人员和相关信息服务经理监督并行工作进程。一些单位己经接收了并行工作最少要进行一个关键周期方针，而另部分单位则决定维持原有系统直到经理认为新系统已经全部运行时为止。
假如在并行工作期间出现了一次较大故障，则应中止并行工作并进行相关修复工作。因为必需维护文件和数据库，所以立即性是十分关键;假如企业改善她们系统测试方法，那么信息服务和用户人员就会自信她们有能力去实现一个系统。有些企业放弃并行工作，尽管这种做法有很大危险，不过这么将把力量集中在成功地实现一个新系统上。在一些情况下，因为时间和人力有限，不能进行并行工作，所以经理替换措施是直接实现新系统，而且要求进行充足系统测试。

实现后评价
因为其它紧急信息系统项目需要人员，往往进行极少，甚至不进行实现后评价，不管好坏，系统就被接收了。实现后评价或定时系统评价应该是系统开发过程组成部分。任何信息系统在刚刚实现以后全部将要求做一些“微小调整”。为此，必需在系统投入生产前，对它进行评价。因为一旦系统投入使用，即便实现前测试设计得很好，也不可能完全暴露出一些在系统投入运行时必将出现问题。
委托并进行评价活动好处是取得更高质量系统而且使用户更为满意。
（1） 指导系统实现后评价
项目组长高速项目标成本以如实反应一、二、三、四阶段最终系统开发成本。另外还将成本汇总以反应出维持系统运行成本。
直到系统实现最少30天以后，才有可能算出正确、符合实际成本数据。
（2） 指导系统实现后评价
系统实现后评价，由从项目组和受影响用户部门挑选出人员来指导进行。在系统运行头多个月，因为存在着对改革阻力，对系统把握不够和非预期问题等，所以，不宜立即进行系统实现后评价。通常在第四阶段完成后3－6个月之间进行系统实现后评价。
项目组和用户部门挑选和人员并指导系统实现后评价以决定：
实际和预期性能比较。利用在系统设计时已建立起来一些标准，将实际性能和性能进行比较。
系统目标实现程度。针对在可行性研究中建立那些目标来评价系统。比如，系统能否给审计员提供很立即信息以进行愈加好决议。
非预期利润或花费。几乎任何基于计算机系统全部将造成非预期利润和花费。这些利润或负荷提供了评价整个信息系统效率直接输入数据。坦率地计论错误。极少有在系统开发过程中不犯错误而实现一个系统。应该将项目组、用户经理、用户人员、其它信息服务人员或信息服务对策委员坦率、具体地讨论错误编写成资料。列举这些错误并非用来追究某个人或某团体责任，而只是着重强调为何会产生这些错误和能够做些什么努力方便在以后项目中消除这些错误。
系统实现后评价被提交给信息服务经理和用户经理方便采取合适方法。
（3） 准备系统检验计划
很多数据处理系统和信息系统在实现以后全部保持，而没有作出任何共同努力去显著地提升它们。在这些系统中，所谓改善工作是不超出例行维护范围，而且是因为用户反应才作。这种被动地改善系统方法其效率远比由定时系统检验来确保主动方法要差得多。有很多原因会造成忽略定时检验，所以，应该经过一个正式书面检验为督促进行检验。两次检验之间间隔时间是依据系统复杂性和易变性来决定。
定时系统检验是业务领域管理人员责任。由检验所产生多种提议将最终反应在由用户管理人员提交一个服务请求中。

附件4：
系统审查评价
安排定时系统评价通常在系统实现后三个月，但不能超出十二个月。信息服务人员和用户全部要主动地参与系统评价。全方面评价可能要化费一个周到多个月时间，这取决于系统规模。评价小组负责审定下列内容。
1、系统效率
2、系统有效性
3、解题周期
4、响应时间
5、信息关联
6、输入输出分配及控制
7、输入输出格式和内容
8、文件、统计和数据库结构
9、更新和后备方法
10、系统资料通用性
善于需要深入改善不足之处和提议全部要编制成文件。并提交给对应业务领域管理人员。
信息系统审查
第一个企业全部应该设置一个企业内部信息系统审查小组，由该小组向高级中立办公室汇报。信息系统审查工作人员职责是确保生产信息系统完整性。有三种不一样信息系统审查，它们是系统开发审查。
一、 系统开发审查
就系统开发审查而论，信息系统审查工作人员要担任开
发项目组顾问或充当其组员，她们可确保在初始系统设计过程中就设置了对应审查控制。信息系统审查小组参与系统开发活动已在前面指明。
二、 工作审查
对于信息服务那一部分工作要定时地进行工作审查，以确保正确管理。遵照分散任务标准可排除同一人既提供输入、实施处理，又负责确诊输出可能性。经过常常地轮换操作员，系统控制将最终操作同想欺骗系统任何企图。当一名操作员音像二个特定信息系统时，企业就轻易受到损失。同理，很多企业有指定假若政策，要求程序员和操作员在不少于两周整段时间内度假。审计员采取这些管理方法和若干其它技术可使乱用计算机系统可能性和机会减到最少。
三、应用审查
定时进行应用审查目标是要确定采取计算机系统完整性。这类审查和上述定时系统评价相比，其中相关目前和未来系统需要和系统有效性一样是关键考虑事项。就应用审查来讲，信息系统审计员要证实一个生产系统是否正按其设计规范进行工作。为了完成这个审查，审计员可能要追溯相关摘要汇报原始事务处理情况，或从原始处理来检验现在情况，为了检验系统内部控制功效，她们有意谋略中止系统或给系统设置故障。在信息系统审查过程中，可用专用审查软件来帮助进行应用审查。