|
 |
| 返回首页>>经营管理>>管理工具库>>规章制度典范>>信息管理系统>> |
系统开发过程（第三部分）
(10)根据可行性研究做出决策 完成可行性研究后，除了技术补充之外所有报告和资料全部交给信息处理政策委员会以便实施。技术补充包括准备可行性研究所要求的背景信息。它还包括一般的系统设计和开始第Ⅱ阶段(系统分析和设计)的一个框架。信息服务政策委员会感兴趣的主要是初始服务请求、范围、图解说明和利润/成本分析。 信息服务政策委员会能对可行性研究施加影响。信息服务政策委员会能够： ①拒绝建议。 2.第Ⅱ阶段-系统分析和设计 很少有几个项目能在批准可行性研究后立即实现。在得到批准和项目开始之间的估计时间可能是两年或两年以上。一旦项目获如通行命令，则开始第Ⅱ阶段-系统分析和设计。在第Ⅱ阶段，将描述所有输入/输出的格式和内容，并且完成详细的系统设计。第Ⅱ阶段的最后一步活动是准备程序说明，其中包括各种程序模块的说明书。重要的是牢记在第Ⅰ阶段和第Ⅱ阶段不编制程序。一个普遍容易犯的错误(经常与系统的质量和运行维护的水平密切相关)是压缩第Ⅱ阶段，使它提前完成以便开始第Ⅲ阶段-程序设计。粗糙的系统设计必将成倍、甚至三倍地增长项目所要求的程序设计量。 (11)指定项目组 与可行性研究组一样，项目组也应该有一个或多个系统分析员和一至多个来自所建议的系统范围内各业务方面的用户代表。如果可能的话，还要给项目组指派一名信息服务审计员，他不作为专职人员，而作为安全和控制方面的顾问。因为在第Ⅱ阶段结束之前程序员实际上并不参与进来，所以可以将指定程序员一事推迟到第Ⅱ阶段结束时再进行。可行性研究组的成员不一定都是项目组成员。在第Ⅰ阶段结束到第Ⅱ阶段开始之间的这一段时间里，通常委派他们到其他项目去。然而我们建议，只要可能则尽量将原有可行性研究组的人员指派到项目组。项目组的组长可以是信息服务人员，也可以是用户。 某些单位有按业务领域组织的固定的项目组。例如，某个项目组专门负责人力资源开发方面的老的系统的维护和新系统的开发，而另一项目组则负责会计和财务方面等等。另一种办法是项目组必须由信息服务人员和用户专业人员共同组成，而且是以项目为基础来指定项目组。究竟怎样组成项目组为好，显然要进行权衡。按专业组成的项目组很难预料在任务过多时或任务不足时由于人员不足或过剩所带来的损失。然而，这种项目组织使得项目组成员有更多的机会积累开发专业领域应用的经验。信息服务项目组组织的最好方式或许是既按专业领域组织而同时又保持一定的灵活性，使得项目组成员能在各项目组织之间流动，以便达到饱满的工作负荷。 根据项目的复杂程度和涉及范围的大小，每个项目组都有不同的最佳人数。项目组长的能力是一个重要的因素。有些地方，一个经理能有效地管理20个以上的人员，而另一些经理却连管理3个人都有困难。项目组的大小以及相对进度这些是用户、信息服务人员以及公司的经理感兴趣的问题。许多公司的经理人员有一种错误的概念，即如果将项目组人员增加一倍，那么完成项目的时间就应该减少一半。实际情况并非如此。一个能够直接分成若干个相同大小模块的简单项目，用两倍的人力，可以在原定的一半时间里实现。然而，绝大多数的项目是复杂的，有的甚至是极为复杂的，这就要求在所有项目组成员间进行内部协调。 图20.9.5说明增大项目组的规模时，将会发生的情况。在某确定的数目之前，每增加一个指派到项目组的人员都增大了对项目的贡献。在这之后，每增加一个人实际上减少了项目组每个人对项目工作的贡献。图上有一点是增人员的反射界线，超过那一点，再增加人对于项目的目标来说反而起相反作用。由于项目成员之间的关系复杂，因而使得生产效率降低。在为了满足项目限期而采取紧急措施的情况下，有时经理人员要求将所有资源转移到紧急的项目上，图20.9.5形象的说明了当一个项目组人员太多时，将会出现的情况。这时将不可能进行内部协调。当头都不知道尾在做什么的时候，即使每一个成员都忙于从事某种与项目有关的工作，项目的进度还是要停顿下来。 对于每一个确定的项目组都有最佳规模。与项目有关的所有经理和公司行政人员都应当很好地掌握这样一个格言：与其过分地扩大项目组织规模，造成欲速则不达的局面，还不如推迟项目的实现时间。
|