网络开发人员工作细则

《网络开发人员工作细则》由会员分享，可在线阅读，更多相关《网络开发人员工作细则（33页珍藏版）》请在金锄头文库上搜索。

1、网 络 开 发 人 员 工 作 细 则附件1：网络开发人员工作流程图附件2:系统开发的责任在系统开发的过程中何时涉及到个人、小组和部门以及涉及到的 程度，并针对每一种活动提出了所涉及的人员和机构。其中：对于那 些有较大失败危险的非结构化的项目，则需要设置更多的阶段标志。下面描述一个人员和机构的含义。1、可行性研究组。这个组由指定来完成可行性研究的用户和信 息服务人员组成。2、项目组。由指定来开发和实现计算机信息系统或对现有系统 作重要改进的用户和信息服务人员组成。3、住处服务管理部门。该机构涉及到信息服务管理组，而不一 定指某个具体人。在一个小单位中，它可能局限于信息服务的一些高 级负责人。在

2、一个大单位中，经理最适合于承担机构所涉及的特定的 任务。4、未指派的程序员和分析员，包括未指派到所讨论的可行性研 究组和项目组的他的信息服务专职人员。5、业务领域管理人员。所有影响到建议开发项目的或者受该项 目的业务领域的管理人员都包括在本责任机构中。6、未指派的专业人员。包括将影响到建议的开发项目或受该项 目的影响的那些专业人员，但他们并未旨派到可行性研究组或项目 组。7、住处系统政策委员会。信息系统政策委员会是对公司所有的信息服务的和一个高级指导委员会。&信息系统审计组。信息服务审计组的一个重要职能是保证在开发过程中对计算机信息系统建立适当的控制。附件3:系统开发过程五个阶段各种系统开发方

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

4、四阶段一转换和实现5第五阶段一实现后的评价第一阶段一系统开始和可行性研究是在为开发一个建议的系统提供人力和资源之前完成的。第一阶段多数的工作和编写的资料是第 二阶段的输入。在第二阶段一系统分析和设计期间，系统分析员与用 户一起工作以编写详细的功能和系统的说明书。将这些说明书交 给程序员，然后开始第三阶段一一程序设计。在第二阶段一转换和实 现期间，一旦软件开发出来，则建立数据文件，转换现有系统，并且 实现新系统。第五阶段一实现后的评价。在开始了系统寿命期中的生 产阶段之后，提出(经常被忽略的)实现后的评价要求。 具体开发过程下面将逐步地描述系统开发过程。至于具体的细节、相互的影响、 方法、形式等

5、，用户管理人员应该与信息服务经理联系，与他们讨论 公司当前使用的方法学，同时再看看公司内部描述方学的手册。第1阶段一系统开始和可行性研究在第I阶段的活动中很少有与其他四个阶段的活动相一致的。此处所提供的方法包括对于受拒绝后的再次服务请求的方法以及将技 术转移可能性的研究合并到诸过程中这些内容。 第I阶段最终的产品 有两个部分。第一部分是实际的可行性研究报告， 它包含对建议的或 改进的系统的描述以及利润，成本分析。第二部分是系统的初步设计。 它对于估价成本和利润是必要的。该初步设计是二阶段一系统分析和 设计的直接输入。将系统的初步设计并入可行性研究的依据是， 多数可行性研究是 以概念而不是以设计

