接口描述

进入条件 项目立项。
输入   1. 客户需求
   2. 《风险检查表》
输出   1. 《风险管理计划》
2. 风险管理记录(WBMP)
退出条件  1.项目结项。_______________________________________________________________________  _

规程描述

角色和职责 参与本过程的有：
项目组成员 参与识别风险, 参与项目风险状态的评审,执行风险减缓计划.
项目经理（PM） 识别风险，对风险进行分类，并对识别的风险确定其可能性、重要性，定义该风险减缓措施触发的阈值；定期评审风险状态、识别新的风险；监督风险减缓计划的执行。.
相关任务 下列任务在本过程完成： 
（PM/项目组成员） RSKM100 – 识别风险 在此过程中确定风险的来源及类别. 项目经理（或组织项目骨干）使用检查表，或（通过WBMP/OA）查找同类型的项目的风险记录，尽可能地识别更多的风险项。
识别、评估有关技术、成本、资源和时间进度的风险，并记录在档。可以将风险进行以下定义：

• 技术风险——是指潜在地设计、实现、接口、验证和维护等方面的问题。此外规约的二义性、技术的不确定性、系统复杂度、陈旧的技术、以及“过于先进”的技术也是风险因素。技术风险威胁要开发的软件的质量及交付时间。如果技术风险变成现实，则开发工作可能变得很困难或者不可能。 技术风险包括：与用以建造产品的工具的可用性及质量相关的风险（即“开发环境风险”）；与待开发软件的复杂性以及系统所包含技术的“新奇性”相关的风险（即“新技术风险”）等。

• 商业风险——包括与管理或市场所加诸的约束相关的风险，以及与客户的素质以及开发者和客户定期通信的能力相关的风险（即“客户风险”）。商业风险常常会危害项目或产品。
 
• 管理风险——管理风险是指在项目管理中活动中，潜在的预算、进度、人力（工作人员和组织）、资源、客户、需求等方面的问题以及它们对软件项目的影响。其中，人员可用性、人员技能风险、参与工作的软件工程师的总体技术水平及项目经验相关的风险（即“人员风险”）也会对项目的成败造成极大的影响。
 
• 过程风险——与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。如果软件过程定义得不清楚；如果分析、设计、测试以无序的方式进行；如果质量是每个人都认为很重要的概念，但没有人切实采取行动来保证它，那么这个项目就处在风险之中。
 

（PM/项目组成员）  RSKM200 –分析风险 项目经理组织一组对技术和管理经验丰富的成员对风险进行“估价”。这个分析小组要给每个风险定义参数和参数值,这些参数值包括：风险发生的可能性、严重性、阈值（一般为可能性与严重性的乘积），并给他们排列优先次序。项目经理自己或者指派项目组其他成员来负责推荐优先次序。项目经理评价优先级列表，确认或修改该建议。一般来说应从已识别的风险中选择十大风险进行关注。
  风险可能性等级为：10％，20％，30％，40％，50％，60％，70％，80％，90％
 风险严重性值为：1，2，3，4，，5，6，7，8，9，10
（PM/项目组成员）  RSKM300 –制定风险减缓策略 
项目经理指派一个人或组来给高等级的风险制定风险减缓策略和风险应急策略，行程风险管理计划。项目经理要保证策划和减缓措施被执行。

风险处理研究

查找其他做过的项目的风险记录。如果对风险了解不足无法进行策划时要先进行研究,不要盲目行动.如果需要,可以从高管那里获得许可后聘请一个技术专家。风险处理研究可以包括：
• 阅读杂志上的文章
• 请教同行
• 召集会议进行讨论
• 在因特网上提出问题
• 原型构造

确定风险可接受性

可接受性就是指我们已充分理解风险，可以做出一个决定了。例如偶然和冲突发生的可能是可以忽略的。我们决定去接受这个风险因此它的出现也是结果之中的事。可接受性不是指忽略风险。

确定应对措施

在已充分理解风险，或者不能进行更深入的研究且不用忍受风险和它的结果时，制定相应措施管理风险。项目经理能够使用五种可能的措施进行风险管理：
• 避免
• 转移
• 降低
• 保护
• 保留

可能措施—— 避免:

避免也可以说是排除，指的是做一些不同的事情使风险不再出现。例如，为避免某些风险决定使用PowerBuilder 而不使用COBOL 。然而，这并不意味着没有风险了。可能会因为使用PowerBuilder而带来一串的风险。并且这些风险可能会更大。重要的是保持对系统的观察。例如，自行开发软件与购买商业组件对比。是否有哪些替代的措施来减轻风险?

可能措施——转移:

指的是转移风险给那些更专业或能够更好解决风险的人, 或是改变一个更合适的风险时间结构。转移不是指忽略风险，项目仍需与风险对抗.如果我们转移一个风险, 当风险发生时或许我们仍旧是 一个受影响的对象。 如:
• 转包合同或部分需求给其他专业公司 (让其他人来解决风险)
• 在开发周期内安排风险的维护 (转变成一个更合适的风险结构)
转包合同给一个专业公司也会带来其他相关的风险。要明确处理风险的最佳时期, 什么人可以更好地去处理它.

可能措施——降低:

• 降低风险，也可以看作是消除或者减轻风险，关注于风险的两个方面：概率和损失。 概率，可以看作预防，旨在减少一个风险出现的可能性（但不能减少到零）。损失，可以看作危害控制，旨在当风险发生是减少它带来的损失和影响。例如，以另外一种方式设计软件——使之有更多的模型，这样如果某一种方法不可行时，只会给软件的某一部分带来影响，并且比较容易用其他方式代替。例如，如果使用某个新的工具失败时，可以计划使用其他工具来降低这个风险。

可能措施——保护:

保护风险与避免（转移风险）、减小风险（减小风险可能性和影响）有些不同。保护风险的一种常见的形式是用一种并行的方式做同一件事。 如：
• 硬件的双重冗余—— 一个失败后另一个仍可以继续
• 软件——影子项目

可能措施——保留:

这是风险最普通的解决方式。保留不能解决风险但可以保留它的征兆（如成本和进度的滑动）。项目中最普通的保留方式是“附加投资”，延长时间进度，或者英雄主义。如果根本不知道风险也无法发现风险的情况下，保留是一种简单易行的方式。因为它不试图——
• 阻止风险的发生
• 如果风险出现，减小结果的影响
• 从风险中取得经验，提供一种途径避免它的发生。
保留是等待风险的发生并试图补偿它带来的危害。如果无止境的保留也不是解决途径，但是这样的情况通常不会发生。

（PM）  RSKM400 –监控风险状态 每月（定期）或事件驱动地检查风险的状态，以确定风险的可能性和重要性是否发生了变化，并发现新的风险或新的风险处理意见。在这个过程中，应把风险的可接受性和阈值进行比较，以确定是否需要实施风险缓解方案
（PM/项目组成员） RSKM500 –实施风险减缓策略 项目经理要追踪指派的任务并需求计划的实施，并记录执行结果。项目经理要每个月评审这些问题的状态。在顾客评审过程中可能会选择某些风险进行评审。

相关规程、指南