系统开发过程.docx

系统开发过程 □ 五个阶段 各种系统开发方法学在范围、复杂性、完善程度以及方法上有很大的不同。尽管有的 方法学分三个阶段，有的分 15 个阶段，但是每个方法学所描述的要完成的活动基本上是 相同的。 本章要阐述的最重要的一点是： 最好的方法学是那些始终把用户考虑进去的方法 学。过去的情况是，用户管理人员与信息服务开发组合作来完成系统的一般功能说明书， 然后，由信息服务人员来进行系统开发。现在，系统开发是各占 50%的比例；因此，用户 管理人员应该非常熟悉系统开发的大体过程，特别应该熟悉他们单位自己使用的方法学。 1. 第Ⅰ阶段— 2. 第Ⅱ阶段— 3. 第Ⅲ阶段— 4. 第Ⅳ阶段— 5. 第Ⅴ阶段— 第Ⅰ阶段—系统开始和可行性研究是在为开发一个建议的系统提供人力和资源之前 完成的。 第Ⅰ阶段多数的工作和编写的资料是第Ⅱ阶段的输入。 在第Ⅱ阶段—系统分析和 设计期间， 系统分析员与用户一起工作以编写详细的功能和系统的说明书。 将这些说明书 交给程序员，然后开始第Ⅲ阶段——程序设计。在第Ⅵ阶段—转换和实现期间，一旦软件 开发出来， 则建立数据文件， 转换现有系统， 并且实现新系统。 第Ⅴ阶段—实现后的评价。 在开始了系统寿命期中的生产阶段之后，提出 (经常被忽略的 ) □ 具体开发过程 下面将逐步地描述系统开发过程。至于具体的细节、相互的影响、方法、形式等，用 户管理人员应该与信息服务经理联系， 与他们讨论公司当前使用的方法学， 同时再看看公 司内部描述 1. 第Ⅰ阶段— 在第Ⅰ阶段的活动中很少有与其他四个阶段的活动相一致的。 此处所提供的方法包括 对于受拒绝后的再次服务请求的方法以及将技术转移可能性的研究合并到诸过程中这些 内容。第Ⅰ阶段最终的产品有两个部分。第一部分是实际的可行性研究报告，它包含对建 议的或改进的系统的描述以及利润 / 成本分析。第二部分是系统的初步设计。它对于估价 成本和利润是必要的。该初步设计是第Ⅱ阶段— 将系统的初步设计并入可行性研究的依据是， 多数可行性研究是以概念而不是以设计 为基础的。如果在描述系统目标上花的时间太少，那么成本估计，甚至利润估计将是错误 的。用概念来指导可行性研究注定会导致成本过高，而且用户不满意。在系统初步设计上 所花费的时间是值得的， 即使拒绝可行性研究也是如此。 因为所编写的资料将必然会被证 下述编号的活动与表 20.9.2 (1) 图 20.5.1 说明了包括对受拒绝的请求再次请求处理的一种方法。所请求的服务毕竟 是用户做的，因此，应该由用户着手进行。我们鼓励用户管理人员请求信息服务人员的帮 助， 但是应该再一次强调， 业务领域的管理人员应该对各种大小的服务请求都提供合适的 (2) 正如在责任矩阵中所注释的那样，信息服务管理人员只能承诺小的项目 针所确定的小项目 ) ( 由公司的方 (3) 信息服务经理和用户经理共同来指定适当的混合的人选以组成可行性分析研究组。 该 组至少由一名系统分析员和一名用户代表组成。 可行性研究组的大小取决于可行性研究的 范围和时间限制 用户代表应该熟悉当前专业领域的所有工作，用户经理、总经理助理，或专业领域分 析员是合理的候选者， 用户的系统分析员， 具有计算机信息处理基础知识的情况已经越来 必须指定一个人担任可行性研究组的组长， 哪怕只是两个人的可行性研究组也需要一 个组长。直到 1980 年为止，多数的可行性研究组和项目组是由一个高级系统分析员或一 个项目负责人来领导的。在信息服务部门中，这两种人是固定分工做这项工作的。目前越 来越多的公司采取这样一种政策， 即由用户担任项目组组长。 这种将主要责任下放给最终 用户的做法将进一步鼓励用户参与系统设计。 在这种政策上取得成功经验的那些公司已经 指派了一些具有杰出管理经验和具有某些计算机和信息处理知识的用户人员担任项目组 组长。在任何情况下，组长必须对该组的工作有一个总的安排。如果要求一个用户代表既 作为可行性研究组或项目组的组长而同时又要求他继续履行业务领域的职责， 那么该项目 是肯定要失败的。 有好些公司已经采用了一种政策， 即自动地指派受系统影响最大的业务 领域的经理作为可行性研究组和项目组的领导以后该经理将从原来的工作职责中解