文档介绍：: .
个项目负责人来领导的。在信息服务部门中，这两种人是固定
分工做这项工作的。目前越来越多的公司采取这样一种政策，即由用户担任项目
组组长。这种将主要责任下放给最终用户的做法将进一步鼓励用户参与系统设
计。在这种政策上取得成功经验的那些公司已经指派了一些具有杰出管理经验和
具有某些计算机和信息处理知识的用户人员担任项目组组长。在任何情况下，组
长必须对该组的工作有一个总的安排。如果要求一个用户代表既作为可行性研究
组或项目组的组长而同时又要求他继续履行业务领域的职责，那么该项目是肯定
要失败的。有好些公司已经采用了一种政策，即自动地指派受系统影响最大的业
务领域的经理作为可行性研究组和项目组的领导以后该经理将从原来的工作职
责中解脱出来，而用他(她)的全部时间管理可行性研究(或项目)组。这种人事安
排已经成为当今的主流，其困难是用户经理需要离开原来主管的业务部门少则两
个月多则三年后才能回他原来的工作岗位上。
(4)标列约束条件
在系统开发的过程一开始，可行性研究组与信息服务人员和用户经理密切合
作标列出设备、成本、进度、规程、软件以及操作上的约束条件。它们可能限制
建议的系统的定义和设计。
(5)整理现有系统的资料
整理现有系统资料的主要理由是：如果可行性研究组不充分了解现有系统，
那么他们就不可能有效地完成所建议的系统的初始设计。已经建立起来的多数人
工系统并没有经过真正的设计。在这些系统中，必须从手稿整理出资料。如果一
个建议的系统是改进一个现有的计算机信息系统，那么可行性研究组只需要保证
现有资料的完整性和保持最新版本就行了。
现有系统所形成的任何资料将给设计阶段提供有价值的输入(如果批准开发
该系统)。即便建议的系统遭到拒绝，也能对现有系统提供基本的资料，并且可
3能透彻地理解理现有系统。现有系统的资料由四部分组成：①系统报告和资料；
②系统数据文件；③系统数据元以及④说明现有系统的数据、信息和工作流程的
图表。前三部分(报告、文件和数据元)可分类如下：
①当前使用的，而且在建议的系统中以目前的形式保留下来；
②当前使用的，但是修改后才在建议的系统中使用；
③当前使用的，但是在建议的系统中将被删除而不再保留的。
例如，列出所有现有的报告和标准的资料，并按上述分类给定一种状态。在
报告上将标明相对周期(如，每天，每周)以及分发范围。
对于现有系统的所有数据文件都标明有关的存储介质(如，3×5 的卡片，磁
带，马尼拉折纸机，磁盘等等)以及存储方式。例如，一个名字一地址文件可以
存储在许多张 3×5 的卡片上，并且按名字的字母顺序排列。一个人工系统所保
存的文件数总是令人吃惊的，即便对于业务领域管理人员也是如此。为了完善现
有文件的资料，将每个文件的记录的样式和简单描述附在文件表中。
系统数据元(即，社会保险号，顾客名，货号等等)是直接列出的，而不必关
系有关的文件。数据元经常在几个文件中重复出现。除了状态指示符之外，如果
数据的名字不能自我说明，则必须对每个数据元进行描述。有关数据元的其他信
息还包括更新要求(如，每天，每周，每月，或根据需要更新等等)、来源(如，
代办处，资料，系统，工作人员等等)以及职责(如，部门名和负责更新者的职务)。
说明在整理现有系统资料时数据元可能采用的一种典型格式。
整理现有系统的资料：系统数据元
报告标题 系统数据元 日期
系统标题 医疗信息系统 标识 MLS
目前的 需要修改 需要 更 新 来源 职责
删除 要求
编号 标题 描述
1 名字