互联网网络计划图cai.ppt

计划评审技术PERT PERT的形式与CPM网络计划基本相同，只是在工作延续时间方面CPM仅需要一个确定的工作时间，而PERT需要工作的三个时间估计，包括最短时间a、最可能时间m及最长时间b，然后按照β分布计算工作的期望时间t。PERT通常使用的计算方法是CPM的方法。 估算的技巧 避免无准备的估算 不要随口说出一个估算 留出估算的时间，并做好计划 估算本身也是一个项目 开发人员参与估算 不要忽略普通任务 使用几种不同的估算技术，并比较它们的结果 估算的群体讨论 过于乐观的进度计划 Microsoft Word for Windows 1.0开发 包含249，000行代码，投入660人月，前后历时5年，实际花费时间为预期时间的5倍 过于乐观的进度计划 导致WinWord1.0开发延迟的几个主要因素： 项目初期制定的开发目标是不可实现的。盖茨下达的指示是用最快的速度开发最好的字处理软件，争取在12月内完成。实现这两个目标中的任何一个都是困难的，同时达到则是不可能的。 过紧的进度计划降低了计划的精确度。 开发过程中频繁换人。5年中共换了4个组长，其中有2人因进度压力离职，1人是出于健康的原因而离职。 迫于进度压力，开发人员匆忙写出一些低质量的和不完整的代码，然后宣称已实现某些性能。这造成了WinWord不得不将用于提高软件稳定性的时间由预计的3个月增加到12个月。 由于该项目中，创新比速度更重要，因而试图缩短开发周期，反而使周期变长 产生过于乐观的进度计划的根源 为了赶在某些特定时间前展示或出售产品。如计算机交易展示会。 管理人员和客户拒绝接受仅给出范围的估算，而是按照他们认为的“最佳”估算来制定进度计划。 项目管理人员和开发人员为了享受挑战的乐趣或在压力下工作的刺激，而故意缩短进度计划。 管理部门和市场部门为了迎合客户而缩短进度计划。 项目管理人员认为较紧的进度计划能够使员工勤奋工作。 原先的估计是合理的，但是在项目进行过程中又加进了很多新特性，从而变成了过于乐观的进度。 …… 过于乐观的进度计划的后果 进度计划准确性 进度完成日期 按期完成概率 开发人员一般采用的较乐观的进度计划 典型的过分乐观的进度计划 过于乐观的进度计划的后果 计划的质量：错误的假设必将导致无效的项目规划。 抛弃计划：当面临进度压力时，大多数开发组织会抛弃原有规划，而走入盲目开发的歧途。 如果试图在关键阶段节省时间，必将在后续阶段加倍补偿。 分散了管理者的注意力：管理者将分散经历在不断调整计划上。 客户关系：项目一拖再拖，客户将失去耐心。 过于乐观的进度计划的后果 仓卒收尾 要排错只能将系统拆分后再进行，一个小的变动要花很长时间。 开发人员清楚地知道系统中存在一些应作修改却未做的地方。 测试人员发现错误的速度大于开发人员排错的速度。 排除已发现错误的同时，产生了大量新的错误。 由于软件变化频繁，难以保证用户文档的同步更新。 项目估算多次调整，软件交付日期一拖再拖。 超负荷的进度压力 产品质量的降低 赌博心理导致风险管理的忽略 激励效应不再起作用 创造性思维受损 精疲力竭：在后面的项目中难以提起热情 中途退出：这些人通常是有能力的人 长期地进行快速开发：难以补充新知识 开发人员与管理人员的关系：不切实际的进度压力会使开发人员丧失对管理人员的尊重。 估算不准的原因 缺乏经验的估算人员 过分乐观 考虑不周 方法不一致 签约前后不连贯 低劣的推测技术 对付估算误差 避免低劣估算 处理低劣估算带来的后果 避免低劣估算 尽可能使企业的估算机构专业化 避免估算缺陷 过分乐观 政治压力 低劣估算模型 处理低劣估算带来的后果 通过数据说明资源不足,争取更多资源 强化变更管理程序 确定目标的优先次序 * （1）根据图3-21计算项目在20天内完成的概率，其中任务1的最乐观、最悲观和最可能的历时估计是8天，24天， 10天, 任务2的最乐观、最悲观和最可能的历时估计是1天，9天，5天。 * 参考答案： * （2）项目经理正在进行一个媒体信息查询系统项目的估算，他采用的delphi的成本估算方法，邀请2位专家估算，第一个专家给出1万， 8万，9万的估算值，第二个专家给出了4万， 6万 ， 万8 万的估算，计算这个项目成本的估算值是多少 * E1=(O+4M+P)/6 =(1+4*8+9)/6 =7 E2=(O+4M+P)/6 =(4+4*6+8)/6 =6 E=(E1+E2)/2=(7+6)/2=6.5(万元) 基于承诺的估计（后墙不倒） 一些组织直接从需求出发安排进度而不进行中间的工作量估算。他们要求每个开发者作出进度承诺而非进度估算。 有利于开发者对进度的关注，开发者在接受承诺后士气高昂，自愿加班加点 问