6.1风险分类与缓解方案-CMMI3级补充材料.ppt

风险分类与缓解方案 Soft Tech Development Inc. 风险类别 横向风险 组织管理 人员 客户 承包商等 纵向风险 立项 计划 需求 设计 编码 测试等 立项阶段 低效的立项申请段。 预防： 由产品工程部和研发部门根据市场需求和产品工期预测给出最迟立项时机； 由产品工程部监控和督促立项； 补救： 评估项目时效性，落实或放弃项目； 坚持切合实际的开发进度，避免共生风险； 共生风险： 计划阶段与进度相关的大部分风险； 计划阶段（包括再计划活动） 计划、资源和产品定义全凭口头指令。 预防： 制定相关执行程序和文档（如可行性分析等）； 坚持使用文档化的指令； 补救： 评估项目可行性，落实资源或放弃项目； 共生风险： 计划阶段的其他大部分风险，测试阶段的质量低下，人员中的人员薄弱等； 计划阶段 计划是理想状态的。 预防： 制定预留缓冲的计划； 考虑可能的需求变更和蔓延量； 使用迭代生命周期； 补救： 重新制定计划； 必要时缩小产品范围以满足进度； 计划阶段 计划漏掉了重要任务。 预防： 执行计划复审； 为可能的遗漏预留缓冲期； 使用迭代生命周期； 补救： 与用户协商添加必要的任务或推迟到下一版本； 删除其他次要功能以完成此重要任务； 计划阶段 产品规模估计不准。 预防： 使用科学的而非主观的估计方法； 使用迭代生命周期； 补救： 必要时删除次要功能以按时完成； 计划阶段 与以往项目经验比较，进度计划明显不切实际。 预防： 使用科学的而非主观的进度估计方法； 尊重历史数据和统计数据； 如果进度计划与项目经验不符，必须给出客观充分的理由； 使用接近阶段交付的生命周期； 将计划发送到别的项目组收集意见； 补救： 改正进度计划； 必要时删除次要功能以保证进度； 共生风险： 计划阶段的银弹综合症； 计划阶段 银弹综合症。 预防： 计划复审时识别银弹； 补救： 必要时删除次要功能以保证进度； 共生风险： 计划阶段与以往项目相比，项目进度明显不切实际。 银弹 各种银弹 新的开发方法 以前积累的库 自动编码和测试工具 新版开发软件 自动配置管理工具 所有需要时间和实践掌握的方法或工具 只影响局部的单一因素，都可能成为银弹。 计划阶段 目标提前但产品范围和可用资源不变。 预防： 变更控制程序中应平衡进度、费用和功能三角； 补救： 增加可用资源； 放弃提前的目标； 必要时删除次要功能以按时完成； 共生风险： 人员中的“项目后期增加新人”； 需求分析阶段（包括需求变更） 需求模糊。 预防： 使用需求原型； 邀请用户参与联合开发或复审需求； 需求复审； 使用操作概念和场景对需求进行细化； 补救： 邀请用户参与联合开发或复审需求； 复审修正后的需求； 需求分析阶段 基线已定但需求仍在变化。 预防： 变更控制，保持基线稳定性； 由变更委员会复审需求变更； 由用户参与复审基线； 采用利于客户评审的需求表达方式； 补救： 将新需求推入下一版本； 必要时删除次要功能以满足新需求； 需求分析阶段 需求镀金。 试图击败竞争对手时常犯的错误。 预防： 邀请用户参与需求复审； 向用户咨询业务开展的日程表； 采用迭代生命周期，把镀金工作放在最后阶段； 不对镀金工作向用户做承诺； 补救： 先实现用户所需，其余推入日后版本实现； 需求分析阶段 研发导向的开发。 预防： 需求复审； 限时开发； 先实现功能，后实现性能； 建立专门的研发部门进行技术研发； 补救： 尽快稳定功能，将研发目标转入下一版本或另一部门； 共生风险： 产品阶段的使用过多新技术。 设计阶段 设计过于简单，无法确切实现。 预防： 设计复审； 由下一阶段人员参加设计复审； 参考PSP中关于缺陷引入阶段分析的理论； 在编码期中预留必要的详细设计时间； 补救： 先实现比较详细的部分，细化其他部分； 设计阶段 设计过于复杂，花费了太多时间。 预防： 制定设计计划，包括设计的范围和进度； 参考以往设计的细度和效果； 参考PSP中关于缺陷引入阶段分析的理论； 设计阶段 设计低劣。 预防： 设计培训； 设计复审； 分工前掌握人员设计能力； 设置检查点和小型里程碑； 补救： 对设计进行评估，对关键模块和低劣模块进行重新设计； 必要时删除部分次要功能以保证进度； 设计阶段 开发人员镀金。 预防： 制定详细设计计划（范围和进度）； 详细设计复审； 使用契约明确任务； 设置检查点进行检查； 冷静对待新的设计思路； 补救： 尽快实现当前用户需求； 将镀金内容推入下一版本； 设计阶段 使用不熟悉的设计方法。 预防： 预留学习熟悉缓冲时间； 补救： 由熟悉此设计方法的人指导； 必要时删除部分次要功能以保证进度； 编码阶段 使用不熟悉的语言。 预防： 尽量使用熟悉的语言； 必要时可通过招聘找到熟悉的人员； 预留学习熟悉缓冲时间；