网络开发人员的工作细则

1、网网 络络 开开 发发 人人 员员 工工 作作 细细 则则 附件附件 1：网络开发人员工作流程图 综合信息中心经理网络开发人员岗位职责信息系统开发 系统开发责任 系统开发责任 系统开始与可行性研究 系统审查评价 系统分析和设计 程序设计 转换和实现 实验后评价 综合副总 附件附件 2： 系统开发的责任系统开发的责任 在系统开发的过程中何时涉及到个人、小组和部门以及涉及到 的程度，并针对每一种活动提出了所涉及的人员和机构。其中：对 于那些有较大失败危险的非结构化的项目，则需要设置更多的阶段 标志。 下面描述一个人员和机构的含义。 1、可行性研究组。这个组由指定来完成可行性研究的用户和信 息服务人员组成。 2、项目组。由指定来开发和实现计算机信息系统或对现有系统 作重要改进的用户和信息服务人员组成。 3、住处服务管理部门。该机构涉及到信息服务管理组，而不一 定指某个具体人。在一个小单位中，它可能局限于信息服务的一些 高级负责人。在一个大单位中，经理最适合于承担机构所涉及的特 定的任务。 4、未指派的程序员和分析员，包括未指派到所讨论的可行性研 究组和项目组的他的信息服务专职人员。 5、业务

2、领域管理人员。所有影响到建议开发项目的或者受该项 目的业务领域的管理人员都包括在本责任机构中。 6、未指派的专业人员。包括将影响到建议的开发项目或受该项 目的影响的那些专业人员，但他们并未旨派到可行性研究组或项目 组。 7、住处系统政策委员会。信息系统政策委员会是对公司所有的 信息服务的和一个高级指导委员会。 8、信息系统审计组。信息服务审计组的一个重要职能是保证在 开发过程中对计算机信息系统建立适当的控制。 附件附件 3： 系统开发过程系统开发过程 五个阶段 各种系统开发方法学在范围、复杂性、完善程度以及方法上有 很大的不同。尽管有的方法学分三个阶段，有的分 15 个阶段，但是 每个方法学所描述的要完成的活动基本上是相同的。本章要阐述的 最重要的一点是:最好的方法学是那些始终把用户考虑进去的方法学。 过去的情况是，用户管理人员与信息服务开发组合作来完成系统的 一般功能说明书，然后，由信息服务人员来进行系统开发。现在， 系统开发是各占 50%的比例;因此，用户管理人员应该非常熟悉系统 开发的大体过程，特别应该熟悉他们单位自己使用的方法学。 系统开发过程可分为五个阶段来描述。这五个阶段是

3、: 1第一阶段一系统开始和可行性研究 2第二阶段一系统分析和设计 3第三阶段一程序设计 4第四阶段一转换和实现 5第五阶段一实现后的评价 第一阶段一系统开始和可行性研究是在为开发一个建议的系统 提供人力和资源之前完成的。第一阶段多数的工作和编写的资料是 第二阶段的输入。在第二阶段一系统分析和设计期间，系统分析员 与用户一起工作以编写详细的功能和系统的说明书。将这些说明书 交 给程序员，然后开始第三阶段程序设计。在第二阶段一转换和 实现期间，一旦软件开发出来，则建立数据文件，转换现有系统， 并且实现新系统。第五阶段一实现后的评价。在开始了系统寿命期 中的生产阶段之后，提出(经常被忽略的)实现后的评价要求。 具体开发过程 下面将逐步地描述系统开发过程。至于具体的细节、相互的影 响、方法、形式等，用户管理人员应该与信息服务经理联系，与他 们讨论公司当前使用的方法学，同时再看看公司内部描述方 学的 手册。 第 1 阶段一系统开始和可行性研究 在第 I 阶段的活动中很少有与其他四个阶段的活动相一致的。 此处所提供的方法包括对于受拒绝后的再次服务请求的方法以及将 技术转移可能性的研究合并到诸过程中

