Pressman ch6 风险管理课件

1、软件工程第六章 风险分析和管理 第六章 风险分析和管理 要点浏览概念：风险风险和管理是一系列帮助软件小组理解和管理不确定性的步骤。一个风险是一个潜在的问题它可能发生，也可能不发生。但是，不管最后结果是什么，去标识它、评估其发生的概率、估算其影响、并建立问题实际发生情形下的应急计划不失为一个好主意。人员：涉及到软件项目的每一个人管理者、软件工程师和客户均参与风险分析和管理。 第六章 风险分析和管理 为什么重要：软件是一项困难的任务，大量的事情可能出错，而且，很多事情经常出错。为此，准备着理解风险和采取积极的去避免或管理风险是好的软件项目管理的关键因素。步骤：认识到什么可能出错是第一步，称为“风险

2、标识”。接着，分析每个风险以确定它可能发生的概率，以及当其发生时将带来的危害。一旦这些信息被建立，则根据概率和影响对风险进行排序。最后，建立一个管理那些具有高概率和高影响的风险的计划。 第六章 风险分析和管理 产品：一个风险缓解（mitigation）、监控（monitoring）和管理（management）（RMMM）的计划，或一组风险信息表单。保障措施：被分析和管理的风险应该从对人员、产品、过程和项目的彻底研究而导出。RMMM应该随着项目的进展而修订，以保证风险是最新的。风险管理的应急计划应该是现实的。 第六章 风险分析和管理 Robert Charette在他的关于风险分析和管理的书中

3、给出了风险的概念定义如下：首先，风险关注未来将要发生的事情。今天和昨天已不再被关心，因为我们已经在收获由我们过去的行为所播下的种子。疑问是：我们是否能够通过改变我们今天的行为，而为一个不同的、充满希望的、更美好的明天创造机会。其次，风险涉及改变，如思想、观念、行为、或地点的改变.第三，风险涉及选择，及选择本身所包含的不确定性。因此，就象死亡和税收一样，风险是生活中最不确定的元素之一。 第六章 风险分析和管理“当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了”。在我们能够标识出软件项目中的“真正风险”之前，识别出所有对管理者及开发者而言均为明显的风险是很重要的。 6

4、.1被动和主动的风险策略 (1)被动风险策略被戏称为“印地安那琼斯学派的风险管理”。印地安那琼斯在以其名字为影片名的电影中，每当面临无法克服的困难时，总是一成不变地说：“不要担心，我会想出办法来的！”。印地安那琼斯从不担心任何问题，直到它们发生，再作出英雄式的反应。遗憾的是，一般的软件项目管理者并不是印地安那琼斯，而且软件项目组的成员也不是他的可信赖的伙伴。 6.1被动和主动的风险策略 (3)QUOTE：如果你不主动的进攻风险，风险将会主动地进攻你。Tom Gilb对于风险管理的一个更聪明的策略是主动式的。主动策略早在技术工作开始之前就已经启动了。标识出潜在的风险，评估它们出现的概率及产生的影

5、响，且按重要性加以排序。然后，软件项目组建立一个计划以管理风险。主要的目标是预防风险，但因为不是所有的风险都能够预防，所以，项目组必须建立一个应急计划，使其在必要时能够以可控的及有效的方式作出反应。我们将讨论风险管理的主动策略。 6.2软件风险 (1)虽然对于软件风险的严格定义还存在很多争议，但在风险包含了两个特性这一点上是达成共识的：* 不确定性风险可能发生也可能不发生；即，没有100%发生的风险。* 损失如果风险变成了现实，就会产生恶性后果或损失。 6.2软件风险 (2)进行风险分析时，重要的是量化不确定性的程度及与每个风险相关的损失的程度。为了实现这点，必须考虑不同类型的风险。？：在建造

