第5章-软件项目风险管理

第五章软件项目风险管理第一页，共八十九页。案例场景模拟(1/4)项目已成功实施1个月，某天项目组成员小谢突然告诉项目负责人，他已办理好了去德国的签证，2周后他会辞职离开公司前往德国留学

（人员）小谢的离开显然将会影响项目组的正常运作，影响项目的进度，为此将会给项目的实施带来损失可以想象，2周以后小谢的离开将会带来一系列问题：谁来接替小谢的工作？在此之前谁来负责交接小谢的工作？如何尽可能的避免由此给项目组带来的损失(包括进度损失和工作损失等)尽管还没发生，但必须考虑如何避免问题的发生，以及一旦发生后该采取得措施，以便将损失减少到最少第二页，共八十九页。案例场景模拟(2/4)按照软件开发计划，需求分析应在12月31日前完成，然而在软件项目实施过程中项目经理发现，由于原先对工作量估算过于乐观，需求分析在12月31日之前已经不可能完成

（计划）显然，原先计划制定的不科学和不准确，导致了实施过程中进度难以控制，如果强行按照计划来执行显然是不可行的，为此，必须对计划重新进行分析和调整第三页，共八十九页。案例场景模拟(3/4)在软件设计阶段，软件设计负责人发现，用户需求中的某项需求(例如，将已有word文档的内容显示在Web页面上)至今尚未找到解决的技术途径

（技术）显然，该问题将直接影响软件项目的后续开发工作，影响到软件项目能否成功完成第四页，共八十九页。案例场景模拟(4/4)在需求分析过程中，软件设计负责人带领的需求分析小组和用户在进行交流的过程中发生了矛盾，出现了争吵，用户方说将不再配合需求分析小组的工作，而且他们确实没有配合开发方的工作

（合作）显然，开发方和用户方出现这种状况是双方没有想到的这种状况延续下去必将对软件项目的实施产生影响，影响软件项目的进度，甚至会导致项目失败第五页，共八十九页。案例启示：风险在项目实施过程中大量存在软件风险形式多样软件风险事先难以确定软件风险会对软件项目的实施产生不良影响如果不对风险进行良好的管理，项目就很难保证按照计划、在成本和进度范围内，开发出高质量的软件产品，甚至会导致项目失败第六页，共八十九页。5.1概述5.1.1风险5.1.2软件风险5.1.3软件项目风险管理5.1.4软件项目风险管理的意义第七页，共八十九页。5.1.1风险卡内基.梅隆大学的软件工程研究所SEI：

风险是损失的可能性Webster’sDictionary：

风险是遭受损失、伤害、破坏的可能性。风险的根源是不利的情况(或损失)发生的不确定性，即不期望发生事件的客观不确定性。风险是在给定情况下和特定时间内，那些可能发生的结果之间的差异，差异越大则风险越大。第八页，共八十九页。5.1.1风险风险具有两大属性：可能性：风险发生的概率损失：指预期与后果之间的差异风险的损失=可能性×损失第九页，共八十九页。项目风险函数表达式项目风险具有不同的组成要素，如项目不希望发生的事件、事件发生的概率、事件的后果等。每个项目的风险可定义为不确定性和后果的函数：风险=f（事件，不确定性，后果)风险=f(事故，安全措施)第十页，共八十九页。5.1.2软件风险什么是软件风险？使软件项目的实施受到影响和损失、甚至导致失败的、可能会发生的事件例如，人员的临时流失，计划过于乐观，设计的低劣软件风险的特点事先难以确定带来损失，影响项目实施，甚至会导致项目失败第十一页，共八十九页。5.1.2软件风险软件风险由管理过程风险和技术过程风险组成，又可分为：1、软件项目风险2、软件过程风险3、软件产品风险第十二页，共八十九页。5.1.3软件风险管理什么是软件风险管理？软件风险管理与项目管理的关系软件风险管理的主要内容第十三页，共八十九页。什么是软件风险管理？(1/3)面对软件风险，一般有两类方法：被动救火型主动防火型软件风险管理属于主动防火型方法第十四页，共八十九页。什么是软件风险管理？(2/3)软件风险管理是对影响软件项目、过程或产品的风险进行估计和控制的实践过程。定义目标。从目标逆向思维可发现软件风险。根据不确定性、损失和时间来描述风险。第十五页，共八十九页。风险管理的涵义根据美国项目管理学会（PMI）的报告，风险管理有三个涵义：系统识别和评估风险因素的形式化过程。识别和控制能够引起不希望的变化的潜在领域和事件的形式、系统的方法。在项目期间识别、分析风险因素，采取必要对策的决策科学和决策艺术的结合。第十六页，共八十九页。什么是软件风险管理？(3/3)在风险影响软件项目成功实施前，对它进行识别和处理，并预防和消除风险的发生。识别风险(会有哪些风险？)预防和消除风险(最好别让风险发生)制定风险发生后的处理措施(万一发生该怎么办？)第十七页，共八十九页。软件风险管理未来是我们所关心的——什么样的风险会导致软件项目彻底失败呢？改变也是我们所关心的——用户需求、开发技术、目标计算机、以及所有其他与项目相关的因素的改变将会对按时交付和总体成功产生什么影响呢？最后，我们必须抓住机会——我们应该采用什么方法及工具？需要多少人员参与工作？对质量的要求要达到什么程度才是“足够的”？第十八页，共八十九页。软件风险管理过程风险管理过程就是从一堆模糊不清的问题、担心和未知开始，逐步将这些不确定因素加以辨识、分析，并进而转化为可接受的风险。

