第5章节 软件项目风险管理.pptVIP

示例 积极 消极 内部 外部 6.匿名风险报告机制 向管理层或组内报告好的消息很少会出现问题，但报告项目的坏消息则不然。 必须有一个匿名的风险交流渠道。 5.3 风险分析 5.3 风险分析 风险分析是人们应用风险分析工具,加深对风险的认识与理解，使风险及风险背景明晰化，从而为有效地管理风险提供基础。 风险分析活动的过程目标包括：提炼风险背景，确定风险来源，确定行动时间框架，确定前10项首要风险名单等。 政府 客户 供货商 分包商 潜在的客户 最终用户 项目经理 团队 发起人 竞争者 组织 集中管理 同事 其他的项目 自然环境 人员 时间 资金 技术 其他要素 项目风险来源 计划编制风险 计划、资源和产品的定义完全由客户或上层领导决定，忽略了项目组的意见，并且这些决定不完全一致 计划忽略了必要的任务和活动 计划不切实际 计划基于特定小组成员，而这样的小组成员根本得不到 产品规模估算过于乐观 工作量估算过于乐观 进度的压力造成生产率的下降 目标日期提前，但没有相应地调整产品范围和可用资源 一个关键任务的延迟导致其他相关任务的连锁反应 …… 组织和管理风险 缺乏强有力、有凝聚力的领导(项目组、企业) 解雇员工导致项目小组能力下降 削减预算打乱项目计划 仅由管理层和市场人员进行技术决策，导致进度延长 低效的项目组组织结构降低生产率 管理层审查/决策的周期比预期时间长 管理层作出了打击项目组积极性的决定 非技术的第三方的工作比预期要长(如, 采购硬件设备) 计划性太差，无法适应期望的开发速度 项目计划由于压力而放弃，导致开发混乱 管理方面的英雄主义，忽视客观确切的状态报告，降低发现和改正问题的能力 开发环境风险 设施不能及时到位 设施到位，但不配套 开发工具未能及时到位 开发工具不如期望的那样有效，开发人员需要更多的时间，或者更换工具 开发工具的学习期比预期的要长 开发工具的选择不是基于技术需求，不能提供计划要求的功能 最终用户风险 最终用户坚持新的需求 最终用户对最后交付的产品不满意，要求重新设计和重做 最终用户不买进项目产品，无法提供后续支持 最终用户的意见未被采纳，造成产品最终无法满足用户要求 组织和管理风险 缺乏强有力、有凝聚力的领导(项目组、企业) 解雇员工导致项目小组能力下降 削减预算打乱项目计划 仅由管理层和市场人员进行技术决策，导致进度延长 低效的项目组组织结构降低生产率 管理层审查/决策的周期比预期时间长 管理层作出了打击项目组积极性的决定 非技术的第三方的工作比预期要长(如, 采购硬件设备) 计划性太差，无法适应期望的开发速度 项目计划由于压力而放弃，导致开发混乱 管理方面的英雄主义，忽视客观确切的状态报告，降低发现和改正问题的能力 开发环境风险 设施不能及时到位 设施到位，但不配套 开发工具未能及时到位 开发工具不如期望的那样有效，开发人员需要更多的时间，或者更换工具 开发工具的学习期比预期的要长 开发工具的选择不是基于技术需求，不能提供计划要求的功能 最终用户风险 最终用户坚持新的需求 最终用户对最后交付的产品不满意，要求重新设计和重做 最终用户不买进项目产品，无法提供后续支持 最终用户的意见未被采纳，造成产品最终无法满足用户要求 客户风险(1/2) 客户坚持新的需求 客户对规划、原型和规格的审核/决策超出预期 客户没有参与规划、原型和规格的审核，导致需求不稳定，以及长时间的变更 客户答复的时间比预期的要长 客户坚持技术决策而导致计划延长 客户对开发进度管理过细，导致实际进度变慢 客户提供的组件无法与开发的产品匹配，导致需要额外的设计和集成工作 客户提供的组件质量欠佳，导致额外的测试、设计或者功能不完善 客户风险(2/2) 客户要求的支持工具与环境不兼容，性能差或者不完善，导致生产率降低 客户不接受交付的软件，尽管它满足了所有的规格 客户期望的开发速度是开发人员所无法达到的 承包商风险 承包商没有按照承诺交付产品 承包商提供的产品质量低下，必须花时间改进质量 承包商提供的产品性能达不到要求 需求风险 需求已经成为项目基准，但仍在变化 需求定义欠佳：不清晰、不准确、不一致 增加额外的需求 产品风险 错误发生率高的模块，需要更多的时间对它进行测试、设计和实现 矫正质量低下的不可接受的产品需要更多的时间对它进行测试、设计和实现 由于功能错误，导致需要重新进行设计和实现 开发额外不需要的功能延长了进度 要满足产品规模和速度要求，需要更多的时间 严格要求与现有系统兼容，需要更多的时间 要求软件重用，需要更多的时间 …… 外部环境风险 产品依赖政府规章，而规章的改变不可预期 产品依赖草拟中的技术标准，而最后的标准不可预期 人员风险(1/3) 招聘人员所需的时间比预期要长 作为人员参与工作的先决条件(如培训、其他项目的完成