6、为基础的。如果在描述系统目标上花的时间太 少，那么成本估计，甚至利润估计将是错误的。用概念来指导可行性 研究注定会导致成本过高，而且用户不满意。在系统初步设计上所花 费的时间是值得的，即使拒绝可行性研究也是如此。因为所编写的资 料将必然会被证实其他项目中是有价值的。(1)提交服务请求对受拒绝的请求再次请求处理的一种方法。 所请求的服务毕竟是 用户做的，因此，应该由用户着手进行。我们鼓励用户管理人员请求 信息服务人员的帮助，但是应该再一次强调，业务领域的管理人员应 该对各种大小的服务请求都提供合适的资料。(2) 估价服务请求正如在责任矩阵中所注释的那样，信息服务管理人员只能承诺小 的项目(由公司

7、的方针所确定的小项目)。(3) 指定可行性研究组信息服务经理和用户经理共同来指定适当的混合的人选以组成 可行性分析研究组。该组至少由一名系统分析员和一名用户代表组 成。可行性研究组的大小取决于可行性研究的范围和时间限制。用户代表应该熟悉当前专业领域的所有工作，用户经理、总经理助理，或专业领域分析员是合理的候选者，用户的系统分析员，具有 计算机信息处理基础知识的情况己经越来越普遍了。必须指定一个人担任可行性研究组的组长，哪怕只是两个人的可行性研究组也需要一个组长。直到 1980年为止，多数的可行性研究 组和项目组是由一个高级系统分析员或一个项目负责人来领导的。在信息服务部门中，这两种人是固定分工

8、做这项工作的。 目前越来越多 的公司采取这样一种政策，即由用户担任项目组组长。这种将主要责 任下放给最终用户的做法将进一步鼓励用户参与系统设计。在这种政策上取得成功经验的那些公司己经指派了一些具有杰出管理经验和 具有某些计算机和信息处理知识的用户人员担任项目组组长。在任何 情况下，组长必须对该组的工作有一个总的安排。如果要求一个用户 代表既作为可行性研究组或项目组的组长而同时又要求他继续履行 业务领域的职责，那么该项目是肯定要失败的。有好些公司己经采用 了一种政策，即自动地指派受系统影响最大的业务领域的经理作为可 行性研究组和项目组的领导以后该经理将从原来的工作职责中解脱 出来，而用他（她）的

9、全部时间管理可行性研究（或项目）组。这种人事 安排己经成为当今的主流，其困难是用户经理需要离开原来主管的业 务部门少则两个月多则三年后才能回他原来的工作岗位上。（4）标列约束条件在系统开发的过程一开始，可行性研究组与信息服务人员和用户 经理密切合作标列出设备、成本、进度、规程、软件以及操作上的约 束条件。它们可能限制建议的系统的定义和设计。（5）整理现有系统的资料整理现有系统资料的主要理由是：如果可行性研究组不充分了解 现有系统，那么他们就不可能有效地完成所建议的系统的初始设计。 已经建立起来的多数人工系统并没有经过真正的设计。在这些系统 中，必须从手稿整理出资料。如果一个建议的系统是改进一个

10、现有 的计算机信息系统，那么可行性研究组只需要保证现有资料的完整性 和保持最新版本就行了。现有系统所形成的任何资料将给设计阶段提供有价值的输入（如果批准开发该系统）。即便建议的系统遭到拒绝，也能对现有系统提 供基本的资料，并且可能透彻地理解理有系统。现有系统的资料由 四部分组成:0系统报告和资料；0系统数据文件;0系统数据元以及说 明现有系统的数据、信息和工作流程的图表。前三部分 （报告、文件 和数据元）可分类如下：0当前使用的，而且在建议的系统中以目前的形式保留下来 ；0当前使用的，但是修改后才在建议的系统中使用；0当前使用的，但是在建议的系统中将被删除而不再保留的。例如，列出所有现有的报告

11、和标准的资料，并按上述分类给定 一种状态。在报告上将标明相对周期（如，每天，每周）以及分发范围。对于现有系统的所有数据文件都标明有关的存储介质（如，3x5 的卡片，磁带，马尼拉折纸机，磁盘等等 ）以及存储方式。例如，一 个名字一地址文件可以存储在许多张 3x5的卡片上，并且按名字的字 母顺序排列。一个人工系统所保存的文件数总是令人吃惊的，即便对 于业务领域管理人员也是如此。为了完善现有文件的资料，将每个文 件的记录的样式和简单描述附在文件表中。系统数据元（即，社会保险号，顾客名，货号等等）是直接列出的， 而不必关系有关的文件。数据元经常在几个文件中重复出现。除了状 态指示符之外，如果数据的名字