风险管理过程是一个持续不断的过程，贯穿于项目周期的始终。第十九页，共八十九页。软件风险管理与项目管理的关系软件风险管理是整个项目管理的一部分。风险管理与项目管理的关系可归纳如下：从项目的成本、时间和质量目标来看，风险管理与项目管理的目标一致。从项目管理的计划职能来看，风险管理为项目计划的制定提供了依据。从项目的成本管理职能来看，项目风险管理通过风险分析，指出有哪些可能的计划外费用，并估计它的多少。从项目实施过程来看，许多风险都在项目实施过程中由潜在变为现实。定出风险反应计划。第二十页，共八十九页。软件风险管理的主要内容第二十一页，共八十九页。项目风险管理内容RiskManagementPlanning－风险管理计划RiskIdentification－风险识别QualitativeRiskAnalysis－风险定性分析QuantitativeRiskAnalysis－风险定量分析RiskResponsePlanning－风险应对计划Riskmonitoringandcontrol－风险监控第二十二页，共八十九页。5.1.4软件项目风险管理的意义KPMG即毕马威，著名的"BIGFOUR"——国际四大会计师事务所之一（其他三大事务所为PwC普华永道，DTT德勤和E&Y安永）的一项调查指出55%失控的项目是没有进行了风险管理；38%的失控项目作了一些,但是其中的一半在项目进行后就没有使用风险监督；剩余7%情况不明。项目实施风险管理的意义，见P141的8点第二十三页，共八十九页。5.2风险识别第二十四页，共八十九页。5.2风险识别风险识别，或称风险辨识，是寻找可能影响项目的风险以及确认风险特性的过程。风险识别活动的参加人员一般包括：项目组成员、风险管理人员、学科专家（组织内）、客户、项目的其他管理人员以及外部专家等。风险识别的目标是：辨识项目面临的风险，揭示风险和风险来源，以文档及数据库的形式记录风险。第二十五页，共八十九页。5.2.1风险识别依据项目计划历史与经验信息外部制度约束风险项目内部的不确定性第二十六页，共八十九页。5.2.2常见软件风险风险的类别计划编制组织和管理开发环境最终用户客户承包商需求产品外部环境人员设计和实现过程第二十七页，共八十九页。政府客户供货商分包商潜在的客户最终用户项目经理团队发起人竞争者组织集中管理同事其他的项目自然环境人员时间资金技术其他要素项目风险来源第二十八页，共八十九页。计划编制风险计划、资源和产品的定义完全由客户或上层领导决定，忽略了项目组的意见，并且这些决定不完全一致计划忽略了必要的任务和活动计划不切实际计划基于特定小组成员，而这样的小组成员根本得不到产品规模估算过于乐观工作量估算过于乐观进度的压力造成生产率的下降目标日期提前，但没有相应地调整产品范围和可用资源一个关键任务的延迟导致其他相关任务的连锁反应……第二十九页，共八十九页。组织和管理风险缺乏强有力、有凝聚力的领导(项目组、企业)解雇员工导致项目小组能力下降削减预算打乱项目计划仅由管理层和市场人员进行技术决策，导致进度延长低效的项目组组织结构降低生产率管理层审查/决策的周期比预期时间长管理层作出了打击项目组积极性的决定非技术的第三方的工作比预期要长(如,采购硬件设备)计划性太差，无法适应期望的开发速度项目计划由于压力而放弃，导致开发混乱管理方面的英雄主义，忽视客观确切的状态报告，降低发现和改正问题的能力第三十页，共八十九页。开发环境风险设施不能及时到位设施到位，但不配套开发工具未能及时到位开发工具不如期望的那样有效，开发人员需要更多的时间，或者更换工具开发工具的学习期比预期的要长开发工具的选择不是基于技术需求，不能提供计划要求的功能第三十一页，共八十九页。最终用户风险最终用户坚持新的需求最终用户对最后交付的产品不满意，要求重新设计和重做最终用户不买进项目产品，无法提供后续支持最终用户的意见未被采纳，造成产品最终无法满足用户要求第三十二页，共八十九页。组织和管理风险缺乏强有力、有凝聚力的领导(项目组、企业)解雇员工导致项目小组能力下降削减预算打乱项目计划仅由管理层和市场人员进行技术决策，导致进度延长低效的项目组组织结构降低生产率管理层审查/决策的周期比预期时间长管理层作出了打击项目组积极性的决定非技术的第三方的工作比预期要长(如,采购硬件设备)计划性太差，无法适应期望的开发速度项目计划由于压力而放弃，导致开发混乱管理方面的英雄主义，忽视客观确切的状态报告，降低发现和改正问题的能力第三十三页，共八十九页。开发环境风险设施不能及时到位设施到位，但不配套开发工具未能及时到位开发工具不如期望的那样有效，开发人员需要更多的时间，或者更换工具开发工具的学习期比预期的要长开发工具的选择不是基于技术需求，不能提供计划要求的功能第三十四页，共八十九页。最终用户风险最终用户坚持新的需求最终用户对最后交付的产品不满意，要求重新设计和重做最终用户不买进项目产品，无法提供后续支持最终用户的意见未被采纳，造成产品最终无法满足用户要求第三十五页，共八十九页。客户风险(1/2)客户坚持新的需求客户对规划、原型和规格的审核/决策超出预期客户没有参与规划、原型和规格的审核，导致需求不稳定，以及长时间的变更客户答复的时间比预期的要长客户坚持技术决策而导致计划延长客户对开发进度管理过细，导致实际进度变慢客户提供的组件无法与开发的产品匹配，导致需要额外的设计和集成工作客户提供的组件质量欠佳，导致额外的测试、设计或者功能不完善第三十六页，共八十九页。客户风险(2/2)客户要求的支持工具与环境不兼容，性能差或者不完善，导致生产率降低客户不接受交付的软件，尽管它满足了所有的规格客户期望的开发速度是开发人员所无法达到的第三十七页，共八十九页。承包商风险承包商没有按照承诺交付产品承包商提供的产品质量低下，必须花时间改进质量承包商提供的产品性能达不到要求第三十八页，共八十九页。需求风险需求已经成为项目基准，但仍在变化需求定义欠佳：不清晰、不准确、不一致增加额外的需求第三十九页，共八十九页。产品风险错误发生率高的模块，需要更多的时间对它进行测试、设计和实现矫正质量低下的不可接受的产品需要更多的时间对它进行测试、设计和实现由于功能错误，导致需要重新进行设计和实现开发额外不需要的功能延长了进度要满足产品规模和速度要求，需要更多的时间严格要求与现有系统兼容，需要更多的时间要求软件重用，需要更多的时间……第四十页，共八十九页。外部环境风险产品依赖政府规章，而规章的改变不可预期产品依赖草拟中的技术标准，而最后的标准不可预期第四十一页，共八十九页。人员风险(1/3)招聘人员所需的时间比预期要长作为人员参与工作的先决条件(如培训、其他项目的完成等)不能按时完成开发人员与管理层关系不佳导致决策迟缓、影响全局项目组成员没有全身心地投入到项目中，因而无法达到所需的产品功能和性能需求缺乏激励措施、士气低下，降低生产能力缺乏必要的规范，增加工作失误，重复工作，降低工作质量缺乏工作基础(语言、经验、工具等)项目结束前，项目组成员离开项目组第四十二页，共八十九页。人员风险(2/3)项目后期，加入新的开发人员，额外的培训和沟通降低了项目组成员的开发效率项目组成员不能有效的在一起工作由于项目组成员之间的冲突，导致沟通不畅，设计欠佳，接口错误和额外重复的工作有问题的项目组成员没有调离项目组，影响其他成员的积极性项目组的最佳人选没有加入项目组，或者加入项目组但没有合理使用关键任务只能兼职参与项目人员不足第四十三页，共八十九页。人员风险(3/3)任务的分配和人员的技能不匹配人员工作的进展比预期的要慢项目管理人员怠工导致计划和进度失效技术人员怠工导致工作遗漏、质量低下，工作需要重做第四十四页，共八十九页。设计和实现风险设计过于简单，考虑不仔细、不全面，导致重新设计和实现设计过于复杂，导致一些不必要的工作，影响效率设计质量低下，导致重新设计和实现使用不熟悉的方法，导致需要额外的培训时间产品使用低级语言编写，导致效率较低分别开发的模块无法有效集成，需要重新设计和实现第四十五页，共八十九页。过程风险跟踪不准确，导致无法预知项目进展是否落后于计划前期的质量保证行为不真实，导致后期的重复工作质量跟踪不准确，导致无法得知影响进度的质量问题不能有效遵循标准，导致沟通不足，质量问题和重复工作风险管理粗心，导致没有发现重大的项目风险……第四十六页，共八十九页。例子:风险列表第四十七页，共八十九页。各阶段典型风险事件48启动阶段计划阶段执行阶段收尾阶段缺少相应专业的专家对需求界定不清没有做可行性研究目标不清没有风险管理计划仓促计划缺少管理层支持职能界定差项目队伍缺乏经验人员技能不够材料短缺人员误工天气影响范围改变项目进度改变环境要求没有适当的控制体系产品或服务质量差客户不能接受成果现金流出现问题风险发生最高时期风险影响最高时期机会和风险得失量时间各阶段典型的风险事件风险价值第四十八页，共八十九页。5.2.3风险识别过程风险分析过程是将项目的不确定性转变为风险陈述的过程。它包括以下活动：进行风险评估系统地识别风险风险定义及分类确定风险驱动因素将风险编写为文档P144第四十九页，共八十九页。5.2.4风险识别方法与技术有很多有效的方法，主要有：核对清单头脑风暴法Delphi法会议法匿名风险报告机制…第五十页，共八十九页。1.核对清单可以采用SEI推荐的软件风险分类系统或项目工作细分结构WBS作为核对清单。SEI软件风险分类系统是一个结构化的核对清单。SEI软件风险分类系统将风险分为产品工程、开发环境和项目约束三类。每类又分若干元素，每个元素通过其属性来体现特征。SEI软件风险分类系统如P145表5.1所示:第五十一页，共八十九页。第五十二页，共八十九页。WBS模型项目工作细分结构WBS提供了识别具体项目风险的框架。每一个项目元素都以支持项目开发活动（计划、执行、控制等）的细节方式被定义。WBS减少了项目的灰度，使项目结构清晰。第五十三页，共八十九页。WBS模型第五十四页，共八十九页。2.头脑风暴法召集项目组全体会议，进行关于项目风险的自由讨论，项目组成员在主持人的引导下完全自由地发言，不受限制，产生关于项目风险的概念。头脑风暴法是一种搜集项目风险的常用方法。第五十五页，共八十九页。3.Delphi法Delphi法又称反馈匿名函询法，本质上是一种达到关于一个科目的专家一致意见的方法。这个“科目”可以是软件成本，软件项目风险等。任命专家→专家匿名参加→发调查表给专家→专家填写→由调查人员将专家意见汇总整理→再返回起点。这个方法体现了民主性。第五十六页，共八十九页。4.会议法定期的项目组会议，如项目转折点或重要变更时举行的会议、项目月及季度总结会项目专家会议都适宜于谈论风险信息，将风险讨论列为会议议题。第五十七页，共八十九页。5.SWOT分析法SWOT技术（Strengths,Weankness,Opportunities,Threats)是分析项目内部优势与弱势和项目外部机会与威胁综合分析的代名词。主要对项目的优势和劣势、机会与威胁等各方面，从多角度对项目风险进行识别。第五十八页，共八十九页。SWOT分析法内部因素外部因素SWOT第五十九页，共八十九页。示例积极消极内部外部第六十页，共八十九页。6.匿名风险报告机制向管理层或组内报告好的消息很少会出现问题，但报告项目的坏消息则不然。必须有一个匿名的风险交流渠道。第六十一页，共八十九页。5.3风险分析第六十二页，共八十九页。5.3风险分析风险分析是人们应用风险分析工具,加深对风险的认识与理解，使风险及风险背景明晰化，从而为有效地管理风险提供基础。风险分析活动的过程目标包括：提炼风险背景，确定风险来源，确定行动时间框架，确定前10项首要风险名单等。第六十三页，共八十九页。5.3.1风险分析过程定义风险度量准则预测风险景响评估风险风险排序制订风险计划第六十四页，共八十九页。5.3.1风险分析过程---1.定义风险度量准则定义风险度量准则风险度量准则是按照重要性对风险进行排序的最基本依据。风险度量准则包括可能性、后果和行动时间框架。第六十五页，共八十九页。5.3.1风险分析过程----1.定义风险度量准则（1）可能性定性度量包括：极低、低、中、高、极高，也可简单定义为：低、中、高。（2）后果后果反映了风险对项目目标的影响程度。（3）行动时间框架行动时间框架是指采取有效措施规避风险的时限。第六十六页，共八十九页。5.3.1风险分析过程----2.预测风险影响我们用风险发生的可能性与风险后果的乘积来度量风险的影响。