4、这些内容。第 I 阶段最终的 产品有两个部分。第一部分是实际的可行性研究报告，它包含对建 议的或改进的系统的描述以及利润，成本分析。第二部分是系统的 初步设计。它对于估价成本和利润是必要的。该初步设计是二阶段 一系统分析和设计的直接输入。 将系统的初步设计并入可行性研究的依据是，多数可行性研究 是以概念而不是以设计为基础的。如果在描述系统目标上花的时间 太少，那么成本估计，甚至利润估计将是错误的。用概念来指导可 行性研究注定会导致成本过高，而且用户不满意。在系统初步设计 上所花费的时间是值得的，即使拒绝可行性研究也是如此。因为所 编写的资料将必然会被证实其他项目中是有价值的。 (1)提交服务请求 对受拒绝的请求再次请求处理的一种方法。所请求的服务毕竟 是用户做的，因此，应该由用户着手进行。我们鼓励用户管理人员 请求信息服务人员的帮助，但是应该再一次强调，业务领域的管理 人员应该对各种大小的服务请求都提供合适的资料。 (2)估价服务请求 正如在责任矩阵中所注释的那样，信息服务管理人员只能承诺 小的项目(由公司的方针所确定的小项目)。 (3)指定可行性研究组 信息服务经理和用户经理共同来指

5、定适当的混合的人选以组成 可行性分析研究组。该组至少由一名系统分析员和一名用户代表组 成。可行性研究组的大小取决于可行性研究的范围和时间限制。 用户代表应该熟悉当前专业领域的所有工作，用户经理、总经 理助理，或专业领域分析员是合理的候选者，用户的系统分析员， 具有计算机信息处理基础知识的情况己经越来越普遍了。 必须指定一个人担任可行性研究组的组长，哪怕只是两个人的 可行性研究组也需要一个组长。直到 1980 年为止，多数的可行性研 究组和项目组是由一个高级系统分析员或一个项目负责人来领导的。 在信息服务部门中，这两种人是固定分工做这项工作的。目前越来 越多的公司采取这样一种政策，即由用户担任项目组组长。这种将 主要责任下放给最终用户的做法将进一步鼓励用户参与系统设计。 在这种政策上取得成功经验的那些公司己经指派了一些具有杰出管 理经验和具有某些计算机和信息处理知识的用户人员担任项目组组 长。在任何情况下，组长必须对该组的工作有一个总的安排。如果 要求一个用户代表既作为可行性研究组或项目组的组长而同时又要 求他继续履行业务领域的职责，那么该项目是肯定要失败的。有好 些公司己经采用了一种政

6、策，即自动地指派受系统影响最大的业务 领域的经理作为可行性研究组和项目组的领导以后该经理将从原来 的工作职责中解脱出来，而用他(她)的全部时间管理可行性研究(或 项目)组。这种人事安排己经成为当今的主流，其困难是用户经理需 要离开原来主管的业务部门少则两个月多则三年后才能回他原来的 工作岗位上。 (4)标列约束条件 在系统开发的过程一开始，可行性研究组与信息服务人员和用 户经理密切合作标列出设备、成本、进度、规程、软件以及操作上 的约束条件。它们可能限制建议的系统的定义和设计。 (5)整理现有系统的资料 整理现有系统资料的主要理由是:如果可行性研究组不充分了解 现有系统，那么他们就不可能有效地完成所建议的系统的初始设计。 已经建立起来的多数人工系统并没有经过真正的设计。在这些系统 中，必须从手稿整理出资料。如果一个建议的系统是改进一个现有 的计算机信息系统，那么可行性研究组只需要保证现有资料的完整 性和保持最新版本就行了。 现有系统所形成的任何资料将给设计阶段提供有价值的输入(如 果批准开发该系统)。 即便建议的系统遭到拒绝，也能对现有系统 提供基本的资料，并且可能透彻地理解理有系 统

7、。现有系统的资料 由四部分组成:0 系统报告和资料;0 系统数据文件;0 系统数据元以及 说明现有系统的数据、信息和工作流程的图表。前三部分(报告、文 件和数据元)可分类 如下: 0 当前使用的，而且在建议的系统中以目前的形式保留下来; 0 当前使用的，但是修改后才在建议的系统中使用; 0 当前使用的，但是在建议的系统中将被删除而不再保留的。 例如，列出所有现有的报告和标准的资料，并按上述分类给定 一种状态。在报告上将标明相对周期(如，每天，每周)以及分发范围。 对于现有系统的所有数据文件都标明有关的存储介质(如，3x5 的卡片，磁带，马尼拉折纸机，磁盘等等)以及存储方式。例如，一 个名字一地址文件可以存储在许多张 3x5 的卡片上，并且按名字的 字母顺序排列。一个人工系统所保存的文件数总是令人吃惊的，即 便对 于业务领域管理人员也是如此。为了完善现有文件的资料，将每个 文件的记录的样式和简单描述附在文件表中。 系统数据元(即，社会保险号，顾客名，货号等等)是直接列出的， 而不必关系有关的文件。数据元经常在几个文件中重复出现。除了 状态指示符之外，如果数据的名字不能自我说明，则必须对每

