第1章软件工程风险管理ppt课件

1、第15章 软件工程风险管理 第15章 软件工程风险管理 15.1 软件风险软件风险15.2 风险识别风险识别15.3 风险预测风险预测 15.4 风险缓解、监控与管理风险缓解、监控与管理15.5 RMMM方案方案 15.6 小结小结 第15章 软件工程风险管理 15.1 软软 件件 风风 险险 对软件风险的严厉定义还存在着很多争议，但对于在风险中包含了两个特性这一点上曾经达成了共识。 (1) 不确定性：风险能够发生也能够不发生，即不存在发生概率为100%的风险(100%会发生的风险实践上是加在工程上的约束)。 (2) 危害性：一旦风险变成了现实，就会产生恶性后果或损失。 第15章 软件工程风险

2、管理 进展风险分析时，重要的是量化不确定性的程度和与每个风险相关的损失程度。为了到达此目的，必需思索不同类型的风险。 工程风险要挟到工程方案。也就是说，假设工程风险变成现实，能够会拖延工程进度且添加工程的本钱。工程风险是指潜在的预算、进度、人力(任务人员及组织)、资源、客户及需求等方面的问题以及它们对软件工程的影响。工程的复杂性、规模及构造不确定性也被定义为工程(估算)风险要素。第15章 软件工程风险管理 技术风险要挟到要开发软件的质量和交付时间。假设技术风险变成现实，那么开发任务能够变得很困难或者根本不能够。技术风险是指潜在的设计、实现、接口、验证和维护等方面的问题。此外，需求规约的二义性，

3、技术的不确定性，陈旧的技术及“先进的技术也是风险要素。技术风险的发生是由于问题比我们所想象的更难以处理。第15章 软件工程风险管理 商业风险要挟到要开发的软件的生存才干。商业风险经常会危害工程或产品。五个主要的商业风险是： 市场风险：开发了一个没有人真正需求的优秀产品或系统。 战略风险：开发的产品不再符合公司的整体商业战略。 营销风险：消费了一个销售部门不知道如何去卖的产品。 管理风险：由于重点的转移或人员的变动，失去了高级管理层的支持。 预算风险：没有得到预算或人力上的保证。 第15章 软件工程风险管理 另一种分类方式将风险分为三类： 知风险：经过仔细评价工程方案，开发工程的商业及技术环境以

4、及其他可靠的音讯来源(如不现实的交付时间，恶劣的开发环境，没有需求或者软件范围文档)之后可以发现的那些风险。 可预测风险：可以从过去工程的阅历中推断出来(如人员调整、与客户无法沟通、开发人员精神分散)的风险。 不可预测风险：能够或有时真会出现的风险，但事先很难识别出来。第15章 软件工程风险管理 15.2 风风 险险 识识 别别 风险识别就是要识别属于前述类型中的某些特定的风险。方法是利用一组问卷来协助工程方案人员了解在工程和技术方面有哪些风险。Boehm建议运用一个“风险工程检查表列出一切能够的与每一个风险要素有关的提问。例如，管理人员或方案人员可以经过回答以下问题得到对有关人力风险的认识：

5、可用人员是最优秀的吗？按照技艺对人员进展了合理组合吗？人力足够吗？第15章 软件工程风险管理 整个工程开发期间人员如何投入？有多少人不是全工时投入本工程的任务？人们对于手头上的任务能否有正确的目的？工程成员能否接受过必要的培训？工程的成员能否是稳定的和延续的？第15章 软件工程风险管理 对于这些提问，经过断定分析或假设分析，给出确定的回答，就可以协助管理人员或方案人员估算风险的影响。当然，上面仅仅是针对人力资源风险有效的问题。同样地，我们也可以对其他类型的风险制定出必要的问题，利用和上述方法一样的手段，估算不同类别风险的影响。例如，针对技术风险的问题包括： 该技术对他的组织来说是新的吗？ 客户

6、的需求能否需求创建新的算法或I/O技术？ 软件能否需求运用新的或未经证明的硬件接口？第15章 软件工程风险管理 待开发软件能否要和开发商提供的未经证明的软件接口？ 待开发软件能否要和其功能和性能均未在身手域中得到证明的数据库系统接口？ 产品的需求中能否包括要求采用特定的用户界面？ 产品的需求中能否要求开发某些程序构件，这些构件和他的组织从前开发过的构件完全不同？ 需求中能否要求运用新的分析、设计或测试方法？第15章 软件工程风险管理 需求中能否要求运用非传统的软件开发方法，如方式化方法，人工神经网络方法？ 需求中对产品性能的约束能否过分严厉？ 客户能确定所要求的功能是“可行的吗？ 假设对于上列