6、软件时，我们可能遇到什么类型的风险。 6.2软件风险 (4)技术风险威胁到要开发软件的质量及交付时间。如果技术风险变成现实，则开发工作可能变得很困难或根本不可能。技术风险是指潜在的设计、实现、接口、验证、和维护等方面的问题。此外，规约的二义性、技术的不确定性、陈旧的技术、及“领先的”技术也是风险因素。技术风险的发生是因为问题比我们所设想的更加难以解决。 6.2软件风险 (5)商业风险威胁到要开发软件的生存能力。商业风险常常会危害项目或产品。五个主要的商业风险是：（1）开发了一个没有人真正需要的优秀产品或系统（市场风险）；（2）开发的产品不再符合公司的整体商业策略（策略风险）；（3）建造了一个销

7、售部门不知道如何去卖的产品；（4）由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）；以及（5）没有得到预算或人力上的保证（预算风险）。绝对重要的一点是应该注意到：简单的分类并不总是行得通。某些风险根本无法事先预测。 6.3风险标识 (1)风险标识是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。通过标识已知的和可预测的风险，项目管理者已经迈出了第一步在可能时避免这些风险，且当必要时控制这些风险。在6.2节中提出的每一类风险又分为两个不同的类型：一般性风险和产品特定的风险。一般性风险对每一个软件项目而言都是一个潜在的威胁。产品特定的风险只有那些对当前项目的技术、人员、及环

8、境非常了解的人才能标识出来。 6.3风险标识 (2)为了标识产品特定的风险，必须检查项目计划及软件范围陈述，并给出以下问题的答案：“本项目中有什么特殊的特性可能会威胁到我们的项目计划？”ADVICE：虽然一般性风险的考虑是重要的，但是，通常产品特定的风险会带来更多的问题。确定花费时间去标识尽可能多的产品特定的风险。 6.3风险标识 (3)标识风险的一个方法是建立风险条目检查表。该检查表可以用于风险标识，并集中于下列一般性子类型中的已知的及可预测的风险：* 产品规模与要建造或要修改的软件的总体规模相关的风险。* 商业影响与管理或市场所加诸的约束相关的风险。* 客户特征与客户的素质以及开发者和客户

9、及时通信的能力相关的风险。 6.3风险标识 (4)* 过程定义与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。* 开发环境与用以建造产品的工具的可用性及质量相关的风险。* 将建造的技术与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险。* 人员数目及经验与参与工作的软件工程师的总体技术水平及项目经验相关的风险。 6.3风险标识 (5)风险条目检查表能够以不同的方式来组织。与上述每个话题相关的提问可以针对每一个软件项目来回答。这些问题的答案使得计划者能够估算风险产生的影响。我们也可以采用另一个不同的风险条目检查表格式，它仅仅列出与每一个一般性子类型有关的特性。最后，列出一

10、组“风险元素和驱动因子”以及它们发生的概率。关于性能、支持、成本、及进度的驱动因子将在以后讨论。 6.3风险标识 (6)QUOTE：风险管理是针对成人的项目管理。Tim Lister一组全面的关于软件项目风险的检查表在文献（如，SEI93、KAR96）中被提出，这些检查表提供了对软件项目的一般性风险的洞悉，凡当启动风险分析和管理时应该是十分有用的。然而，一个相对短的提问表可被用于提供对是否项目处于“风险”状态的指标。 6.3.1 评估整体项目风险 (2)5. 终端用户的期望现实吗？6. 项目范围稳定吗？7. 软件工程队伍拥有合适的技能吗？8. 项目需求稳定吗？9. 项目小组对将实现的技术有经验

