UML软件工程组织

风险管理过程
51CMM原创 作者:秋语 [2003/10/27]
摘要
本文详尽地描述了软件开发项目的风险管理过程,主要包括过程的具体活动,和采用的工具。 这里将软件风险管理过程分为五个步骤:风险识别,风险分析,风险计划,风险跟踪,和风险应对。对于每个步骤的具体活动将在后面详细介绍。
风险管理过程
软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。风险的最大特征是不确定性,也就是说它可能发生,也可能不发生。
风险管理在项目管理中有非常重要的地位:
· 有效的风险管理可以提高项目的成功率。在项目早期就应该进行必要的风险分析,并通过规避风险降低失败概率,避免返工造成成本上升。
· 提前对风险制定对策,就可以在风险发生时迅速作出反应,避免忙中出错造成更大损失。
· 风险管理可以增加团队的健壮性。与团队成员一起做风险分析可以让大家对困难有充分估计,对各种意外有心理准备,不至受挫后士气低落;而项目经理如果心中有数就可以在发生意外时从容应对,大大提高组员的信心从而稳定队伍。
· 有效的风险管理可以帮助项目经理抓住工作重点,将主要精力集中于重大风险,将工作方式从被动救火转变为主动防范。 风险管理可以简单分成五个步骤:风险识别、风险分析、风险计划、风险跟踪、和风险应对。如下图所示:

***识别风险和分析风险包含了评估风险所需的活动。计划风险、跟踪风险和应对风险包含了控制风险所需的实践。
一、风险识别
风险识别过程的活动是将不确定性转变为明确的风险陈述。包括下面几项,他们在执行时可能是重复,也可能是同时进行的:
1、 进行风险评估。在项目的初期,以及主要的转折点或重要的项目变更发生时进行。这些变更通常指成本、进度、范围或人员等方面的变更。
2、 系统地识别风险。采用下列三种简单的方法识别风险:风险检查表,定期会议(周例会上),日常输入(每天晨会上)。
3、 将已知风险编写为文档。通过编写风险陈述和详细说明相关的风险背景来记录已知风险,相应的风险背景包括风险问题的何事、何时、何地、如何及原因。
4、 交流已知风险。同时以口头和书面方式交流已知风险。在大家都参加的会议上交流已知风险,同时将识别出来的风险详细记录到文档中,以便他人查阅。
二、风险分析
风险分析过程的活动是将风险陈述转变为按优先顺序排列的风险列表。包括以下活动:
1、 确定风险的驱动因素。为了很好地消除软件风险,项目管理者需要标识影响软件风险因素的风险驱动因子,这些因素包括性能、成本、支持和进度。
2、 分析风险来源。风险来源是引起风险的根本原因。
3、 预测风险影响。如果风险发生,就将可能性和后果来评估风险影响。可能性被定义为大于0而小于100,分为5个等级(1、2、3、4、5)。将后果分为4个等级(低,中等,高,关键的)。采用风险可能性和后果对风险进行分组。具体组别如下表所示:

 

后果

关键的

11

7

4

2

1


15

12

8

5

3

中等

18

16

13

9

6


20

19

17

14

10

 

 

1

2

3

4

5

 

 

风险影响等级

4、 对风险按照风险影响进行优先排序,优先级别最高的风险,其风险严重程度等于1,优先级别最低的风险,其风险严重程度等于20。对级别高的风险优先处理。
三、风险计划
风险计划过程的活动是将按优先级排列的风险列表转变为风险应对计划。包括以下内容:
1、 制定风险应对策略。风险应对策略有接受、避免、保护、减少、研究、储备和转移几种方式。
2、 制定风险行动步骤。风险行动步骤详细说明了所选择的风险应对途径。它将详细描述处理风险的步骤。
四、风险跟踪
风险跟踪过程的活动包括监视风险状态以及发出通知启动风险应对行动。包括以下内容:
1、 比较阈值和状态。通过项目控制面板来获取。如果指标的值在可接受标准之外,则表明出现了不可接受的情况。
2、 对启动风险进行及时通告。对要启动的风险,在每天的晨会上通报给全组人员,并安排负责人进行处理。
3、 定期通报风险的情况。在定期的会议上通告相关人员目前的主要风险以及他们的状态。
五、风险应对
风险应对过程的活动是执行风险行动计划,以求将风险降至可接受程度。包括以下内容:
1、 对触发事件的通知作出反应。得到授权的个人必须对触发事件作出反应。适当的反应包括回顾当前现实以及更新行动时间框架,并分派风险行动计划。
2、 执行风险行动计划。应对风险应该按照书面的风险行动计划进行。
3、 对照计划,报告进展。确定和交流对照原计划所取得的进展。定期报告风险状态,加强小组内部交流。小组必须定期回顾风险状态。
4、 校正偏离计划的情况。有时结果不能令人满意,就必须换用其他途径。将校正的相关内容记录下来。
相关准则和规定
1 可能性评估准则
可能性评估准则

