软件工程
电子教案
王树林
第 6章 风险管理
风险概念定义：
（ 1）风险关注未来将要发生的事情；
（ 2）风险涉及改变；
（ 3）风险涉及选择本身所包含的不确定
性。
当没有办法消除风险，甚至连试图降低该
风险也存在疑问时，这些风险就是真正
的风险了。
第 6章 风险管理
6.1 被动的和主动的风险策略
被动风险策略被称为“印地安娜,琼斯学派的
风险管理”。“不要担心，我总是有办法
的”。
? 被动策略就是针对可能发生的风险来监督
项目，直到他们变成真正的问题时，才拨出
资源来处理他们。这被称为“救火模式”。
当这样的努力无效时，项目就处于“危机”
中了。
? 主动策略：在技术工作开始前。标识出潜在
的风险，评估他们出现的概率及影响，划分
出重要性并排序，然后建立一个计划对风险
第 6章 风险管理
进行管理。主要目标是预防风险，但不是所有
的风险都可以预防，那么就有必要建立一个
意外事件处理计划。下面的讨论主要是针对
主动策略。
6.2 软件风险
风险中包含两个特性, （ 1） 不确定性，刻画
风险的事件可能发生也可能不发生；
（ 2） 损失 —如果风险变成了现实，就会产生恶
性后果或损失。
第 6章 风险管理
进行风险分析时，重要的是量化不确定性的程
度以及与每个风险活动相关的程度。
项目风险威胁到项目计划。如果风险变成现实，
就会影响到项目的进度，增加成本。项目的
风险是指潜在的预算、进度、人力、资源、
客户、需求、项目复杂性、规模、结构不确
定性等因素。
技术风险影响到开发的软件质量及交付时间。
技术风险是指潜在的设计、实现、接口、验
证、和维护等方面的问题。规约的二义性、
技术的不确定性、陈旧的技术、及先进的技
术。
第 6章 风险管理
技术风险的发生是因为问题比我们所设想的更
加难以解决。
商业风险威胁到要开发软件的生存能力。五个
主要的商业风险是（ 1）开发了一个没有人真
正需要的优秀产品或系统；（ 2）开发的产品
不再符合公司的整体商业策略（策略风险）；
（ 3）建造了一个销售部门不知道如何去买的
产品；（ 4）由于重点的转移或人员的变动而
失去了高级主管的支持（管理风险）；（ 5）
没有得到预算或人力上的保证（预算风险）。
第 6章 风险管理
6.3 识别风险
通过已知的和预测的风险，在可能时，
项目管理者就可以避免风险，且当必要时控
制这些风险。
每一类风险都可分为两个不同的风险：一般风
险和特定产品风险。一般风险对每一个软件
而言都是一个潜在的威胁。特定产品风险只
有那些对当前项目的技术、人员、及环境非
常了解的人才能识别出来。
如果你不主动攻击风险，风险就会主动攻击你。
识别风险的一个方法是建立风险条目检查表。
第 6章 风险管理
? 产品规模 —与要建造的软件总体规模相关的
风险。
? 商业影响 —与管理市场所加诸的约束相关的
风险。
? 客户特性 —与客户的素质以及开发者和客户
定期通信的能力相关的风险。
? 过程定义 —与软件过程被定义的程度以及他
们被开发者所遵守的程度相关的风险。
? 开发环境 —与用于建造产品的工具的可用性
及质量相关的风险。
? 建造的技术 —与待开发软件的复杂性及系统
第 6章 风险管理
所包含技术的“新奇性”相关的风险。
人员数目及经验 —与参与工作的软件工程
师的总体技术水平及项目经验相关的风
险。
6.3.1 产品规模风险
项目风险是直接与产品规模成正比的。
? 是否以 LOC和 FP来估算风险？
? 对于估算出来的产品信任程度如何？
第 6章 风险管理
? 产品的规模与以前产品的规模平均值的
偏差百分比是多少？
? 产品的用户数有多少？
? 产品的需求改变多少？交付之前有多少？
交付之后有多少？
? 复用的软件有多少？
第 6章 风险管理
6.3.2 商业影响风险
商业考虑有时会与技术现实发生冲突。
? 本产品对公司的收入有何影响？
? 本产品是否得到公司高级管理层的重视？
? 交付期限的合理性如何？
? 延迟交付所造成的成本消耗是多少？
? 产品缺陷所造成的成本风险是多少？
第 6章 风险管理
6.3.3 客户相关的风险
客户有不同的需要。
客户有不同的个性。
一个不好的客户可能会对一个软件项目组
能否在预算内按时完成项目产生很大的影响。
? 你以前是否与这个客户合作过？
? 该客户是否很清楚需要什么？他能否花时间
把需求写出来？
第 6章 风险管理
? 该客户是否具有该产品领域的技术素养？
? 该客户是否愿意让你的人来做他们的工
作。
? 该客户是否了解软件过程？
6.3.4 过程风险
如果质量是每个人都认为很重要的
概念，但没有人切实地采取行动来保证
它，那么这个项目就处于风险之中。
第 6章 风险管理
过程问题
? 你的高级管理层是否支持一份已经写好的政
策综述？
? 你的组织是否已经建立了一份已经成文的、
用于本项目的软件过程说明？
? 开发人员是否“签约”同意按照文档所写的
软件过程进行开发工作？
? 是否定期地对需求规约、设计和编码进行正
式的技术复审？
等等
第 6章 风险管理
技术问题
? 是否使用特定的技术方法进行软件分析？
? 是否使用工具来创建软件原型？
? 是否使用工具来支持计划和跟踪活动？
等等
6.3.5 技术风险
下面的风险检查表中的条目标识了与建造的技
术相关的风险？
? 该技术对于你的组织而言是新的吗？
第 6章 风险管理
? 客户的需求是否需要创建新的算法或输入、
输出技术？
? 软件是否需要使用新的、未经证实的硬件接
口？
? 产品的需求中是否要求采用特定的用户界面？
? 需求中是否要求使用分析、设计、或测试方
法？
? 需求中是否要求使用非传统的软件开发方法
如形式化方法、基于 AI的方法以及人工神经
网络？
第 6章 风险管理
需求中是否有过份的对产品的性能的约束？
等等
6.3.6 开发环境风险
所用的工具有问题，那么所开发出的产品
很难说不存在问题。如开发环境有缺陷，那
么他就是风险源。
? 是否有可用的软件项目管理工具？
? 是否有可用的分析及设计工具？
? 是否有可用的过程管理工具？
第 6章 风险管理
? 是否所有工具都是彼此集成的？
6.3.7 与人员数及经验相关的风险
? 是否有最优秀的人员可用？
? 人员在技术上是否配套？
? 开发人员是否能够自始自终地参加整个
项目的工作？
? 项目中是否有一些人员只能部分时间工
作？
第 6章 风险管理
? 开发人员对自己的工作是否有正确的期望？
? 开发人员是否接受过必要的培训？
? 开发人员的流动是否仍能保证工作的连续性？
6.3.8 风险因素和驱动因子
风险因素定义：
性能风险 —产品能够满足需求且符合于其使用
目的的不确定程度。
成本风险 —项目预算能够被维持的不确定的程
度。
支持风险 —软件易于纠错、适应及增强的不确
定程度。
第 6章 风险管理
? 进度风险 —项目进度能够被维持且产品能够
按时交付的不确定程度。
每一个风险驱动因子对风险因素的影响均可分
为四个类别 ----可忽略的、轻微的、严重的及
灾难的。
6.4 风险预测
风险预测就是风险估算，通常我们从两个方面
评估每一个风险。（ 1）风险发生的概率；
（ 2）如果发生风险，所产生的后果。
第 6章 风险管理
? 风险预测活动,
（ 1）建立一个尺度，反映风险发生的可
能性；
（ 2）描述风险的后果；
（ 3）估算风险对项目及产品的影响；
（ 4）标注风险预测的整体精确度，以免
产生误解。
第 6章 风险管理
6.4.1 建立风险表
风险表给项目管理者提供了一种简单的风险预测技术。
列出所有的风险，然后对风险分类，并给出概率，
6.4.2 评估风险影响
如果风险真的发生了，那么风险的性质、范围和时间
都会受到影响。管理者希望风险出现的越早越好。
6.4.3 风险评估
在风险管理中的这一步，我们建立了如下形式的一系列
三元组。
[ri,li,xi ] 其中 ri表示风险,li表示风险发生的
概率，表示风险产生的影响。
开始考虑如何避免风险的发生 。
第 6章 风险管理
进度
延迟
临界点（成本、时间）
终止项目
成本超支
风险参考水平线
第 6章 风险管理
6.5 风险缓解、监控和管理
风险分析活动的目的就是辅助项目组建立处理
风险的策略。通常从三个方面考虑问题, （ 1）
风险避免；（ 2）风险监控；（ 3）风险管理
及意外事件计划。
软件项目组应采取主动的方法，分析风险所造
成的影响，尽可能避免风险的发生。这可以
通过风险缓解计划来达到。例如：假设频繁
的人员流动被标注为一个项目风险，他对项
目成本及进度有严重影响。为了缓解这个风
险，项目管理必须建立一个策略来降低人员
流动。
第 6章 风险管理
? 与现有人员一起探讨一下人员流动的原因。
? 一旦项目启动，假设会发生人员流动并采取
一些技术以保证当人员离开时工作的连续性。
? 对所有工作进行详细复审，使得不止一个人
熟悉该项工作。
? 对于每一个关键的技术人员都指定一个后备
人员。
? 与报酬和利益相关的潜在问题。
? 在公司内和公司外工作的可能性。
第 6章 风险管理
项目管理者应监控风险缓解步骤的效力。
项目管理者应该仔细地监控这些文档，
以保证这些文档内容正确。
RMMM计划步骤将导致额外的项目开销。
一个大项目可能标出 30-40个风险，如果
对每一个风险都建立一个风险管理计划，
那么，工作量将增加很多。所以可按 80-
20原则来对风险进行管理。
第 6章 风险管理
6.6 安全风险和危险
风险并不仅限于软件项目本身。在软件
交付给用户之后仍有可能发生风险。
软件安全和危险分析是属于软件质量保证
活动。如果能够在早期阶段标识出风险，
则可以在软件开发过程中消除或控制潜
在的风险。
第 6章 风险管理
6.7 RMMM计划
风险管理策略可以包含在软件项目计划中，
或者风险管理步骤也可以组织成一个独立的
风险缓解、监控和管理计划（ RMMM计划）。
RMMM计划大纲如下：
1.引言
1.1 文档的范围和目的
1.2主要风险综述
1.3 责任
1,3,1 管理者
1,3,2 技术人员
第 6章 风险管理
2,项目风险表
2,1 终止线之上的所有风险描述
2,2 影响的概率及影响的因素
3, 风险缓解、监控和管理
3, n, 风险 # n
3, n,1 缓解
a,一般策略
b,缓解风险的特定步骤
第 6章 风险管理
3, n,2 监控
a,被监控的因素
b.监控方法
3, n,3 管理
a,意外事件计划
b,特殊的考虑
4.RMMM计划的迭代时间安排表
5.总结
6.8 SUMMARY
Whenever a lot is riding on a software project,
common sense dictates risk analysis,And
yet,most software project managers do it at all,
The time spent identifying,analyzing,and
managing risk pays itself in many ways:less
upheaval during project ;a greater ability to track
and control a project ;and the confidence that
comes with planning for problems before they
occur.
Risk analysis can absorb a significant amount of
project planning effort, Identification,
6.8 SUMMARY
projection,assessment,management,and
monitoring all take time,But the effort is
worth it,To quote sun Tzu,a Chinese
general who lived 2500 years ago,“If you
know the enemy and know yourself,you
need not the result of a hundred battles.”
For the software project manager,the
enemy is risk,
电子教案
王树林
第 6章 风险管理
风险概念定义：
（ 1）风险关注未来将要发生的事情；
（ 2）风险涉及改变；
（ 3）风险涉及选择本身所包含的不确定
性。
当没有办法消除风险，甚至连试图降低该
风险也存在疑问时，这些风险就是真正
的风险了。
第 6章 风险管理
6.1 被动的和主动的风险策略
被动风险策略被称为“印地安娜,琼斯学派的
风险管理”。“不要担心，我总是有办法
的”。
? 被动策略就是针对可能发生的风险来监督
项目，直到他们变成真正的问题时，才拨出
资源来处理他们。这被称为“救火模式”。
当这样的努力无效时，项目就处于“危机”
中了。
? 主动策略：在技术工作开始前。标识出潜在
的风险，评估他们出现的概率及影响，划分
出重要性并排序，然后建立一个计划对风险
第 6章 风险管理
进行管理。主要目标是预防风险，但不是所有
的风险都可以预防，那么就有必要建立一个
意外事件处理计划。下面的讨论主要是针对
主动策略。
6.2 软件风险
风险中包含两个特性, （ 1） 不确定性，刻画
风险的事件可能发生也可能不发生；
（ 2） 损失 —如果风险变成了现实，就会产生恶
性后果或损失。
第 6章 风险管理
进行风险分析时，重要的是量化不确定性的程
度以及与每个风险活动相关的程度。
项目风险威胁到项目计划。如果风险变成现实，
就会影响到项目的进度，增加成本。项目的
风险是指潜在的预算、进度、人力、资源、
客户、需求、项目复杂性、规模、结构不确
定性等因素。
技术风险影响到开发的软件质量及交付时间。
技术风险是指潜在的设计、实现、接口、验
证、和维护等方面的问题。规约的二义性、
技术的不确定性、陈旧的技术、及先进的技
术。
第 6章 风险管理
技术风险的发生是因为问题比我们所设想的更
加难以解决。
商业风险威胁到要开发软件的生存能力。五个
主要的商业风险是（ 1）开发了一个没有人真
正需要的优秀产品或系统；（ 2）开发的产品
不再符合公司的整体商业策略（策略风险）；
（ 3）建造了一个销售部门不知道如何去买的
产品；（ 4）由于重点的转移或人员的变动而
失去了高级主管的支持（管理风险）；（ 5）
没有得到预算或人力上的保证（预算风险）。
第 6章 风险管理
6.3 识别风险
通过已知的和预测的风险，在可能时，
项目管理者就可以避免风险，且当必要时控
制这些风险。
每一类风险都可分为两个不同的风险：一般风
险和特定产品风险。一般风险对每一个软件
而言都是一个潜在的威胁。特定产品风险只
有那些对当前项目的技术、人员、及环境非
常了解的人才能识别出来。
如果你不主动攻击风险，风险就会主动攻击你。
识别风险的一个方法是建立风险条目检查表。
第 6章 风险管理
? 产品规模 —与要建造的软件总体规模相关的
风险。
? 商业影响 —与管理市场所加诸的约束相关的
风险。
? 客户特性 —与客户的素质以及开发者和客户
定期通信的能力相关的风险。
? 过程定义 —与软件过程被定义的程度以及他
们被开发者所遵守的程度相关的风险。
? 开发环境 —与用于建造产品的工具的可用性
及质量相关的风险。
? 建造的技术 —与待开发软件的复杂性及系统
第 6章 风险管理
所包含技术的“新奇性”相关的风险。
人员数目及经验 —与参与工作的软件工程
师的总体技术水平及项目经验相关的风
险。
6.3.1 产品规模风险
项目风险是直接与产品规模成正比的。
? 是否以 LOC和 FP来估算风险？
? 对于估算出来的产品信任程度如何？
第 6章 风险管理
? 产品的规模与以前产品的规模平均值的
偏差百分比是多少？
? 产品的用户数有多少？
? 产品的需求改变多少？交付之前有多少？
交付之后有多少？
? 复用的软件有多少？
第 6章 风险管理
6.3.2 商业影响风险
商业考虑有时会与技术现实发生冲突。
? 本产品对公司的收入有何影响？
? 本产品是否得到公司高级管理层的重视？
? 交付期限的合理性如何？
? 延迟交付所造成的成本消耗是多少？
? 产品缺陷所造成的成本风险是多少？
第 6章 风险管理
6.3.3 客户相关的风险
客户有不同的需要。
客户有不同的个性。
一个不好的客户可能会对一个软件项目组
能否在预算内按时完成项目产生很大的影响。
? 你以前是否与这个客户合作过？
? 该客户是否很清楚需要什么？他能否花时间
把需求写出来？
第 6章 风险管理
? 该客户是否具有该产品领域的技术素养？
? 该客户是否愿意让你的人来做他们的工
作。
? 该客户是否了解软件过程？
6.3.4 过程风险
如果质量是每个人都认为很重要的
概念，但没有人切实地采取行动来保证
它，那么这个项目就处于风险之中。
第 6章 风险管理
过程问题
? 你的高级管理层是否支持一份已经写好的政
策综述？
? 你的组织是否已经建立了一份已经成文的、
用于本项目的软件过程说明？
? 开发人员是否“签约”同意按照文档所写的
软件过程进行开发工作？
? 是否定期地对需求规约、设计和编码进行正
式的技术复审？
等等
第 6章 风险管理
技术问题
? 是否使用特定的技术方法进行软件分析？
? 是否使用工具来创建软件原型？
? 是否使用工具来支持计划和跟踪活动？
等等
6.3.5 技术风险
下面的风险检查表中的条目标识了与建造的技
术相关的风险？
? 该技术对于你的组织而言是新的吗？
第 6章 风险管理
? 客户的需求是否需要创建新的算法或输入、
输出技术？
? 软件是否需要使用新的、未经证实的硬件接
口？
? 产品的需求中是否要求采用特定的用户界面？
? 需求中是否要求使用分析、设计、或测试方
法？
? 需求中是否要求使用非传统的软件开发方法
如形式化方法、基于 AI的方法以及人工神经
网络？
第 6章 风险管理
需求中是否有过份的对产品的性能的约束？
等等
6.3.6 开发环境风险
所用的工具有问题，那么所开发出的产品
很难说不存在问题。如开发环境有缺陷，那
么他就是风险源。
? 是否有可用的软件项目管理工具？
? 是否有可用的分析及设计工具？
? 是否有可用的过程管理工具？
第 6章 风险管理
? 是否所有工具都是彼此集成的？
6.3.7 与人员数及经验相关的风险
? 是否有最优秀的人员可用？
? 人员在技术上是否配套？
? 开发人员是否能够自始自终地参加整个
项目的工作？
? 项目中是否有一些人员只能部分时间工
作？
第 6章 风险管理
? 开发人员对自己的工作是否有正确的期望？
? 开发人员是否接受过必要的培训？
? 开发人员的流动是否仍能保证工作的连续性？
6.3.8 风险因素和驱动因子
风险因素定义：
性能风险 —产品能够满足需求且符合于其使用
目的的不确定程度。
成本风险 —项目预算能够被维持的不确定的程
度。
支持风险 —软件易于纠错、适应及增强的不确
定程度。
第 6章 风险管理
? 进度风险 —项目进度能够被维持且产品能够
按时交付的不确定程度。
每一个风险驱动因子对风险因素的影响均可分
为四个类别 ----可忽略的、轻微的、严重的及
灾难的。
6.4 风险预测
风险预测就是风险估算，通常我们从两个方面
评估每一个风险。（ 1）风险发生的概率；
（ 2）如果发生风险，所产生的后果。
第 6章 风险管理
? 风险预测活动,
（ 1）建立一个尺度，反映风险发生的可
能性；
（ 2）描述风险的后果；
（ 3）估算风险对项目及产品的影响；
（ 4）标注风险预测的整体精确度，以免
产生误解。
第 6章 风险管理
6.4.1 建立风险表
风险表给项目管理者提供了一种简单的风险预测技术。
列出所有的风险，然后对风险分类，并给出概率，
6.4.2 评估风险影响
如果风险真的发生了，那么风险的性质、范围和时间
都会受到影响。管理者希望风险出现的越早越好。
6.4.3 风险评估
在风险管理中的这一步，我们建立了如下形式的一系列
三元组。
[ri,li,xi ] 其中 ri表示风险,li表示风险发生的
概率，表示风险产生的影响。
开始考虑如何避免风险的发生 。
第 6章 风险管理
进度
延迟
临界点（成本、时间）
终止项目
成本超支
风险参考水平线
第 6章 风险管理
6.5 风险缓解、监控和管理
风险分析活动的目的就是辅助项目组建立处理
风险的策略。通常从三个方面考虑问题, （ 1）
风险避免；（ 2）风险监控；（ 3）风险管理
及意外事件计划。
软件项目组应采取主动的方法，分析风险所造
成的影响，尽可能避免风险的发生。这可以
通过风险缓解计划来达到。例如：假设频繁
的人员流动被标注为一个项目风险，他对项
目成本及进度有严重影响。为了缓解这个风
险，项目管理必须建立一个策略来降低人员
流动。
第 6章 风险管理
? 与现有人员一起探讨一下人员流动的原因。
? 一旦项目启动，假设会发生人员流动并采取
一些技术以保证当人员离开时工作的连续性。
? 对所有工作进行详细复审，使得不止一个人
熟悉该项工作。
? 对于每一个关键的技术人员都指定一个后备
人员。
? 与报酬和利益相关的潜在问题。
? 在公司内和公司外工作的可能性。
第 6章 风险管理
项目管理者应监控风险缓解步骤的效力。
项目管理者应该仔细地监控这些文档，
以保证这些文档内容正确。
RMMM计划步骤将导致额外的项目开销。
一个大项目可能标出 30-40个风险，如果
对每一个风险都建立一个风险管理计划，
那么，工作量将增加很多。所以可按 80-
20原则来对风险进行管理。
第 6章 风险管理
6.6 安全风险和危险
风险并不仅限于软件项目本身。在软件
交付给用户之后仍有可能发生风险。
软件安全和危险分析是属于软件质量保证
活动。如果能够在早期阶段标识出风险，
则可以在软件开发过程中消除或控制潜
在的风险。
第 6章 风险管理
6.7 RMMM计划
风险管理策略可以包含在软件项目计划中，
或者风险管理步骤也可以组织成一个独立的
风险缓解、监控和管理计划（ RMMM计划）。
RMMM计划大纲如下：
1.引言
1.1 文档的范围和目的
1.2主要风险综述
1.3 责任
1,3,1 管理者
1,3,2 技术人员
第 6章 风险管理
2,项目风险表
2,1 终止线之上的所有风险描述
2,2 影响的概率及影响的因素
3, 风险缓解、监控和管理
3, n, 风险 # n
3, n,1 缓解
a,一般策略
b,缓解风险的特定步骤
第 6章 风险管理
3, n,2 监控
a,被监控的因素
b.监控方法
3, n,3 管理
a,意外事件计划
b,特殊的考虑
4.RMMM计划的迭代时间安排表
5.总结
6.8 SUMMARY
Whenever a lot is riding on a software project,
common sense dictates risk analysis,And
yet,most software project managers do it at all,
The time spent identifying,analyzing,and
managing risk pays itself in many ways:less
upheaval during project ;a greater ability to track
and control a project ;and the confidence that
comes with planning for problems before they
occur.
Risk analysis can absorb a significant amount of
project planning effort, Identification,
6.8 SUMMARY
projection,assessment,management,and
monitoring all take time,But the effort is
worth it,To quote sun Tzu,a Chinese
general who lived 2500 years ago,“If you
know the enemy and know yourself,you
need not the result of a hundred battles.”
For the software project manager,the
enemy is risk,