7、问题中任何一个问题的回答是一定的，那么需求进展进一步的调研来评价潜在的风险。第15章 软件工程风险管理 15.3 风风 险险 预预 测测 风险预测又称为风险估算。它试图从两个方面去评价每一个风险：其一是风险发生的能够性或概率；其二是假设风险发生了会呵斥的后果。风险预测活动要进展四项任务： (1) 建立一个尺度，以反映风险发生的能够性(尺度可以是布尔值、定性的或定量的)。 (2) 描画风险的后果。 (3) 估算风险对工程和产品的影响。 (4) 标注风险整体预测的准确度以免产生误解。第15章 软件工程风险管理 15.3.1 建立风险表建立风险表表表15.1 风险预测表样本风险预测表样本风险描画风险

8、类别发生概率能够的影响RMMM规模估算能够非常低产品规模60%2 用户数量大大超越方案产品规模30%3 复用程度低于方案产品规模70%2最终用户抵抗该系统商业风险40%3 交付期限紧缩商业风险50%2 第15章 软件工程风险管理 资金流失预算风险40%1 需求改动产品规模80%2 技术达不到预期效果技术风险30%1 短少对于工具的培训人力风险80%3 人员缺乏阅历人力风险30%2 人员流动频繁人力风险60%2 表表15.1 风险预测表样本风险预测表样本第15章 软件工程风险管理 在表15.1中，影响类别取值为1：灾难的；2：严重的；3：细微的；4：可以忽略的。工程组将一切能够的风险都在第一列中

9、列出，在第二列上加以分类。发生概率经评价后取评价均值，将估计的影响程度填入第四列，然后按照发生概率和影响程度自高到低地对风险表进展第一次风险排序。 管理者研讨曾经排序的风险表，定义一条中止线，普通来说，管理者对于中止线以上的风险会进展进一步的关注。其他的风险需求再次评价以完成第二次排序。第15章 软件工程风险管理 图15.1 风险和管理的思索01.0很高影响很低可忽略的风险因素发生的概率管理的考虑高第15章 软件工程风险管理 风险表中一切在终止线以上的风险都该当进展管理。在表的最后一列包含有一个指针，指向为一切终止线以上的风险制定的风险缓解、监控和管理方案(RMMM方案，Risk Mitiga

10、tion，Monitoring and Management Plan)。 第15章 软件工程风险管理 15.3.2 风险评价风险评价 建立一个三元组集合来进展风险评价：建立一个三元组集合来进展风险评价：Ri，Li，Xi。其中，。其中，Ri是风险，是风险，Li是风险出现的能够性，是风险出现的能够性，Xi是风险出现会呵斥的影是风险出现会呵斥的影响。在进展风险评价时，该当进一步检验在风险预测时得到的响。在进展风险评价时，该当进一步检验在风险预测时得到的估计的准确性估计的准确性(影响及概率影响及概率)，试图为已被发现的风险排出优先顺，试图为已被发现的风险排出优先顺序，并开场思索如何控制或防止能够发生

11、的风险。序，并开场思索如何控制或防止能够发生的风险。第15章 软件工程风险管理 要使评价发生作用，必需定义一个风险参考程度值。对于大多数软件工程而言，前面所讨论的风险要素性能、本钱、支持及进度也代表了风险参考程度值，即对于性能下降、本钱超支、支持困难、进度延迟(或者它们的组合)都有一个程度值的要求。超出程度值就会导致工程被迫终止。假设风险的组合所产生的问题引起一个或多个参考程度值被超越，那么任务将会停顿。在软件风险分析中，风险参考程度值存在一个点，称为参考点或临界点。在这个点上，决议继续进展某工程或者是终止它(问题太大了)都是可以接受的。图15.2中就表示了这种情况。假设风险组合产生的问题导致

12、本钱超支及进度延迟，那么会有一个程度值，(即图中的曲线)，当超越它时会引起工程终止。第15章 软件工程风险管理 图15.2 风险参考程度曲线终进度延迟临界点(成本、时间)成本超支止项目第15章 软件工程风险管理 实践上参考程度值很少可以表示成如图15.2所示的光滑曲线。在大多数情况下，它是一个区域，其中存在很多不确定性，这个区域能够是一个易变区域。在这些区域中想要做出基于参考值组合的管理判别往往是非常困难的。因此，在作风险评价时，可以采用下面的步骤执行： (1) 为工程定义风险参照水准。 (2) 尝试找出在每一个Ri，Li，Xi 和每一个参照水准之间的关系。 (3) 预测参照点组以定义一个终止