可能性

不确切的表达

估计

>80%

几乎一定,非常可能

5

61%~80%

可能,我们相信

4

41%~60%

我们怀疑,可能不会,大于50

3

21%~40%

不可能,可能不会

2

1%~20%

非常不可能,机会很小

1

2 后果评估标准
后果评估标准

准则

成本

进度

技术目标


低于1

比原计划落后1

对性能稍有影响

中等

低于5

比原计划落后2

对性能有一定的影响


低于10

比原计划落后1个月

对性能有严重影响

关键的

10%或更多

比原计划落后1个月以上

无法完成任务

3 时间框架评估准则
时间框架评估准则

时间框架

估计

1个月


2个月

适当

三个月


4 风险的驱动因素
风险因素是以如下的方式定义的:
1、 性能风险——产品能够满足需求且符合于其使用目的的不确定的程度。
2、 成本风险——项目预算能够被维持的不确定的程度。
3、 支持风险——软件易于纠错、适应及增强的不确定的程度。
4、 进度风险——项目进度能够被维持且产品能按时交付的不确定的程度。
过程工具
以下介绍的过程工具,只给出了工程描述。大家可根据自己公司的实际情况进行修改,并定制出适合自己的工具进行使用。
1 风险数据库
风险数据库是用来记录风险,跟踪风险处理过程,并能够对风险进行简单查询和统计的风险管理工具。
一般内容:
包括项目的一般信息(如名称),和在本项目中风险处理采用的一些标准和规定等。
1、 项目名称
2、 可能性评估准则(1,2,3,4,5)
3、 后果评估准则(低,中等,高,关键的)
4、 时间框架准则(短,中等,长)
5、 风险应对策略(风险应对策略用接受、避免、保护、减少、研究、储备和转移)
6、 风险的状态(Watch,Execute Contingency,Mitigate,Transfer,Avoid,Retired )
7、 风险驱动因素的类别(性能,成本,技术,进度)
风险记录的内容:
风险的内容是在风险处理的不同阶段不断添加进去的,如在风险计划阶段填写应对策略和行动步骤两列。
1、 编号
2、 识别日期
3、 识别者姓名
4、 风险类别(产品规模、商业影响、客户特性、过程定义、开发环境、技术难题、人员数目及经验)
5、 风险标题
6、 风险评估
a. 风险背景
b. 驱动因素(性能,成本,技术,进度)
c. 风险来源
d. 可能性(1、2、3、4、5)
e. 后果(低、中等、高、关键的)
f. 时间框架(短、中等、长)
g. 风险影响(1、2、3、4、5、6、7、8、9、10、11、12、13、14、15、16、17、18、19、20)
7、 风险计划
a. 应对策略(风险应对策略用接受、避免、保护、减少、研究、储备和转移)
b. 行动步骤
8、 风险跟踪
a. 风险的状态(Watch,Execute Contingency,Mitigate,Transfer,Avoid,Retired )
b. 批注
9、 风险应对
a. 负责人
b. 完成日期
c. 批注
辅助的管理功能:
1、 查看所有风险的状态(风险矩阵)
2、 对所有的当前风险进行优先排序
3、 已结束风险的备案
2 项目控制面板
项目控制面板可用作自动项目跟踪工具。将项目的各方面的数据(如需求变更数量,Bug数量等)录入对应的表格,即可自动得到当前关键指标的状态(是否处于正常的范围之内)。关键的项目指标包括:项目的进度,工作的效率,需求的变化,配置项的变化,人员的流动,不同阶段的缺陷数目,加班时间等。如果我们给每个指标一个可接受的阈值,当超过这个阈值时,系统便会自动给出警告。
控制面板的首页面是一系列的度量仪表,仪表上的指示将随着你输入的项目信息计算迩来。每个仪表分为两部分,白色的安全区和红色的警告区。如果指针处于红色区域,则说明有不可接受的情况发生。除此之外,当你单击每个仪表或图表时,会自动联接并切换到对应的更详细的分析图表中。
3 风险检查表
该检查表可以用来识别风险,并可以集中来识别下列常见子类型中已知的及可预测的风险:
1、 产品规模——与要建造或要修改的软件的总体规模相关的风险。
2、 商业影响——与管理或市场所加诸的约束相关的风险。
3、 客户特性——与客户的素质以及开发者和客户定期通信的能力相关的风险。
4、 过程定义——与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。
5、 开发环境——与用以建造产品的工具的可用性及质量相关的风险。
6、 技术难题——与待开发软件的复杂性以及系统所采用的新技术相关的风险。
7、 人员数目及经验——与参与工作的软件工程师的总体技术水平及项目经验相关的风险。
 

版权所有:UML软件工程组织