12、不能自我说明，则必须对每个数据数 据元进行描述。有关数据元的其他信息还包括更新要求（如，每天，每周，每月，或根据需要更新等等）、来源（如，代办处，资料，系统， 工作人员等等）以及职责（如，部门名和负责更新者的职务）。说明在整 理现有系统资料时数据元可能采用的一种典型格式。我们通过将系统简化为输入、处理和输出等几个基本组成部分来表示整理现有系统资料的工作过程。然后用图形描绘出各部分之间的 逻辑关系。有多种图像表示技术来做这件事。最为流行的（尽管不一定是最好的）是流程图。其他的更为结构化的技术还有:数据、信息和 工作流程的一个概貌。它着重强调系统申控制工作流程的那些数据 元。这些图应该刻划人工和计

13、算机的处理步骤， 并且以适当的顺序安 排每一处理步骤。通常以能最好地显示出工作过程的方式来组织和提 供这些图。它们可以是由一些随机事件、功能或按小的和大的周期来 驱动的子系统，也可以是若干子系统；既可以是层次的，也可以是混 合的。很少有几个系统是完全顺序的，因此，在多数情况下可以应用 模块方法。（6）调查研究技术转移的可能性为了更好地利用现有的技术，许多公司正在进行将有关技术转移 到他们的系统开发方法学中可能性的调查。 鼓励调查技术转移的可能 性和（或）可行性的政策必将带来人力资源的大量节省。特别对程序员 和分析员更是如此，合适的技术转移将使这些人的工作集中于还没有 现成软件的特定行业的应用领

14、域。技术转移可能性的调查是从走访那些己经实现的，而且与所建议的系统有类似规模和工作的系统。可行性研究组还应该调查商品软件目录，以便找到适合的可应用的软 件。如果认为技术转移是可行的，则可行性研究组说明怎样使用这些 技术以及为适应现有环境所要求的修改范围。如果使用标准的方法来进行技术转移潜力调查， 那么提出要求的 公司应该采取与具有类似要求的其他公司合作的政策。(7) 完成建议系统的初步设计可行性研究组要走访专业人员以获得一般的系统要求，然后，将这些要求转换成初步的系统设计。 设计过程是交互的，用户经理和可 行性研究组需要经常就设计思想和方法等交换意见，用生动的文字和 图形说明来形成建议的系统初

15、步设计的资料，这些生韵的文字(用 非技术词汇)描述了所建议的系统的基本工作过程，而且常常同时附 有图形说明。这些文字图表也将列举出那些大大违背现有工作方式而 建议的系统所期望的手续、手段和方法。这些文字图像也将描述建议 的系统与人工系统以及建议系统必须与之兼容的自动系统之间的关 系。(8) 确定项目范围可行性研究组与信息服务人员以及用户管理人员合作估计初步 设计中所刻划的系统的复杂程度。并对开发项目今后的每一个阶段进 行人力资源要求的估计(用户，信息服务人员及其他人员)。此外，还 注意到培训和计算机机时要求。(9) 准备利润，成本分析报告一旦完成初步设计并且确定了项目的范围， 则可以开始利润，

16、成 本分析。不幸的是，由于用户和信息服务管理人员都希望加快可行性 研究阶段，所以，一些关键的步骤被省略了，因此造成在利润、成本 估计上的错误。仅仅根据一种概念是不可能精确的反映出利润和成 本的。设计中的某些步骤是必不可少的。另一种在形成公司决策过程中所隐含的错误将不可避免地把那些难以确定的利润也算成资金收入。 当今许多复杂的，综合的系统为 公司的利益做出了重大的贡献，而做到这样程度是因为它们经历了漫 长的、不可捉摸和难以预见的道路。评价信息服务项目的好处和价 值是一个主观的过程，它要求具有成本和利润方面的实际的知识。 此 外，决策者对于正的和负的不确定的利润要有透彻的理解。使用美元作为所有成本和利润的统一的计量标准