1、第18章 软件工程风险管理 LOGO软件工程风险管第18章 软件工程风险管理 第18章 软件工程风险管理18.1 软件风险软件风险18.2 风险识别风险识别18.3 风险预测风险预测 18.4 风险缓解、监控与管理风险缓解、监控与管理18.5 RMMM计划计划 18.6 小结小结 第18章 软件工程风险管理 18.1 软软 件件 风风 险险 对软件风险的严格定义还存在着很多争议，但对于在风险中包含了两个特性这一点上已经达成了共识。(1)不确定性：风险可能发生也可能不发生，即不存在发生概率为100%的风险(100%会发生的风险实际上是加在项目上的约束)。(2)危害性：一旦风险变成了现实，就会产生
2、恶性后果或损失。第18章 软件工程风险管理 进行风险分析时，重要的是量化不确定性的程度和与每个风险相关的损失程度。为了达到此目的，必须考虑不同类型的风险。项目风险威胁到项目计划。也就是说，如果项目风险变成现实，可能会拖延项目进度且增加项目的成本。项目风险是指潜在的预算、进度、人力(工作人员及组织)、资源、客户及需求等方面的问题以及它们对软件项目的影响。项目的复杂性、规模及结构不确定性也被定义为项目(估算)风险因素。第18章 软件工程风险管理 技术风险威胁到要开发软件的质量和交付时间。如果技术风险变成现实，则开发工作可能变得很困难或者根本不可能。技术风险是指潜在的设计、实现、接口、验证和维护等方
3、面的问题。此外，需求规约的二义性，技术的不确定性，陈旧的技术及“先进的”技术也是风险因素。技术风险的发生是因为问题比我们所设想的更难以解决。第18章 软件工程风险管理 商业风险威胁到要开发的软件的生存能力。商业风险常常会危害项目或产品。五个主要的商业风险是：市场风险：开发了一个没有人真正需要的优秀产品或系统。策略风险：开发的产品不再符合公司的整体商业策略。营销风险：生产了一个销售部门不知道如何去卖的产品。管理风险：由于重点的转移或人员的变动，失去了高级管理层的支持。预算风险：没有得到预算或人力上的保证。第18章 软件工程风险管理 另一种分类方式将风险分为三类：已知风险：通过仔细评估项目计划，开
4、发项目的商业及技术环境以及其他可靠的消息来源(如不现实的交付时间，恶劣的开发环境，没有需求或者软件范围文档)之后可以发现的那些风险。可预测风险：能够从过去项目的经验中推断出来(如人员调整、与客户无法沟通、开发人员精力分散)的风险。不可预测风险：可能或有时真会出现的风险，但事先很难识别出来。第18章 软件工程风险管理 18.2 风风 险险 识识 别别 风险识别就是要识别属于前述类型中的某些特定的风险。方法是利用一组问卷来帮助项目计划人员了解在项目和技术方面有哪些风险。Boehm建议使用一个“风险项目检查表”列出所有可能的与每一个风险因素有关的提问。例如，管理人员或计划人员可以通过回答下列问题得到
5、对有关人力风险的认识：可用人员是最优秀的吗？按照技能对人员进行了合理组合吗？人力足够吗？第18章 软件工程风险管理 整个项目开发期间人员如何投入？有多少人不是全工时投入本项目的工作？人们对于手头上的工作是否有正确的目标？项目成员是否接受过必要的培训？项目的成员是否是稳定的和连续的？第18章 软件工程风险管理 对于这些提问，通过判定分析或假设分析，给出确定的回答，就可以帮助管理人员或计划人员估算风险的影响。当然，上面仅仅是针对人力资源风险有效的问题。同样地，我们也可以对其他类型的风险制定出必要的问题，利用和上述方法相同的手段，估算不同类别风险的影响。例如，针对技术风险的问题包括：该技术对你的组织
6、来说是新的吗？客户的需求是否需要创建新的算法或I/O技术？软件是否需要使用新的或未经证实的硬件接口？第18章 软件工程风险管理 待开发软件是否要和开发商提供的未经证实的软件接口？待开发软件是否要和其功能和性能均未在本领域中得到证实的数据库系统接口？产品的需求中是否包括要求采用特定的用户界面？产品的需求中是否要求开发某些程序构件，这些构件和你的组织从前开发过的构件完全不同？需求中是否要求使用新的分析、设计或测试方法？第18章 软件工程风险管理 需求中是否要求使用非传统的软件开发方法，如形式化方法，人工神经网络方法？需求中对产品性能的约束是否过分严格？客户能确定所要求的功能是“可行的”吗？如果对于
7、上列问题中任何一个问题的回答是肯定的，则需要进行进一步的调研来评估潜在的风险。第18章 软件工程风险管理 18.3 风风 险险 预预 测测 风险预测又称为风险估算。它试图从两个方面去评价每一个风险：其一是风险发生的可能性或概率；其二是如果风险发生了会造成的后果。风险预测活动要进行四项工作：(1)建立一个尺度，以反映风险发生的可能性(尺度可以是布尔值、定性的或定量的)。(2)描述风险的后果。(3)估算风险对项目和产品的影响。(4)标注风险整体预测的精确度以免产生误解。第18章 软件工程风险管理 18.3.1 建立风险表建立风险表表表18.1 风险预测表样本风险预测表样本风险描述风险类别发生概率可
8、能的影响RMMM规模估算可能非常低产品规模60%2 用户数量大大超过计划产品规模30%3 复用程度低于计划产品规模70%2最终用户抵制该系统商业风险40%3 交付期限紧缩商业风险50%2 第18章 软件工程风险管理 资金流失预算风险40%1 需求改变产品规模80%2 技术达不到预期效果技术风险30%1 缺少对于工具的培训人力风险80%3 人员缺乏经验人力风险30%2 人员流动频繁人力风险60%2 表表18.1 风险预测表样本风险预测表样本第18章 软件工程风险管理 在表18.1中，影响类别取值为1：灾难的；2：严重的；3：轻微的；4：可以忽略的。项目组将所有可能的风险都在第一列中列出，在第二列
9、上加以分类。发生概率经评估后取评估均值，将估计的影响程度填入第四列，然后按照发生概率和影响程度自高到低地对风险表进行第一次风险排序。管理者研究已经排序的风险表，定义一条中止线，一般来说，管理者对于中止线以上的风险会进行进一步的关注。其他的风险需要再次评估以完成第二次排序。第18章 软件工程风险管理 图18.1 风险和管理的考虑第18章 软件工程风险管理 风险表中所有在终止线以上的风险都应当进行管理。在表的最后一列包含有一个指针，指向为所有终止线以上的风险制定的风险缓解、监控和管理计划(RMMM计划，Risk Mitigation，Monitoring and Management Plan)。
10、第18章 软件工程风险管理 18.3.2 风险评估风险评估 建立一个三元组集合来进行风险评估：Ri，Li，Xi其中，Ri是风险，Li是风险出现的可能性，Xi是风险出现会造成的影响。在进行风险评估时，应当进一步检验在风险预测时得到的估计的准确性(影响及概率)，试图为已被发现的风险排出优先顺序，并开始考虑如何控制或避免可能发生的风险。第18章 软件工程风险管理 要使评估发生作用，必须定义一个风险参考水平值。对于大多数软件项目而言，前面所讨论的风险因素性能、成本、支持及进度也代表了风险参考水平值，即对于性能下降、成本超支、支持困难、进度延迟(或者它们的组合)都有一个水平值的要求。超出水平值就会导致项
11、目被迫终止。如果风险的组合所产生的问题引起一个或多个参考水平值被超过，则工作将会停止。在软件风险分析中，风险参考水平值存在一个点，称为参考点或临界点。在这个点上，决定继续进行某项目或者是终止它(问题太大了)都是可以接受的。图18.2中就表示了这种情况。如果风险组合产生的问题导致成本超支及进度延迟，则会有一个水平值，(即图中的曲线)，当超过它时会引起项目终止。第18章 软件工程风险管理 图18.2 风险参考水平曲线第18章 软件工程风险管理 实际上参考水平值很少能够表示成如图18.2所示的光滑曲线。在大多数情况下，它是一个区域，其中存在很多不确定性，这个区域可能是一个易变区域。在这些区域中想要做
12、出基于参考值组合的管理判断往往是非常困难的。因此，在作风险评估时，可以采用下面的步骤执行：(1)为项目定义风险参照水准。(2)尝试找出在每一个Ri，Li，Xi 和每一个参照水准之间的关系。(3)预测参照点组以定义一个终止区域，用一条曲线或一些易变动区域来界定。(4)努力预测复合的风险组合将如何形成一个参照水准。第18章 软件工程风险管理 18.4 风险缓解、监控与管理风险缓解、监控与管理 在这一步的工作中，所有的风险分析活动都只有一个目的，那就是辅助项目建立处理风险的策略。任何一种有效的策略都必须考虑三个问题：风险避免、风险监控、风险管理及意外事件计划。如果项目组对于风险采取主动策略，则最好的
13、方法是通过制定一个风险缓解计划并付诸实施，设法避免风险。图18.3所示为风险缓解与监控。第18章 软件工程风险管理 图18.3 风险缓解与监控第18章 软件工程风险管理 例如人员频繁流动是软件开发组织中的一个普遍存在的风险。将其标注为R0，基于以往的历史数据和管理经验，发生概率L0被估算为0.7，影响X0被预测为对于项目的成本和进度有极严重的影响。为了缓解这一风险，项目管理者可以采取如下的策略来降低人员流动：(1)预先与现有人员一同探讨一下人员流动的原因(如工作条件恶劣、低报酬、激烈的人才竞争)。(2)在项目开始之前，采取行动来缓解那些被识别出的、且在管理控制之下的原因。第18章 软件工程风险
14、管理 (3)一旦项目启动，假设人员会发生流动，并采取一些措施以保证当人员离开时工作的连续性。(4)对项目组进行良好的组织，使得每一个开发活动的信息能够被广泛地传播和交流。(5)定义文档的标准，并建立保证文档能够被及时、正确建立的机制。(6)对所有的工作进行详细的复审，保证不止一个人熟悉该项工作。(7)对每一个关键的技术人员都指定一个后备人员。第18章 软件工程风险管理 随着项目的进展，开始进行风险监控活动。项目管理者监控某些因素，这些因素可以提供风险是否正在变高或变低的指示。针对人员频繁流动的风险，应当监控下列因素：(1)项目组成员对于项目压力的一般态度。(2)项目组的凝聚力。(3)项目组成员
15、彼此之间的关系。(4)与报酬和利益相关的潜在问题。(5)在公司内和公司外工作的可能性。第18章 软件工程风险管理 除了监控上述因素之外，项目管理者还应当监控预设的风险缓解步骤的效力。例如，前述的一个风险缓解步骤中要求定义“定义文档的标准，并建立保证文档能够被及时、正确建立的机制”。如果有关键的人员离开了项目组，这就是一个保持工作连续性的机制。项目管理者应当仔细监控这些文档，以保证每一个文档内容正确，而且当新员工加入项目组时，能够利用已经建立并得到监控的文档为他们提供必要的信息。第18章 软件工程风险管理 如果风险缓解工作失败，风险已经发生，那么就要按照风险管理和意外事件处理计划(风险应对预案)
16、进行处理，减少风险带来的损失。假定项目进行过程中，有一些人宣布要离开，如果我们执行了缓解措施，那么就有后备人员可用，同时因为信息已经文档化，并且有关知识已经在项目组中广泛地进行了交流，后备人员能够很快地接手工作。此外，项目管理者还可以暂时重新将资源调整到那些人员充足的功能上去(并对项目进度作必要的调整)，从而使得新加入的人员能够“赶上进度”。同时，应当要求宣布要离开的人员停止工作，在最后一段时间里进入“知识与业务交接”模式。第18章 软件工程风险管理 应当注意的是，在防范风险的过程中是要花费成本的。应当在防范措施的成本和风险一旦发生的损失之间进行投入产出分析，以此确定要执行什么样的风险防范措施
17、。举例来说，为每个项目组成员都配备一名后备人员就没有必要。在风险缓解和风险监控措施中，应当注意抓主要风险。经验证明，整个软件风险的80%，可以由仅仅20%的已标识出的风险来说明。在早期进行风险排序，能够帮助项目管理者识别出这20%的主要风险。其他一些已标识出的风险虽然已经评估、预测过，但可以不纳入RMMM计划之中。第18章 软件工程风险管理 18.5 RMMM 计计 划划 风险管理策略可以包含在软件项目开发计划中，也可以建立一个独立的风险缓解、监控和管理计划(RMMM计划)。RMMM计划将所有的风险分析工作文档化，并作为整个项目计划中的一部分来使用。RMMM计划的大纲如下：1.引言1.1 文档
18、的范围和目的1.2 主要风险综述1.3 责任划分A.管理者B.技术人员第18章 软件工程风险管理 2.项目风险表2.1 中止线以上的所有风险的描述2.2 影响概率及影响的因素3.风险缓解、监控和管理3.1 风险1A.缓解第18章 软件工程风险管理 3.n 风险nA.缓解.一般策略.缓解风险的特定步骤B.监控.被监控的因素.监控方法C.管理.意外事件计划.特殊考虑4.RMMM计划的迭代时间安排表5.总结第18章 软件工程风险管理 一旦建立了RMMM计划且项目已经启动，则风险缓解及监控活动也就随之开始。正如前面讨论过的，风险缓解是一种“问题避免”活动；风险监控则是一种项目跟踪活动，它包括三个主要目
19、的：评估一个被预测的风险是否真正发生了；保证为风险而定义的缓解步骤被正确地实施；收集能够用于今后的风险分析的信息。在很多情况下，项目中发生的问题可以追溯到不止一个风险，所以风险监控的另一个任务就是试图在整个项目中确定问题的“起源”(什么风险引起了什么问题)。第18章 软件工程风险管理 18.6 小小 结结 当软件项目成功的期望值很高时，一般都会进行风险分析。过去这种分析一般是由项目管理者非正式地完成的。但是为了提高项目的成功率，我们认为，这项工作应当纳入制度化、规范化的工作范畴。成功的风险分析能够从更加平稳的项目过程，较高的跟踪和控制项目的能力等方面得到满意的回报。第18章 软件工程风险管理 风险预测表是进行风险预测的良好工具。使用“中止线”概念能够使我们将有限的精力与资源用来对付最危险的风险。而使用RMMM计划规范风险管理工作，将有助于使风险管理成为软件工程过程中的一项制度化的工作环节。风险分析是要花费资源和时间的。但是“知己知彼，百战不殆”的古训告诉我们，这样做是值得的，这里的“彼”指的就是风险。第18章 软件工程风险管理 第18章 软件工程风险管理 第18章 软件工程风险管理 第18章 软件工程风险管理 第18章 软件工程风险管理 第18章 软件工程风险管理 第18章 软件工程风险管理 第18章 软件工程风险管理*第18章 软件工程风险管理 PPT模板下载：
