风险管理指南最新版

卷号卷内编号密级

分类:

<指南>

使用者:

<项目组、项目管理部、技术委员会>

文档编号：

©托普信息（iTOP）集团,2002风险管理指南

Version 1.1

技术委员会

文档信息

标题:风险管理指南

作者:技术委员会

创建日期: 2002-4-23

上次更新日期:

版本:1.1

部门名称: 托普信息（iTOP）集团

修订文档历史记录

日期版本说明作者2002-4-23 1.0 创建孟胜

2002-8-29 1.1为了iTOP集团推广CMM成果，对封面及部分

内容作了调整托普信息（iTOP）集团技术委员会

目录

1.简介 (1)

1.1目的 (1)

1.2定义、首字母缩写词和缩略语 (1)

1.3参考资料 (1)

2.风险管理准备 (1)

2.1风险管理的组成 (1)

2.2风险种类 (2)

2.2.1资源风险 (2)

2.2.2业务风险 (2)

2.2.3技术风险 (2)

2.2.4进度风险 (3)

2.3定义风险参数 (3)

2.4风险管理策略 (4)

2.5风险管理角色及职责 (4)

2.5.1项目经理 (4)

2.5.2项目组开发人员 (4)

2.5.3SQA (4)

3.风险识别 (4)

4.风险分析 (4)

4.1发生的可能性 (5)

4.2影响的严重性 (5)

5.风险的优先级 (5)

6.风险的控制 (5)

6.1控制方法 (5)

6.1.1风险管理计划 (5)

6.1.2风险的化解 (6)

6.2风险监控 (6)

6.2.1周例会检查风险 (6)

6.2.2阶段/迭代完成后重新评估风险 (6)

风险管理指南

1. 简介

1.1 目的

风险管理的目标是在潜在问题发作以前就标志它们，这样就可以在生命周期中可以适时地计划和启用风险处理活动。

1.2 定义、首字母缩写词和缩略语

PM Project Manager

1.3 参考资料

RUP

《快速软件开发》

SW-CMM

CMMI

2. 风险管理准备

2.1 风险管理的组成

2.2 风险种类

2.2.1 资源风险

组织

•对该项目是否有足够的支持（包括管理人员、测试员、QA 和其他外部的相关各方）？

•这是否是该组织尝试过的最大项目？

•软件工程是否有明确定义的流程？需求记录和管理？

资金

•完成项目所需的资金是否到位？

•是否为培训和指导分配了资金？

•是否有预算限制使得系统必须以固定的成本交付，否则将被取消？

•成本估算是否准确？

人员

•是否可以获得足够的人员？

•他们是否具备合适的技能和经验？

•他们以前是否在一起工作过？

•他们是否相信项目会成功？

•是否可以找到用户代表来担任复审员？

•是否可以找到领域专家？

时间

•时间表制定得是否现实？

•是否可以为了满足时间表而对功能进行规模管理？

•对交付日期的要求有多严格？

•是否有时间“把工作做好”？

2.2.2 业务风险

•如果竞争对手抢先将产品推向市场怎么办？

•如果项目资金处于危险境地怎么办（换句话说，“如何确保有足够的资金”）？

•系统的预计价值是否大于预计成本？（务必要考虑货币的时间价值和资金的成本）。

•如果无法同关键的供应商签定合同怎么办？

2.2.3 技术风险

规模风险

•成功是否能够被评测？

•是否有关于如何评测成功的协议？

•需求是否相当稳定并得到了充分的了解？

•项目规模是固定不变还是在不断扩展？

•项目开发的时间范围是否太短、不够灵活？

技术风险

•技术是否已经过证明？

•重复使用目标是否合理？

•工件必须要使用一次后才能被重复使用。

•构件可能要在若干次发布后才能变得稳定，以致无需重大变更即可复用。

•需求中的事务量是否合理？

•事务比率的估计值是否可靠？这些估计是否过于乐观？

•数据量是否合理？当前可用的框架是否能够保存这些数据，或者，如果需求使您相信工作站或部门系统将成为设计的一部分，那么是否能够在这些地方合理地保存数据？

•是否有特殊或苛刻的技术需求（如要求项目团队处理他们不熟悉的问题）？

•成功是否依赖于新的或未经试验的产品、服务或技术？是否依赖于新的或未被证明的硬件、软件或技术？

•对于与其他系统（包括企业以外的系统）的接口是否存在外部依赖性？是否存在必需的接口或必须创建它们？

•是否存在极不灵活的可用性和安全性需求（例如“系统必须永远不出现故障”）？

•系统的用户是否对正在开发的系统类型没有经验？

•应用程序的大小或复杂性，或者技术的新颖性是否导致了风险的增加？

•是否存在对国家语言支持的需求？

•是否可能设计、实施和运行该系统？某些系统只由于太大或太复杂而无法正常工作。

外部依赖性风险

•该项目是否依赖于其他（平行的）开发项目？

•成功是否依赖于市售产品或外部开发的构件？

•成功是否依赖于开发工具（设计工具、编译器等）和实施技术（操作系统、数据库、进程间通信机制等）的成功集成。您是否有替代计划，可以在没有这些技术的情况下

交付项目？

2.2.4 进度风险

•功能是否无限追加

•计划是否过于乐观；

•是否缺乏计划

•在压力下是否放弃计划

•是否追赶计划

2.3 定义风险参数

风险参数可用于评估、分类和划分风险的优先级；

TP集团将风险参数分为：“发生的可能性”和“影响的严重性”两类