第6章 软件项目计划-7-2011精品.ppt

Case Study 死亡之旅 ——网吧连锁经营管理系统 Case Study 案例 Definition of Impossible Mission 如果利用无偏见、客观的风险评估（包括对技术、个人、合法性、政治等各方面因素的风险评估）方法发现评估结果中项目失败的概率大于50%，这就是一个死亡之旅类型的项目。 案例 Case Study Characteristics of Impossible Mission 进度比估算进度加快一半以上 员工缩减到正常一半以下 预算及相关资源被削减一半以上 要求给出两倍于正常情况的功能、特性、性能或其他技术要求。 案例 Case Study Case Introduction 十家连锁网吧运营商 中电华通要在8月初在武汉、北京两地进行网吧试点 2003年6月底决定做，客户要求8月初试点 没有需求 案例 Case Study Plan 1人分析流行的网吧软件，列出每个软件的所有功能，做出文档（3天） 讨论、修改、确认（1天） 设计系统整体结构、讨论（1天） 3个人设计数据库（3天），讨论、修改、确认（1天） 4个人进行模块详细设计并讨论确认（3天） 编码（加班、无休息日）（2-3周） 测试/调试（2-3周） 共计35个工作日，6月23日开始，8月8日完成。 案例 Case Study Result 设计未延期 编码延期4天 测试人员从未做过测试，但却要严格按照规范测试 项目经理是新手 部门经理不介入 8月8日，认为文档不全不规范，重新写需求文档，4天以后需求文档仍然不过关。最后，决定不论做成什么样8月15日关闭项目。 案例 Case Study 发生的原因 政治 - 售前经理对设计非常感兴趣，此外他是新任命的，急于建功立业 - 事业部总经理也是新任命的，他不能让整个事业部空转 幼稚的管理者根本未经历过软件项目，太乐观 海军特种兵心理 案例 Case Study 参加的原因 虽然风险高，但回报也高（管理者） 不做就得失业（程序员） 为了将来更好地发展值得一试（项目经理） 每个人都希望被别人需要（所有人） 不关心项目的成败，愿意接触一流的技术（Delphi—Java） 盲目的乐观（售前经理） 完成工作（所有人） 这是唯一的项目（项目组成员） 老板要这样 案例 Case Study 进度安排 Scheduling 进度计划 优先约束 人员水平 LPT算法 An Example——WinWord 1.0 项目初期制定的开发目标是不可实现的。比尔.盖茨给项目组下达的指示是用最快的速度开发迄今为止最好的字处理软件，争取在12个月内完成。 过紧的进度计划降低了计划的精确度。在开发的前4年里，预期进度估算误差率达到了60%-80%。 开发过程中频繁换人。5年中共换了4个组长，其中有2人因进度压力离职，1人是出于健康的原因离职。 迫于进度压力，开发人员匆匆写出一些低质量的和不完整的代码，然后宣称已实现某些性能。这造成WinWord不得不将用于提高软件稳定性的时间由预计的3个月增加到12个月。 Scheduling 进度计划 Root Causes of Overly Optimistic Schedules 为了赶在某些特定时间前战士或出售产品。 管理人员和客户拒绝接受仅给出范围的估算，而是按照他们所认为的“最佳”估算来指定进度计划。 项目管理人员和开发人员为了享受接受挑战的乐趣或在压力下工作的刺激，而故意缩短进度计划。 管理部门或市场部门为迎合客户而缩短进度计划。 开发人员为获取资金以开发自己感兴趣的项目，而违心地缩短计划。 项目管理人员认为较紧的进度计划能够促进开发人员努力工作。 高层管理部门、市场部门或某重要客户希望在特定时间内完成，而项目管理人员无法说服他们。 项目初期指定的计划是合理的，但在开发过程中，新的性能不断加入使得原来合理的计划相对于新的性能需求来说，变成了过分乐观的进度计划。 进度估算过程本身不够充分。 Scheduling 进度计划 Effects of Overly Optimistic Schedules 进度计划的精确性 计划的质量 坚持执行计划 功能范围的缩小 项目推进 客户关系 仓促收尾 Scheduling 进度计划 Effects of Excessive Schedule Pressure 产品质量 赌博心理 激励效应 创造性思维 精疲力竭