11、吗？10. 项目小组的人员数目适合于完成该工作吗？ 6.3.1 评估整体项目风险 (3)11. 所有的客户/用户对项目的重要性和待建造的系统/产品的需求有共识吗？如果这些提问的任意一个的回答是否定的，则应该确定无疑地启动缓解、监控和管理步骤。项目处于风险的程度直接正比于这些提问的否定回答的数量。 6.3.2 风险因素和驱动因子 (2)* 性能风险产品能够满足需求且符合于其使用目的的不确定的程度。* 成本风险项目预算能够被维持的不确定的程度。* 支持风险软件易于纠错、适应修改、及增强的不确定的程度。* 进度风险项目进度能够被维持且产品能按时交付的不确定的程度。 6.3.2 风险因素和驱动因子 (

12、3)每一个风险驱动因子对风险元素的影响均可分为四个影响类别可忽略的、轻微的、严重的、及灾难的。图6.1指出了由于错误而产生的潜在影响（标为1的行）或没有达到预期的结果所产生的潜在影响（标为2的行）。影响类别的选择是基于最符合表中描述的特性。 图 6.1 影响评估 BOE89 注：（1）未测试出的软件错误或缺陷所产生的潜在影响。 （2）如果没有达到预期的结果所产生的潜在影响。 6.4风险预测 (1)风险预测，又称风险估算，试图从两个方面评估每一个风险风险发生的可能性或概率，以及如果风险发生了，所产生的后果。项目计划者，以及其它管理人员和技术人员，一起执行四个风险预测活动：（1）建立一个尺度，以反

13、映风险发生的可能性；（2）描述风险的后果；（3）估算风险对项目及产品的影响；（4）标注风险预测的整体精确度，以免产生误解。 6.4风险预测 6.4.1建立风险表 风险表给项目管理者提供了一种简单的风险预测技术。风险表的样本如图6.2所示。项目组一开始要在表中的第一列列出所有风险（不管多么细微）。这能够利用6.3节所述的风险条目检查表来完成。每一个风险在第二列上加以分类（如，PS指产品规模风险，BU指商业风险）。每个风险发生的概率则输入到第三列中。每个风险发生的概率值可以由项目组成员个别估算，个体成员通过循环的方式投票，直至他们的风险概率评估开始会聚。 图6-26.4.1建立风险表风险规模估算可

14、能非常低用户数量大大超出计划复用程度低于计划最终用户抵制该系统交付期限将被紧缩资金将会流失用户将改变需求技术达不到预期的效果缺少对工具的培训人员缺乏经验人员流动比较频繁 6.4.1建立风险表 ADVICE：尽力思考你将要建造的软件并问你自己，“什么有可能出错？”创建你自己的列表并要求软件小组的其他成员同样如此做。下一步是评估每个风险所产生的影响。使用图6.1所述的特性评估每个风险元素，并确定其影响的类别。四个风险元素性能、支持、成本、及进度的影响类别被求平均以得到一个整体的影响值。 6.4.1建立风险表 一旦完成了风险表的前四列内容，就要根据概率及影响来进行排序。高发生概率、高影响的风险放在表

15、的上方，而低概率风险则移到表的下方。这样就完成了一阶风险优先序。KEYPOINT：风险表根据概率和影响对风险进行排序。项目管理者研究已排序的表，并定义一条中止线。该中止线（表中某一点上的一条水平线）表示：只有那些在线之上的风险才会得到进一步的关注。 6.4.1建立风险表 而在线之下的风险则需要再评估以完成二阶风险优先序。风险影响及概率从管理的角度来考虑，是起着不同的作用的（见图6.3-第4版图6-1）。一个具有高影响但发生概率很低的风险因素不应该花费太多的管理时间。而高影响且发生概率为中到高的风险、以及低影响且高概率的风险，应该首先列入随后的风险分析步骤中。 图6-36.4.1建立风险表 所有

16、在中止线之上的风险都必须进行管理。标有RMMM的列中包含了一个指示器，指向为所有中止线之上的风险所建立的风险缓解、监控、及管理计划（Risk Mitigation，Monitoring and Management Plan），或者，一组风险信息表单。RMMM计划和风险信息表单将在6.5和6.6节讨论。QUOTE：没有准备即是准备失败。Ben Franklin 6.4.1建立风险表 风险概率的确定可以通过先做个别估算而后求出一个有一致共识的值。虽然该方法是可行的，不过仍存在很多其它确定风险概率的更加复杂的技术AFC88。风险驱动因子的评估基于一个定性的概率尺度：不可能、不一定、可能、和极可能。

