管 理 信 息 系 统 (10).ppt

用户方人员和开发方人员 用户方人员细分为用户方项目管理人员、用户方业务人员和用户方决策人员。 开发方人员分为开发方的项目管理人员和开发方技术人员。 9.5 项目的沟通管理 （一）开发方与用户方的沟通 （二）用户方成员之间的沟通 （三）项目管理人员与开发方技术人员的沟通 （四）硬件与软件问题的沟通 （五）系统性能与灵活性问题的沟通 （一）开发方与用户方的沟通 用户方一般对计算机系统工程缺乏全面的了解，而开发方对用户方的需求细节往往了解得不充分，这使得用户方与开发方对项目的理解从一开始就存在着差异。 （一）开发方与用户方的沟通（续） 这种认识上的差异与理解的不同往往在开发初期不易被察觉或者被故意忽略。 当系统开发结束时（或告一段落时），双方才发现这种差异使开发出的系统与实际需求偏差甚远。 开发初期的认识差异 用户方 开发方 “先把精力集中在整个系统的总的需求上！” “我给你提出一些细节需求！” “这些问题留待后面讨论！” 开发初期的认识差异（续） 用户方 开发方 “我们那时候没有考虑这些细节需求啊！” “我提出的细节需求怎么没实现啊？” 系统开发结束后…… 开发初期的认识差异（续） 开发初期，用户方的项目管理人员应该把这些“留待后面讨论”的需求单独记录整理。 在开发方做完系统的整体需求分析后，项目管理人员应及时推动提出对系统进行进一步的、更深入的、细致的、具体的需求分析，以解决那些开发方要“留待后面讨论”的问题。 针对未确定需求的认识差异 用户方 开发方 “嗯，这就是确定的需求，按照这个做吧！！” “这部分需求我们还要考虑，不过你们可以先按现在的模式做。” 系统开发过程中…… 针对未确定需求的认识差异（续） 用户方 开发方 “不会吧！这样修改的话我们需要做大量的修改工作！” “那个未确定的需求我们需要按照这样的方式做” 针对未确定需求的认识差异（续） 对这种情况，用户方业务人员应尽量将需求陈述清楚，对不能确定的需求，应提出几种可能的实施方案供开发方参考，以保证开发方进行分析与系统设计时，将这些尚未确定的部分设计成灵活可变的功能。 针对系统分析报告的认识差异 用户方 开发方 “看来客户已经认可了我们的分析报告，我们对需求理解的很准确！” “这么多技术术语，犹如天书啊！不过他们能写出来，应该已经了解我们的需求。” 系统 分析 报告 针对系统分析报告的认识差异（续） 用户方的项目管理人员一定要要求开发方对需求分析报告进行进一步更详细的解释。 开发方技术人员也应尽力用通俗易懂的方式在系统分析报告中描述系统需求，并耐心地听取用户方业务人员对这些需求的意见。 “头儿，您对系统有哪些功能要求，尽管提出来，一切都没有问题” 对软件开发工具的认识差异 用户方 开发方 “我们不是超人啊，怎么能实现这些离谱的需求啊！” “计算机应该能实现这个功能，为什么会作不到？” 对软件开发工具的认识差异（续） 双方应详细、务实、具体地制定系统最终实现的目标，切不可用一些简单的术语来笼统概括需求。 这种抽象、笼统的描述只能导致用户对管理信息系统的错误理解，认为管理系统应该实现他所期望的所有功能。 开发方与用户方的沟通要点 项目管理人员要注意安排开发方人员与需求方使用人员的交流，保证有效畅通的交流渠道。 在交流中用户方要尽量避免含糊不清的需求，而开发方要杜绝敷衍了事、得过且过的行为。 10 10 14 10 （3）确定关键路径 可行性分析 时差 0 准备问题界定报告 时差 0 重点访谈 时差 1 与用户交流 时差 0 与上级部门交流 时差 3 系统设计与开发 时差 0 明确系统功能 时差 1 明确信息结构 时差 0 活动描述 活动序号 工期估计 LS LF 0 4 4 5 6 10 5 8 10 14 14 42 10 ES EF 0 4 4 5 5 9 5 5 7 10 14 9 14 42 13 （四）计划评审技术 计划评审技术（Program Evaluation and Review Technique——PERT）假设项目持续时间以及整个项目完成时间是随机的，且服从某种概率分布，从而估计整个项目在某个时间内完成的概率。 PERT的三种估计时间 乐观时间（Optimistic Time）——任何事情都顺利的情况下，完成某项工作的时间，通常用a表示； 最可能时间（Most Likely Time）——正常情况下，完成某项工作的时间，通常用m表示； 悲观时间（Pessimistic Time）——最不利的情况下，完成某项工作的时间，通常用b表示。 活动期望时间的计算 假定三个估计服从β分布，由此可算出每个活动的期望时间ti： 其中：ai表示第i项活动的乐观时间，