13、区域，用一条曲线或一些易变动区域来界定。 (4) 努力预测复合的风险组合将如何构成一个参照水准。 第15章 软件工程风险管理 15.4 风险缓解、监控与管理风险缓解、监控与管理 在这一步的任务中，一切的风险分析活动都只需一个目的，那就是辅助工程建立处置风险的战略。任何一种有效的战略都必需思索三个问题：风险防止、风险监控、风险管理及不测事件方案。 假设工程组对于风险采取自动战略，那么最好的方法是经过制定一个风险缓解方案并付诸实施，设法防止风险。图15.3所示为风险缓解与监控。第15章 软件工程风险管理 图15.3 风险缓解与监控风险分析数据1R1, L1, X1风险缓解步骤1风险1风险分析数据2

14、R2, L2, X2风险缓解步骤2风险2风险分析数据nRn, Ln, Xn风险缓解步骤n风险n风险缓解风险缓解与监控计划第15章 软件工程风险管理 例如人员频繁流动是软件开发组织中的一个普遍存在的风险。将其标注为R0，基于以往的历史数据和管理阅历，发生概率L0被估算为0.7，影响X0被预测为对于工程的本钱和进度有极严重的影响。 为了缓解这一风险，工程管理者可以采取如下的战略来降低人员流动： (1) 预先与现有人员一同讨论一下人员流动的缘由(如任务条件恶劣、低报酬、猛烈的人才竞争)。 (2) 在工程开场之前，采取行动来缓解那些被识别出的、且在管理控制之下的缘由。第15章 软件工程风险管理 (3)

15、 一旦工程启动，假设人员会发生流动，并采取一些措施以保证当人员分开时任务的延续性。 (4) 对工程组进展良好的组织，使得每一个开发活动的信息可以被广泛地传播和交流。 (5) 定义文档的规范，并建立保证文档可以被及时、正确建立的机制。 (6) 对一切的任务进展详细的复审，保证不止一个人熟习该项任务。 (7) 对每一个关键的技术人员都指定一个后备人员。第15章 软件工程风险管理 随着工程的进展，开场进展风险监控活动。工程管理者监控某些要素，这些要素可以提供风险能否正在变高或变低的指示。针对人员频繁流动的风险，该当监控以下要素：(1) 工程组成员对于工程压力的普通态度。(2) 工程组的凝聚力。(3)

16、 工程组成员彼此之间的关系。(4) 与报酬和利益相关的潜在问题。(5) 在公司内和公司外任务的能够性。第15章 软件工程风险管理 除了监控上述要素之外，工程管理者还该当监控预设的风险缓解步骤的效能。例如，前述的一个风险缓解步骤中要求定义“定义文档的规范，并建立保证文档可以被及时、正确建立的机制。 假设有关键的人员分开了工程组，这就是一个坚持任务延续性的机制。工程管理者该当仔细监控这些文档，以保证每一个文档内容正确，而且当新员工参与工程组时，可以利用曾经建立并得到监控的文档为他们提供必要的信息。 第15章 软件工程风险管理 假设风险缓解任务失败，风险曾经发生，那么就要按照风险管理和不测事件处置方

17、案(风险应对预案)进展处置，减少风险带来的损失。假定工程进展过程中，有一些人宣布要分开，假设我们执行了缓解措施，那么就有后备人员可用，同时由于信息曾经文档化，并且有关知识曾经在工程组中广泛地进展了交流，后备人员可以很快地接手任务。此外，工程管理者还可以暂时重新将资源调整到那些人员充足的功能上去(并对工程进度作必要的调整)，从而使得新参与的人员可以“赶上进度。 同时，该当要求宣布要分开的人员停顿任务，在最后一段时间里进入“知识与业务交接方式。第15章 软件工程风险管理 该当留意的是，在防备风险的过程中是要破费本钱的。该当在防备措施的本钱和风险一旦发生的损失之间进展投入产出分析，以此确定要执行什么

18、样的风险防备措施。举例来说，为每个工程组成员都配备一名后备人员就没有必要。 在风险缓解和风险监控措施中，该当留意抓主要风险。阅历证明，整个软件风险的80%，可以由仅仅20% 的已标识出的风险来阐明。在早期进展风险排序，可以协助工程管理者识别出这20% 的主要风险。其他一些已标识出的风险虽然曾经评价、预测过，但可以不纳入RMMM方案之中。第15章 软件工程风险管理 15.5 RMMM 计计 划划 风险管理战略可以包含在软件工程开发方案中，也可以建立一个独立的风险缓解、监控和管理方案(RMMM方案)。RMMM方案将一切的风险分析任务文档化，并作为整个工程方案中的一部分来运用。RMMM方案的大纲如下：1. 引言1.1 文档的范围和目的1.2 主要风险综述1.3 责任划分A. 管理者B. 技术人员第15章 软件工程风险管理 2. 工程风险表2.1 中止线以上的一切风险的描画2.2 影响概率及影响的要素3. 风险缓解、监控和管理3.1 风险1缓解第15章 软件工程风险管理 3.n 风险nA. 缓解. 普通战略. 缓解风险