17、然后，给每一个定性值关联上数学的概率值（如，概率为0.7到1.0表示极可能发生的风险）。 6.4.2评估风险影响 有三个因素可能会影响如果风险真的发生了所产生的后果：风险的性质、范围、及时间。风险的性质是指当风险发生时可能产生的问题。例如，一个定义得很差的与客户硬件的外部接口（技术风险）会妨碍早期的设计及测试，也有可能导致项目后期阶段的系统集成问题。风险的范围结合了严重性（即风险有多严重？）及其整体分布情况（项目中有多少部分受到影响或有多少用户受到损害？）。 6.4.2评估风险影响 最后，风险的时间主要考虑何时能够感到风险及持续多长时间。在大多数情况下，项目管理者希望“坏消息”越早出现越好，但

18、在某些情况下，越迟越好。让我们再回到美国空军提出的风险分析方法上来。以下的步骤被建议用来确定风险的整体影响： 6.4.2评估风险影响1 确定每个风险元素发生的平均概率。2 使用图6.1，基于其中列出的标准来确定每个元素的影响。3 按照前面几节给出的方法完成风险表，并分析其结果。整体的风险曝光度（risk exposure），RE，用下面关系确定：RE PC这里P是风险发生的概率，C是风险发生时带来的项目成本。 6.4.2评估风险影响例如，假定软件小组以如下方式定义了一个项目风险：风险标识：事实上，预定要复用的软件构件中只有70将被集成到应用中，剩余的功能将必须被定制开发。风险概率：80（可能）

19、。 6.4.2评估风险影响风险影响：计划了60个可复用软件构件，如果只有70可能被使用，则18个构件将必须从头开发（除了其他已经计划开发的定制软件之外）。因为构件平均是100 LOC，且本地数据显示，每个LOC的软件工程成本是14.00美元，开发构件的整体成本（影响）将是1810014 25200美元。风险曝光度：RE 0.8025200，约为20200美元。 6.4.2评估风险影响一旦风险的成本估算完成，则可以针对风险表中的每个风险计算风险曝光度。对所有风险（在风险表中的中止线之上）的全部风险曝光度可以提供一种调节项目的最终成本估算的方法，它也可以用于预测在项目进度中各个点上所需的人员资源的

20、可能增加。ADVICE：将所有风险的RE和项目的成本估算进行比较，如果RE大于项目成本的50，则项目的生存力必须被评估。 6.4.2评估风险影响6.4.1节和6.4.2节所述的风险预测和分析技术可以在软件项目进展过程中迭代使用。项目组应该定期复查风险表，再评估每一个风险，以确定新的情况是否引起其概率及影响发生改变。这个活动的结果可能需要在表中添加一些新风险，删除一些不再有影响的风险，并改变风险的相对位置。 6.4风险预测 6.4.3风险评估 (1)在风险管理中的这一步，我们建立了如下形式的一组三元组：ri,li,xi其中ri表示风险，li表示风险发生的概率，xi则表示风险产生的影响。在风险评估

21、过程中，我们进一步审查在风险预测阶段所做的估算的精确度，试图为所发现的风险排出优先次序，并开始考虑如何控制和/或避免可能发生的风险。 6.4.3风险评估 (2)要使评估发生作用，必须定义一个风险参考水平。对于大多数软件项目而言，前面所讨论的风险元素性能、成本、支持、及进度也表示了风险参考水平。即，对于性能下降、成本超支、支持困难、或进度延迟（或者这四种的组合），都有一个水平，超过它就会导致项目被迫终止。如果风险的组合所产生的问题引起一个或多个参考水平被超过，则工作将会停止。在软件风险分析中，风险参考水平存在一个点，称为参考点或临界点，在这个点上决定继续进行该项目或终止它（问题太大时）都是可以接

22、受的。图6.4（第4版图6-2）以图形方式表示了这种情况。 图6-4 （第4版图6-2）6.4.3风险评估 KEYPOINT：风险参考水平建立了你的痛苦忍耐度，一旦风险曝光度超出参考水平，项目可能被终止。实际上，参考水平很少能表示成如图所示的一条光滑曲线。在大多数情况下，它是一个区域，其中存在很多不确定性，即，试图基于参考值的组合预测管理决策常常是不可能的。因此，在风险评估过程中，我们执行以下步骤： 6.4.3风险评估1 定义项目的风险参考水平。2 建立每一组ri,li,xi与每一个参考水平之间的关系。3 预测一组临界点以定义项目终止区域，该区域由一条曲线或不确定区域所界定。4 预测什么样的风

