单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,北京赛迪网信息技术有限公司,软件工程风险管理,1,本章内容提要,软件项目风险管理概述,合同管理概述,7.1,风险识别,7.2,风险评估,7.3,风险,计划,7.4,风险控制与管理,7.5,案例分析,7.6,本章小结,7.7,复习思考题,7.8,2,7.1 软件工程风险管理概述,风险定义与分类,美国软件工程研究所将风险定义为损失的可能性。风险同人们有目的的活动有关，同未来的活动有关，同人们变化的行为方式有关。风险具有两大属性：可能性和损失，可能性是风险发生的概率，损失是指预期与后果之间的差异，我们用可能性(Likelihood)和损失(Loss)的乘积来记录风险损失。风险的根源在于事物的不确定性，虽然无法防止不确定性，但是可以通过适当的方法对其进行控制与管理。,从范围角度上看，风险主要分为下述三种类型：工程风险、技术风险和商业风险。,软件风险是有关软件工程、软件开发过程和软件产品损失的可能性。软件风险又可区分为软件工程风险、软件过程风险和软件产品风险。,3,软件工程风险管理概述,风险管理,风险管理是指在工程进行过程中不断对风险进行识别、评估，制定策略，监控风险的过程。通过风险识别、风险分析和风险评价去认识工程的风险，并以此为基础合理地使用各种风险应对措施、管理方法、技术和手段对工程的风险进行有效的控制，妥善处理风险事件造成的不利后果，以最小的本钱保证工程总体目标的实现。风险管理可以分为四个层次：,危机管理：是在风险已经造成麻烦后才着手处理它们。,风险缓解：事先制定好风险发生后的补救措施，但不制定任何的防范措施。,着力预防：将风险识别与风险防范作为软件工程的一局部加以规划和执行。,消灭根源：识别和消灭可能产生风险的根源。,风险管理策略有两种：救火模式和主动模式。,4,软件工程风险管理概述,风险管理的意义,工程实施风险管理的意义可归纳如下：,通过风险分析，可加深对工程和风险的认识和理解，澄清各个方案的利弊，了解风险对工程的影响，以便减少或分散风险。,为以后的规划与设计工作提供反应，以便采取措施防止与防止风险损失。,通过风险管理可以使决策更科学，从总体上减少工程风险，保证工程的实现。,可推开工程管理层和工程组织积累风险资料，以便改进将来的工程管理。,5,本章内容提要,软件项目风险管理概述,合同管理概述,7.1,风险识别,7.2,风险评估,7.3,风险,计划,7.4,风险控制与管理,7.5,案例分析,7.6,本章小结,7.7,复习思考题,7.8,6,7.2,风险识别,风险识别过程,风险识别 或称风险辨识，是寻找可能影响工程的风险以及确认风险特性的过程。风险识别的目标是：辨识工程面临的风险，揭示风险和风险来源，以文档及数据库的形式记录风险。,风险识别的输入与输出 输入可能是工程的WBS、工作的陈述（Statement Of Work，SOW）、工程相关信息、工程方案假设、历史工程数据，其他工程经验文件、评审报告、公司目标等。风险识别的输出是风险列表。,包括以下活动 风险识别方法确实定；风险定义及分类；风险文档编写。,7,风险识别,风险识别的方法,风险条目检查表,风险条目检查表是最常用也是比较简单的风险识别方法，它是利用一组提问来帮助管理者了解工程在各方面有哪些风险。,在风险条目检查表中，列出了所有可能的与每一个风险因素有关的提问，使得风险管理者集中来识别常见的、的和可预测的风险(如产品规模风险、依赖性风险、需求风险、管理风险及技术风险等)。,风险条目检查表一般根据风险要素进行编写，包括工程的环境、管理层的重视度、技术情况以及内部因素(如团队成员的技能或技能缺陷等)。,8,风险识别,德尔菲（Delphi）法,德尔菲方法又称专家调查法，它起源于20世纪40年代末期，最初是美国兰德公司首先使用，很快就在世界上盛行起来，目前此法的应用已普及经济、社会、工程技术等各领域。,我们在进行本钱估算的时候也用到这种方法。用德尔菲方法进行工程风险识别的过程，是由工程风险小组选定与该工程有关的领域专家，并与这些适当数量的专家建立直接的函询联系，通过函询收集专家意见，然后加以综合整理，再匿名反应给各位专家，再次征询意见。这样反复经过四至五轮，逐步使专家的意见趋向一致，作为最后识别的根据。,9,风险识别,情景分析法,情景分析法是根据工程开展趋势的多样性，通过对系统内外相关问题的系统分析，设计出多种可能的未来前景，然后用类似于撰写电影剧本的手法，对系统开展态势做出自始至终的情景和画面的描述。,当一个工程持续的时间较长时，往往要考虑各种技术、经济和社会因素的影响，对这种工程进行风险预测和识别，就可用情景分析法来预测和识别其关键风险因素及其影响程度。,会议法,定期的工程组会议，如工程转折点或重要变更时举行的会议，工程月、季度总结会，工程专家会议都适宜于谈论风险信息，将风险讨论列为会议议题。,10,本章内容提要,软件项目风险管理概述,合同管理概述,7.1,风险识别,7.2,风险评估,7.3,风险,计划,7.4,风险控制与管理,7.5,案例分析,7.6,本章小结,7.7,复习思考题,7.8,11,7.3,风险评估,风险评估过程,风险评估又称风险预测，就是对识别出的风险做进一步分析，对风险发生的概率进行估计和评价，对风险后果的严重程度进行估计和评价，对风险影响范围进行估计和评价，以及对于风险发生时间进行估计和评价。,风险评估可采用定性风险评估和定量风险评估来进行。,12,风险评估,风险评估过程如下,确定风险类别,确定风险驱动因素,判定风险来源,定义风险度量准则,预测风险影响,评估风险,对风险进行排序,将风险分析结果归档,13,风险评估,风险评估的方法,定性风险评估,定性风险评估主要是针对风险概率及后果进行定性的评估。,例如采用历史资料法、概率分布法、风险后果估计法等。历史资料法主要是应用历史数据进行评估的方法，通过同类历史工程的风险发生情况，进行本工程的估算。,14,风险评估,定量风险评估,定量风险评估是一种广泛使用的管理决策支持技术。一般，在定性风险分析之后就可以进行定量风险分析。,定量风险分析过程的目标是量化分析每一个风险的概率及其对工程目标造成的后果，也分析工程总体风险的程度。定量风险评估可以包括以下方法：,访谈,盈亏平衡分析,决策树分析,模拟法,15,本章内容提要,软件项目风险管理概述,合同管理概述,7.1,风险识别,7.2,风险评估,7.3,风险,计划,7.4,风险控制与管理,7.5,案例分析,7.6,本章小结,7.7,复习思考题,7.8,16,7.4 风险方案,风险方案,针对风险分析的结果，为提高实现工程目标的时机并降低风险的负面影响而制定风险应对策略和应对措施的过程，即通过制定一系列的行动和策略来对付、减少以至于消灭风险事件。,降低风险的主要策略 回避风险、转移风险、损失控制以及自留风险。,风险方案的结果 工程风险方案或风险管理方案。风险方案的应该提供一个风险分析表，包括：工程风险的来源、类型，工程风险发生的可能时间、范围，工程风险事件带来的损失，以及工程风险可能影响的范围等。,17,本章内容提要,软件项目风险管理概述,合同管理概述,7.1,风险识别,7.2,风险评估,7.3,风险,计划,7.4,风险控制与管理,7.5,案例分析,7.6,本章小结,7.7,复习思考题,7.8,18,7.5,风险控制与管理,风险控制,通过对风险的规划和对工程全过程的控制，保证风险管理能到达预期的目标。,风险控制是工程实施过程的一个重要工作，其目的是核对风险管理的策略和实施的实际效果是否与预见相同，同时获取反应信息，改善风险方案和管理。,风险管理描述的是整个工程生存期中风险识别、风险评估、风险规划和风险控制是如何架构和执行的。在工程的进行过程中，需要不断地进行风险控制。,19,本章内容提要,软件项目风险管理概述,合同管理概述,7.1,风险识别,7.2,风险评估,7.3,风险,计划,7.4,风险控制与管理,7.5,案例分析,7.6,本章小结,7.7,复习思考题,7.8,20,7.6,案例分析,以一个教育管理系统工程为例。某教育管理系统工程是一个基于J2EE技术的Web应用工程。它主要为个公司或者一个部门的所有员工提供教育培训的管理。这个工程的需求来自一家大型公司，我们要在规定期限内提交产品，并保证软件的质量。这里我们将探讨软件工程风险管理等内容在软件工程管理中的具体应用，总结出一些有价值的软件工程管理经验，为以后在软件工程中实施工程管理提供了有益的借鉴。教育管理系统工程工程被划分成多个较小的模块或单元，分配给工程的各个小组的成员，每个小组成员承担一个或几个任务。首先是子系统和模块的分解，子系统和模块的分解着重于功能，本系统的分解，依据需求所要求的三个角色的不同操作进行划分。系统被划分员工操作子系统、部门领导管理子系统以及系统管理员子系统这样三个子系统。然后，根据功能，将各个子系统又划分成几个模块。整个教育管理系统的功能划分如图7-1所示。,21,案例分析,22,案例分析,由于风险是在工程开始之后才开始对工程的开发起负面的影响，所以风险分析的缺乏，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，根本能够对工程的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是防止损失的重要环节。下面主要关注软件开发中的主要风险，但是这只是工程风险中的一局部，在资金、预算、合同等方面都存在风险。,23,案例分析,工程过程中在几乎每个阶段都会出现风险。因此，正确评估每个阶段可能的风险是保证工程按时按质完成的重要环节。软件在需求分析阶段、设计阶段、实现阶段以及测试维护阶段等，会出现不同的风险。,需求分析阶段的风险,软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方的引导才能保证需求的完整，再以书面的形式形成 用户需求这一重要的文档。需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级级地放大，因此本阶段的风险最大。,24,案例分析,设计阶段的风险,设计的主要目的在于软件的功能正确的反映了需求。可见需求的不完整和对需求分析的不完整和错误，在设计阶段被成倍地放大。设计阶段的主要任务是完成系统体系结构的定义，使之能够完成需求阶段的即定目标;另一方面也是检验需求的一致性和需求分析的完整性和正确性。,设计本身的风险主要来自于系统分析人员。分析人员在设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护本钱的激增。,设计阶段蕴涵的另一种风险来自于设计文档。文档的不健全不仅会造成实现阶段的困难，更会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本升级，甚至是发现的简单错误都无从更正。,25,案例分析,开发测试阶段的风险,软件的实现从某种意义上讲是软件代码的生产。原代码本身也是文档的一局部，同时它又是将来运行于计算机系统之上的实体。源代码书写的标准性，可读性是该阶段的主要风险来源。标准的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到最低限度，从而减小了系统整合的风险。,维护阶段的风险,从软件工程的角度看，软件维护费用约占总费用的 55%-70%，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断开展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。,26,案例分析,在软件系统运营期间，主要的风险源自于技术支持体系的无效运转。科学的方法是有一支客户支持队伍不断收集运行中发现的问题，并将解决问题的方法传授给软件系统的所有使用者。,体系结构方面的风险,本工程采用J2EE技术和三层结构，在技术的成熟度上来说，不存在风险。但是，在实现上，对开发人员的技术要求，以及在实现良好的软件