8、个数 据数据元进行描述。有关数据元的其他信息还包括更新要求(如，每 天，每周，每月，或根据需要更新等等)、来源(如，代办处，资料， 系统，工作人员等等)以及职责(如，部门名和负责更新者的职务)。 说明在整理现有系统资料时数据元可能采用的一种典型格式。 我们通过将系统简化为输入、处理和输出等几个基本组成部分 来表示整理现有系统资料的工作过程。然后用图形描绘出各部分之 间的逻辑关系。有多种图像表示技术来做这件事。最为流行的(尽管 不一定是最好的)是流程图。其他的更为结构化“的技术还有:数据、 信息和工作流程的一个概貌。它着重强调系统申控制工作流程的那 些数据元。这些图应该刻划人工和计算机的处理步骤，并且以适当 的顺序安排每一处理步骤。通常以能最好地显示出工作过程的方式 来组织和提供这些图。它们可以是由一些随机事件、功能或按小的 和大的周期来驱动的子系统，也可以是若干子系统;既可以是层次的， 也可以是混合的。很少有几个系统是完全顺序的，因此，在多数情 况下可以应用模块方法。 (6)调查研究技术转移的可能性 为了更好地利用现有的技术，许多公司正在进行将有关技术转 移到他们的系统开发方法学中可能

9、性的调查。鼓励调查技术转移的 可能性和(或)可行性的政策必将带来人力资源的大量节省。特别对程 序员和分析员更是如此，合适的技术转移将使这些人的工作集中于 还没有现成软件的特定行业的应用领域。 技术转移可能性的调查 是从走访那些己经实现的，而且与所建议的系统有类似规模和工作 的系统。可行性研究组还应该调查商品软件目录，以便找到适合的 可应用的软件。如果认为技术转移是可行的，则可行性研究组说明 怎样使用这些技术以及为适应现有环境所要求的修改范围。 如果使用标准的方法来进行技术转移潜力调查，那么提出要求 的公司应该采取与具有类似要求的其他公司合作的政策。 (7)完成建议系统的初步设计 可行性研究组要走访专业人员以获得一般的系统要求，然后， 将这些要求转换成初步的系统设计。设计过程是交互的，用户经理 和可行性研究组需要经常就设计思想和方法等交换意见，用生动的 文字和图形说明来形成建议的系统初步设计的资料，这些生韵的文 字(用 非技术词汇)描述了所建议的系统的基本工作过程，而且常常同时附 有图形说明。这些文字图表也将列举出那些大大违背现有工作方式 而建议的系统所期望的手续、手段和方法。这些文字图像也将描述 建议的系统与人工系统以及建议系统必须与之兼容的自动系统之间 的关系。 (8)确定项目范围 可行性研究组与信息服务人员以及用户管理人员合作估计初步 设计中所刻划的系统的复杂程度。并对开发项目今后的每一个阶段 进行人力资源要求的估计(用户，信息服务人员及其他人员)。此外， 还注意到培训和计算机机时要求。 (9)准备利润，成本分析报告 一旦完成初步设计并且确定了项目的范围，则可以开始利润， 成本分析。不幸的是，由于用户和信息服务管理人员都希望加快可 行性研究阶段，所以，一些关键的步骤被省略了，因此造成在利润、 成本估计上的错误。仅仅根据一种概念是不可能精确的反映出利润 和成 本的。设计中的某些步骤是必不可少的。 另一种在形成公司决策过程中所隐含的错误将不可避免地把那 些难以确定的利润也算成资金收入。当今许多复杂的，综合的系统 为公司的利益做出了重大的贡献，而做到这样程度是因为它们经历 了漫长的、不可捉摸和难以预见的道路。评价信息服务项目的好处 和价 值是一个主观的过程，它要求具有成本和利

《网络开发人员的工作细则》由会员F****n分享，可在线阅读，更多相关《网络开发人员的工作细则》请在金锄头文库上搜索。