23、险组合会影响参考水平。 6.5 风险求精 (1)在项目计划的早期阶段，风险可能是相当一般性地陈述的。随着时间推移，关于项目和风险的了解加深，有可能将风险精化为一组更详细的风险，而每个风险在某种程度上更易于被缓解、监控和管理。这样做的一种方式是按条件变迁结果（condition-transtion- consequence，CTC）格式来表示风险，即，风险按如下方式陈述：？：什么是描述风险的好方式？ 6.5 风险求精 (2)给定，则存在担忧（可能）。使用CTC格式，在6.4.2节中提到的复用风险可描述为：给定：所有可复用软件构件必须符合特定设计标准，且某些并不符合，则存在担忧（可能）：仅仅70的

24、计划中的可复用模块可被集成进最终的系统中，从而导致了定制开发剩余的30的构件的需要。 6.5 风险求精 (3)这个一般性条件可以按如下方式精化：子条件1：某些可复用构件是由不知道内部设计的第三方开发的。子条件2：构件接口的设计标准尚未固定下来，且可能不符合某些也有的软件构件。子条件3：某些可复用构件已经实现为目标环境所不支持的语言。和这些精化的子条件关联的结果保持相同（即，30的软件构件必须被定制开发），但是，求精可以帮助我们孤立底层根本性的风险，并且可能导致更容易的分析和回应。 6.6 风险缓解、监控和管理 (1)这一步的所有风险分析活动都只有一个目的辅助项目组建立处理风险的策略。一个有效的

25、策略必须考虑三个问题：* 风险避免* 风险监控，和* 风险管理及应急计划6.6 风险缓解、监控和管理 (2)QUOTE：我采取如此多的预防措施，是因为我不想留下任何冒险机会。Napolean如果软件项目组对于风险采用主动的方法，则避免永远是最好的策略。这可以通过建立一个风险缓解计划来达到。例如，假设频繁的人员流动被标注为一个项目风险，r0。基于以往的历史及管理经验，人员频繁流动的概率l0被估算为0.7（百分之70，相当高），而影响x0被预测为第二级，即，高的流动率对于项目成本及进度有严重的影响。为了缓解这个风险，项目管理必须建立一个策略以降低人员流动。可能采取的策略如下： 6.6 风险缓解、监

26、控和管理 (3)* 与现有人员一起探讨一下人员流动的原因（如，恶劣的工作条件，低报酬，竞争激烈的劳动力市场）。* 在项目开始之前，采取行动以缓解那些在我们管理控制之下的原因。* 一旦项目启动，假设会发生人员流动并采取一些技术以保证当人员离开时的工作连续性。* 对项目组进行良好组织，使得每一个开发活动的信息能被广泛传播和交流。 6.6 风险缓解、监控和管理 (4)* 定义文档的标准并建立相应的机制以确保文档能被及时建立。* 对所有工作进行详细复审，使得不止一个人熟悉该项工作。* 对于每一个关键的技术人员都指定一个后备人员。随着项目的进展，风险监控活动开始进行了。项目管理者监控某些因素，这些因素可

27、以提供风险是否正在变高或变低的指示。在人员频繁流动的例子中，应该监控下列因素： 6.6 风险缓解、监控和管理 (5)* 项目组成员对于项目压力的一般态度。* 项目组的凝聚力。* 项目组成员彼此之间的关系。* 与报酬和利益相关的潜在问题。* 在公司内及公司外工作的可能性。QUOTE：我们准备好迎接某未曾预见到的事件，它可能发生，也可能不发生。 6.6 风险缓解、监控和管理 (6)除了监控上述因素之外，项目管理者还应该监控风险缓解步骤的效力。例如，前述的一个风险缓解步骤中要求定义“文档的标准并建立相应的机制以确保文档能被及时建立”。如果有关键的人员离开了项目组，这是一个保证工作连续性的机制。项目管

