同时再看看公司内部描述方法学的手册。

    1. Ⅰ

—

第 阶段 系统开始和可行性研究

    

Ⅰ

在第 阶段的活动中很少有与其他四个阶段的活动相一致的。此处所提供的方

法包括对于受拒绝后的再次服务请求的方法以及将技术转移可能性的研究合并

Ⅰ

到诸过程中这些内容。第 阶段最终的产品有两个部分。第一部分是实际的可行性

研究报告，它包含对建议的或改进的系统的描述以及利润

/成本分析。第二部分

Ⅱ

—

是系统的初步设计。它对于估价成本和利润是必要的。该初步设计是第 阶段 系

统分析和设计的直接输入。

    将系统的初步设计并入可行性研究的依据是，多数可行性研究是以概念而不

是以设计为基础的。如果在描述系统目标上花的时间太少，那么成本估计，甚至

利润估计将是错误的。用概念来指导可行性研究注定会导致成本过高，而且用户

不满意。在系统初步设计上所花费的时间是值得的，即使拒绝可行性研究也是如

此。因为所编写的资料将必然会被证实其他项目中是有价值的。

    下述编号的活动与表 20.9.2 的系统开发责任矩阵相对应。

    (1)提交服务请求

    图 20.5.1 说明了包括对受拒绝的请求再次请求处理的一种方法。所请求的服

务毕竟是用户做的，因此，应该由用户着手进行。我们鼓励用户管理人员请求信

息服务人员的帮助，但是应该再一次强调，业务领域的管理人员应该对各种大

  

小的服务请求都提供合适的资料。

(2)估价服务请求

    正如在责任矩阵中所注释的那样，信息服务管理人员只能承诺小的项目(由

公司的方针所确定的小项目

)。

    (3)指定可行性研究组

    信息服务经理和用户经理共同来指定适当的混合的人选以组成可行性分析研

究组。该组至少由一名系统分析员和一名用户代表组成。可行性研究组的大小取

决于可行性研究的范围和时间限制。

    用户代表应该熟悉当前专业领域的所有工作，用户经理、总经理助理，或专

业领域分析员是合理的候选者，用户的系统分析员，具有计算机信息处理基础

知识的情况已经越来越普遍了。

    必须指定一个人担任可行性研究组的组长，哪怕只是两个人的可行性研究组

也需要一个组长。直到

1980 年为止，多数的可行性研究组和项目组是由一个高

2