风险影响（RE）=风险发生的可能性（P）*风险后果（C）可能性被定义为大于0，小于1。后果从1到10表示风险对成本、进度和技术目标的影响。两者的乘积可能是经济的损失，也可能是时间的损失等。第六十七页，共八十九页。5.3.1风险分析过程---3.评估风险风险影响和行动时间框架决定了风险的相对严重程度，见P148表5.4。风险严重程度有利于区分当前风险的优先级别。随着时间的推移，风险严重程度发生变化，有利于提供当前项目面临的重点问题。第六十八页，共八十九页。5.3.1风险分析过程----4.风险排序依据评估准确风险排序，可保证高风险影响和短行动时间框架的风险能被最先处理。右表是一个非常生要的风险报告形式，在实际项目中可以使用。第六十九页，共八十九页。5.3.1风险分析过程----5.制定风险计划风险计划是实施风险应对措施的依据与前提。风险计划要包括：确定风险设想选择风险应对途径其中，常用作选择风险应对途径的取舍标准是风险倍率和风险多样化。风险多样化通过分散风险来减少风险。项目不要过分依赖一种方法、一种工具、一个人或一个厂商等。设定风险阈值编写风险计划第七十页，共八十九页。风险倍率风险倍率是一条风险应对法则，它通过减少风险影响来减少风险。风险应对成本是实施风险行动计划的成本。倍率的概仿有助于确定获得最高回报的行动。主要的风险倍率多存在于软件生命周期的早期。第七十一页，共八十九页。5.3.2风险分析技巧与工具因果关系分析法决策分析法：用于构建决策，用决策模型来代表真实世界里的问题。决策模型的元素包括决策、不确定事件以及结果的价值。差距分析法确定变量的差距。描述了人们意识到的重要性和实际执行情况的差距，从而确定风险管理实践是否需要改进。Pareto帕雷托分析法只要找出项目风险的20%关键致因，就可以解决项目的大部分问题敏感度分析法通过改变每一个输入变量，保持其它变量，来确定厝型对输入变量的敏感度。第七十二页，共八十九页。因果关系分析法—鱼骨图第七十三页，共八十九页。5.3.3风险分析的成果经过风险分析，可以得到一个按优先等级排序的风险列表。第七十四页，共八十九页。5.4风险跟踪与应对第七十五页，共八十九页。风险控制风险管理计划风险化解风险监控第七十六页，共八十九页。风险监控(1/2)检查风险的化解程度及其变化(概率、损失)风险监控的方式监控和跟踪重要的(前10个)风险，记录风险危险度的变化以及风险化解的进展中间审查，在每个里程碑后进行小规模的走查任命风险官员(适合于大项目)，警告项目风险，防止项目经理和开发人员忽略计划中的风险管理第七十七页，共八十九页。风险管理计划(2/2)例子，小谢将在项目实施过程中离开公司**项目组的小谢项目组成员小谢由于出国离开公司小谢可能会在6月1日前后出国为了进一步学习和深造和小谢协商能否在项目结束之后(大约7月中旬)离开如果离开，计划让小王接替他的工作，同时让小刘分担小王的一部分工作第七十八页，共八十九页。应对风险的基本措施规避。通过变更项目计划消除风险或风险的触发条件，使目标免受影响。转移。不能消除风险，而是将项目风险的结果连同应对的权利转移给第三方。弱化。将风险时间的概率或结果降低到一个可以接受的程度，其中降低发生的概率更为有效。接受。不改变项目计划，而考虑发生后如何应对第七十九页，共八十九页。风险应对模拟场景风险化解方式避免风险：推迟小谢的离开时间将风险从系统的一部分转移到另一部分：让客户来做消除发生风险的根源：加薪发布风险：不会突然和惊讶接受和控制风险：接受并提供处理计划，安排小