第15章--软件工程风险管理-普通高等院校计算机类专业系列教材-软件工程教学.ppt

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