28、理者应该仔细地监控这些文档，以保证每一个文档内容正确，且当新员工在项目进行中某点加入该项目时，能够提供必要的信息。 6.6 风险缓解、监控和管理 (7)风险管理及应急计划假设缓解工作已经失败且风险变成了现实。继续前面的例子，假定项目正在进行之中，有一些人宣布将要离开。如果按照缓解策略行事，则有后备人员可用，信息已经文档化，有关知识已经在项目组中广泛交流。此外，项目管理者还可以暂时重新调整资源（并调整项目进度）以集中于那些人员充足的功能，从而使得新加人员能够“赶上进度”。同时，应该要求那些要离开的人员停止工作，并在最后几星期进入“知识交接模式”。这可能包括：基于视频的知识捕获，“注释文档”的建立

29、，和/或与仍留在项目组中的成员进行交流。 6.6 风险缓解、监控和管理 (8)值得注意的是，RMMM步骤将导致额外的项目开销。例如，花费时间去“备份”每一个关键的技术人员需要花钱。因此，风险管理的部分任务是评估何时由RMMM步骤所产生的效益低于实现它们所花费的成本。本质上，项目计划者执行一个典型的成本效益分析。如果对于频繁人员流动的风险缓解步骤将会增加百分之15的项目成本及持续时间，而主要的成本因素是“备份后备人员”，则管理者可能决定不执行这一步骤。另一方面，如果风险缓解步骤仅增加百分之5的成本及百分之3的持续时间，则管理者极有可能将这一步骤付诸实现。 6.6 风险缓解、监控和管理 (9)AD

30、VICE：如果某特定风险的RE小于风险缓解的成本，不要试图去缓解该风险，而是继续去监控之。对于一个大型项目，可能标识出30 或40种风险。如果为每种风险定义三至七个风险管理步骤，则风险管理本身就可能变成一个“项目”！因此，我们将Pareto的8020规则用于软件风险上。经验表明：整个软件风险的百分之80（即，可能导致项目失败的百分之80的潜在因素）能够由仅仅百分之20的已标识风险来说明。6.6 风险缓解、监控和管理 (10)早期风险分析步骤中所实现的工作能够帮助计划者确定哪些风险在所说的这百分之20中（如，导致高风险曝光度的风险）。为此，一些已经标识、评估及预测的风险可能并不纳入RMMM计划之

31、中它们不属于那关键的百分之20（具有最高项目优先级的风险）。 6.7 安全性风险和危险 (1)风险并不仅限于软件项目本身。在软件已经被成功开发并交付给客户之后，仍有可能发生风险。这些风险一般与领域中的软件失败相关。在计算的早期，人们不愿使用计算机（和软件）去控制安全关键的过程，如核反应堆、飞机飞行控制、武器系统、及大型工业过程。虽然一个良好开发的系统发生错误的概率很小，但在基于计算机的控制及监督系统中未被发现的错误可能会导致巨大的经济损失，或者更加严重，造成人员伤害或丧失生命。不过，基于计算机的控制及监督系统所产生的成本和功能效益常常超过这种风险。今天，计算机硬件及软件已经大量用于控制安全关键

32、的系统。 6.7 安全性风险和危险 (2)当软件被用作控制系统的一部分时，复杂度会呈现数量级的增加。由于人的错误所引起的微小的设计缺陷这在基于硬件的传统控制系统中能够被发现并消除当使用软件时会变得难以发现。软件安全性和危险分析是软件质量保证活动（第8章），集中于标识和评估可能对软件产生负面影响并使整个系统失败的潜在危险。如果危险能够在软件工程的早期阶段被标识，则可以指定软件设计特征以消除或控制潜在的危险。 6.8 RMMM计划 (1)风险管理策略可以包含在软件项目计划中，或者风险管理步骤也可以组织成一个独立的风险缓解、监控和管理计划（RMMM 计划）。RMMM计划将所有风险分析工作文档化，并由项目管理者使用作为整个项目计划中的一部分。某些软件小组并不建立正式的RMMM文档，而是，将每个风险个别地使用风险信息表单（ri