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

1、1,第五章 软件项目风险管理,2,案例场景模拟(1/4),项目已成功实施1个月，某天项目组成员小谢突然告诉项目负责人，他已办理好了去德国的签证，2周后他会辞职离开公司前往德国留学 （人员） 小谢的离开显然将会影响项目组的正常运作，影响项目的进度，为此将会给项目的实施带来损失 可以想象，2周以后小谢的离开将会带来一系列问题：谁来接替小谢的工作？在此之前谁来负责交接小谢的工作？如何尽可能的避免由此给项目组带来的损失(包括进度损失和工作损失等) 尽管还没发生，但必须考虑如何避免问题的发生，以及一旦发生后该采取得措施，以便将损失减少到最少,3,案例场景模拟(2/4),按照软件开发计划，需求分析应在12

2、月31日前完成，然而在软件项目实施过程中项目经理发现，由于原先对工作量估算过于乐观，需求分析在12月31日之前已经不可能完成（计划） 显然，原先计划制定的不科学和不准确，导致了实施过程中进度难以控制，如果强行按照计划来执行显然是不可行的，为此，必须对计划重新进行分析和调整,4,案例场景模拟(3/4),在软件设计阶段，软件设计负责人发现，用户需求中的某项需求(例如，将已有word文档的内容显示在Web页面上)至今尚未找到解决的技术途径（技术） 显然，该问题将直接影响软件项目的后续开发工作，影响到软件项目能否成功完成,5,案例场景模拟(4/4),在需求分析过程中，软件设计负责人带领的需求分析小组和

3、用户在进行交流的过程中发生了矛盾，出现了争吵，用户方说将不再配合需求分析小组的工作，而且他们确实没有配合开发方的工作（合作） 显然，开发方和用户方出现这种状况是双方没有想到的 这种状况延续下去必将对软件项目的实施产生影响，影响软件项目的进度，甚至会导致项目失败,6,案例启示：,风险在项目实施过程中大量存在 软件风险形式多样 软件风险事先难以确定 软件风险会对软件项目的实施产生不良影响 如果不对风险进行良好的管理，项目就很难保证按照计划、在成本和进度范围内，开发出高质量的软件产品，甚至会导致项目失败,7,5.1 概述,5.1.1 风险 5.1.2 软件风险 5.1.3 软件项目风险管理 5.1.

4、4 软件项目风险管理的意义,8,5.1.1 风险,卡内基.梅隆大学的软件工程研究所SEI： 风险是损失的可能性 Websters Dictionary： 风险是遭受损失、伤害、破坏的可 能性。 风险的根源是不利的情况(或损失)发生的不确定性 ，即不期望发生事件的客观不确定性 。 风险是在给定情况下和特定时间内，那些可能发生的结果之间的差异，差异越大则风险越大。,9,5.1.1 风险,风险具有两大属性： 可能性：风险发生的概率 损失：指预期与后果之间的差异,风险的损失=可能性损失,10,项目风险函数表达式,项目风险具有不同的组成要素，如项目不希望发生的事件、事件发生的概率、事件的后果等。 每个项

5、目的风险可定义为不确定性和后果的函数：,风险= f（事件，不确定性，后果) 风险= f (事故，安全措施),11,5.1.2 软件风险,什么是软件风险？ 使软件项目的实施受到影响和损失、甚至导致失败的、可能会发生的事件 例如，人员的临时流失，计划过于乐观，设计的低劣 软件风险的特点 事先难以确定 带来损失，影响项目实施，甚至会导致项目失败,12,5.1.2 软件风险,软件风险由管理过程风险和技术过程风险组成，又可分为： 1、软件项目风险 2、软件过程风险 3、软件产品风险,13,5.1.3 软件风险管理,什么是软件风险管理？ 软件风险管理与项目管理的关系 软件风险管理的主要内容,14,什么是软

6、件风险管理？(1/3),面对软件风险，一般有两类方法： 被动救火型 主动防火型 软件风险管理属于主动防火型方法,15,什么是软件风险管理？(2/3),软件风险管理是对影响软件项目、过程或产品的风险进行估计和控制的实践过程。 定义目标。从目标逆向思维可发现软件风险。 根据不确定性、损失和时间来描述风险。,16,风险管理的涵义,根据美国项目管理学会（PMI）的报告，风险管理有三个涵义： 系统识别和评估风险因素的形式化过程。 识别和控制能够引起不希望的变化的潜在领域和事件的形式、系统的方法。 在项目期间识别、分析风险因素，采取必要对策的决策科学和决策艺术的结合。,17,什么是软件风险管理？(3/3)

7、,在风险影响软件项目成功实施前，对它进行识别和处理，并预防和消除风险的发生。 识别风险(会有哪些风险？) 预防和消除风险(最好别让风险发生) 制定风险发生后的处理措施(万一发生该怎么办？),18,软件风险管理,未来是我们所关心的什么样的风险会导致软件项目彻底失败呢？ 改变也是我们所关心的用户需求、开发技术、目标计算机、以及所有其他与项目相关的因素的改变将会对按时交付和总体成功产生什么影响呢？ 最后，我们必须抓住机会我们应该采用什么方法及工具？需要多少人员参与工作？对质量的要求要达到什么程度才是“足够的”？,19,软件风险管理过程,风险管理过程就是从一堆模糊不清的问题、担心和未知开始，逐步将这些

8、不确定因素加以辨识、分析，并进而转化为可接受的风险。 风险管理过程是一个持续不断的过程，贯穿于项目周期的始终。,20,软件风险管理与项目管理的关系,软件风险管理是整个项目管理的一部分。 风险管理与项目管理的关系可归纳如下： 从项目的成本、时间和质量目标来看，风险管理与项目管理的目标一致。 从项目管理的计划职能来看，风险管理为项目计划的制定提供了依据。 从项目的成本管理职能来看，项目风险管理通过风险分析，指出有哪些可能的计划外费用，并估计它的多少。 从项目实施过程来看，许多风险都在项目实施过程中由潜在变为现实。定出风险反应计划。,21,软件风险管理的主要内容,22,项目风险管理内容,Risk M

9、anagement Planning 风险管理计划 Risk Identification风险识别 Qualitative Risk Analysis风险定性分析 Quantitative Risk Analysis风险定量分析 Risk Response Planning风险应对计划 Risk monitoring and control 风险监控,23,5.1.4 软件项目风险管理的意义,KPMG即毕马威，著名的BIG FOUR国际四大会计师事务所之一（其他三大事务所为PwC普华永道，DTT德勤和E&Y安永）的一项调查指出 55%失控的项目是没有进行了风险管理； 38%的失控项目作了一些,

10、但是其中的一半在项目进行后就没有使用风险监督； 剩余7%情况不明。 项目实施风险管理的意义，见P141的8点,24,5.2 风险识别,25,5.2 风险识别,风险识别，或称风险辨识，是寻找可能影响项目的风险以及确认风险特性的过程。 风险识别活动的参加人员一般包括：项目组成员、风险管理人员、学科专家（组织内）、客户、项目的其他管理人员以及外部专家等。 风险识别的目标是：辨识项目面临的风险，揭示风险和风险来源，以文档及数据库的形式记录风险。,26,5.2.1 风险识别依据,项目计划 历史与经验信息 外部制度约束风险 项目内部的不确定性,27,5.2.2 常见软件风险,风险的类别 计划编制 组织和管

11、理 开发环境 最终用户 客户 承包商 需求 产品外部环境 人员 设计和实现 过程,28,政府,客户,供货商,分包商,潜在的客户,最终用户,项目经理,团队,发起人,竞争者,组织,集中管理,同事,其他的项目,自然环境,人员 时间 资金 技术 其他要素,项目风险来源,29,计划编制风险,计划、资源和产品的定义完全由客户或上层领导决定，忽略了项目组的意见，并且这些决定不完全一致 计划忽略了必要的任务和活动 计划不切实际 计划基于特定小组成员，而这样的小组成员根本得不到 产品规模估算过于乐观 工作量估算过于乐观 进度的压力造成生产率的下降 目标日期提前，但没有相应地调整产品范围和可用资源 一个关键任务的

12、延迟导致其他相关任务的连锁反应 ,30,组织和管理风险,缺乏强有力、有凝聚力的领导(项目组、企业) 解雇员工导致项目小组能力下降 削减预算打乱项目计划 仅由管理层和市场人员进行技术决策，导致进度延长 低效的项目组组织结构降低生产率 管理层审查/决策的周期比预期时间长 管理层作出了打击项目组积极性的决定 非技术的第三方的工作比预期要长(如, 采购硬件设备) 计划性太差，无法适应期望的开发速度 项目计划由于压力而放弃，导致开发混乱 管理方面的英雄主义，忽视客观确切的状态报告，降低发现和改正问题的能力,31,开发环境风险,设施不能及时到位 设施到位，但不配套 开发工具未能及时到位 开发工具不如期望的

13、那样有效，开发人员需要更多的时间，或者更换工具 开发工具的学习期比预期的要长 开发工具的选择不是基于技术需求，不能提供计划要求的功能,32,最终用户风险,最终用户坚持新的需求 最终用户对最后交付的产品不满意，要求重新设计和重做 最终用户不买进项目产品，无法提供后续支持 最终用户的意见未被采纳，造成产品最终无法满足用户要求,33,组织和管理风险,缺乏强有力、有凝聚力的领导(项目组、企业) 解雇员工导致项目小组能力下降 削减预算打乱项目计划 仅由管理层和市场人员进行技术决策，导致进度延长 低效的项目组组织结构降低生产率 管理层审查/决策的周期比预期时间长 管理层作出了打击项目组积极性的决定 非技术

14、的第三方的工作比预期要长(如, 采购硬件设备) 计划性太差，无法适应期望的开发速度 项目计划由于压力而放弃，导致开发混乱 管理方面的英雄主义，忽视客观确切的状态报告，降低发现和改正问题的能力,34,开发环境风险,设施不能及时到位 设施到位，但不配套 开发工具未能及时到位 开发工具不如期望的那样有效，开发人员需要更多的时间，或者更换工具 开发工具的学习期比预期的要长 开发工具的选择不是基于技术需求，不能提供计划要求的功能,35,最终用户风险,最终用户坚持新的需求 最终用户对最后交付的产品不满意，要求重新设计和重做 最终用户不买进项目产品，无法提供后续支持 最终用户的意见未被采纳，造成产品最终无法

15、满足用户要求,36,客户风险(1/2),客户坚持新的需求 客户对规划、原型和规格的审核/决策超出预期 客户没有参与规划、原型和规格的审核，导致需求不稳定，以及长时间的变更 客户答复的时间比预期的要长 客户坚持技术决策而导致计划延长 客户对开发进度管理过细，导致实际进度变慢 客户提供的组件无法与开发的产品匹配，导致需要额外的设计和集成工作 客户提供的组件质量欠佳，导致额外的测试、设计或者功能不完善,37,客户风险(2/2),客户要求的支持工具与环境不兼容，性能差或者不完善，导致生产率降低 客户不接受交付的软件，尽管它满足了所有的规格 客户期望的开发速度是开发人员所无法达到的,38,承包商风险,承

16、包商没有按照承诺交付产品 承包商提供的产品质量低下，必须花时间改进质量 承包商提供的产品性能达不到要求,39,需求风险,需求已经成为项目基准，但仍在变化 需求定义欠佳：不清晰、不准确、不一致 增加额外的需求,40,产品风险,错误发生率高的模块，需要更多的时间对它进行测试、设计和实现 矫正质量低下的不可接受的产品需要更多的时间对它进行测试、设计和实现 由于功能错误，导致需要重新进行设计和实现 开发额外不需要的功能延长了进度 要满足产品规模和速度要求，需要更多的时间 严格要求与现有系统兼容，需要更多的时间 要求软件重用，需要更多的时间 ,41,外部环境风险,产品依赖政府规章，而规章的改变不可预期

17、产品依赖草拟中的技术标准，而最后的标准不可预期,42,人员风险(1/3),招聘人员所需的时间比预期要长 作为人员参与工作的先决条件(如培训、其他项目的完成等)不能按时完成 开发人员与管理层关系不佳导致决策迟缓、影响全局 项目组成员没有全身心地投入到项目中，因而无法达到所需的产品功能和性能需求 缺乏激励措施、士气低下，降低生产能力 缺乏必要的规范，增加工作失误，重复工作，降低工作质量 缺乏工作基础(语言、经验、工具等) 项目结束前，项目组成员离开项目组,43,人员风险(2/3),项目后期，加入新的开发人员，额外的培训和沟通降低了项目组成员的开发效率 项目组成员不能有效的在一起工作 由于项目组成员

18、之间的冲突，导致沟通不畅，设计欠佳，接口错误和额外重复的工作 有问题的项目组成员没有调离项目组，影响其他成员的积极性 项目组的最佳人选没有加入项目组，或者加入项目组但没有合理使用 关键任务只能兼职参与 项目人员不足,44,人员风险(3/3),任务的分配和人员的技能不匹配 人员工作的进展比预期的要慢 项目管理人员怠工导致计划和进度失效 技术人员怠工导致工作遗漏、质量低下，工作需要重做,45,设计和实现风险,设计过于简单，考虑不仔细、不全面，导致重新设计和实现 设计过于复杂，导致一些不必要的工作，影响效率 设计质量低下，导致重新设计和实现 使用不熟悉的方法，导致需要额外的培训时间 产品使用低级语言

19、编写，导致效率较低 分别开发的模块无法有效集成，需要重新设计和实现,46,过程风险,跟踪不准确，导致无法预知项目进展是否落后于计划 前期的质量保证行为不真实，导致后期的重复工作 质量跟踪不准确，导致无法得知影响进度的质量问题 不能有效遵循标准，导致沟通不足，质量问题和重复工作 风险管理粗心，导致没有发现重大的项目风险 ,47,例子:风险列表,48,各阶段典型风险事件,48,风险发生 最高时期,风险影响 最高时期,机会和风险,得失量,时间,各阶段典型的风险事件,风 险,价 值,49,5.2.3 风险识别过程,风险分析过程是将项目的不确定性转变为风险陈述的过程。它包括以下活动： 进行风险评估 系统

20、地识别风险 风险定义及分类 确定风险驱动因素 将风险编写为文档 P144,50,5.2.4 风险识别方法与技术,有很多有效的方法，主要有： 核对清单 头脑风暴法 Delphi法 会议法 匿名风险报告机制 ,51,1.核对清单,可以采用SEI推荐的软件风险分类系统或项目工作细分结构WBS作为核对清单。 SEI软件风险分类系统是一个结构化的核对清单。SEI软件风险分类系统将风险分为产品工程、开发环境和项目约束三类。每类又分若干元素，每个元素通过其属性来体现特征。 SEI软件风险分类系统如P145表5.1所示:,52,53,WBS模型,项目工作细分结构WBS提供了识别具体项目风险的框架。 每一个项目

21、元素都以支持项目开发活动（计划、执行、控制等）的细节方式被定义。WBS减少了项目的灰度，使项目结构清晰。,54,WBS模型,55,2.头脑风暴法,召集项目组全体会议，进行关于项目风险的自由讨论，项目组成员在主持人的引导下完全自由地发言，不受限制，产生关于项目风险的概念。 头脑风暴法是一种搜集项目风险的常用方法。,56,3. Delphi法,Delphi法又称反馈匿名函询法，本质上是一种达到关于一个科目的专家一致意见的方法。 这个“科目”可以是软件成本，软件项目风险等。 任命专家专家匿名参加发调查表给专家专家填写由调查人员将专家意见汇总整理再返回起点。 这个方法体现了民主性。,57,4.会议法,

22、定期的项目组会议，如项目转折点或重要变更时举行的会议、项目月及季度总结会项目专家会议都适宜于谈论风险信息，将风险讨论列为会议议题。,58,5.SWOT分析法,SWOT技术 （Strengths,Weankness,Opportunities,Threats)是分析项目内部优势与弱势和项目外部机会与威胁综合分析的代名词。 主要对项目的优势和劣势、机会与威胁等各方面，从多角度对项目风险进行识别。,59,SWOT 分析法,内部因素,外部因素,S,W,O,T,60,示例,积极,消极,内部,外部,61,6.匿名风险报告机制,向管理层或组内报告好的消息很少会出现问题，但报告项目的坏消息则不然。 必须有一个

23、匿名的风险交流渠道。,62,5.3 风险分析,63,5.3 风险分析,风险分析是人们应用风险分析工具,加深对风险的认识与理解，使风险及风险背景明晰化，从而为有效地管理风险提供基础。 风险分析活动的过程目标包括：提炼风险背景，确定风险来源，确定行动时间框架，确定前10项首要风险名单等。,64,5.3.1 风险分析过程,定义风险度量准则 预测风险景响 评估风险 风险排序 制订风险计划,65,5.3.1 风险分析过程-1.定义风险度量准则,定义风险度量准则 风险度量准则是按照重要性对风险进行排序的最基本依据。风险度量准则包括可能性、后果和行动时间框架。,66,5.3.1 风险分析过程-1.定义风险度

24、量准则,（1）可能性 定性度量包括：极低、低、中、高、极高，也可简单定义为：低、中、高。 （2）后果 后果反映了风险对项目目标的影响程度。 （3）行动时间框架 行动时间框架是指采取有效措施规避风险的时限。,67,5.3.1 风险分析过程-2.预测风险影响,我们用风险发生的可能性与风险后果的乘积来度量风险的影响。 风险影响（RE） =风险发生的可能性（P）*风险后果（C） 可能性被定义为大于0，小于1。 后果从1到10表示风险对成本、进度和技术目标的影响。两者的乘积可能是经济的损失，也可能是时间的损失等。,68,5.3.1 风险分析过程-3.评估风险,风险影响和行动时间框架决定了风险的相对严重程

25、度，见P148表5.4。风险严重程度有利于区分当前风险的优先级别。随着时间的推移，风险严重程度发生变化，有利于提供当前项目面临的重点问题。,69,5.3.1 风险分析过程-4.风险排序,依据评估准确风险排序，可保证高风险影响和短行动时间框架的风险能被最先处理。右表是一个非常生要的风险报告形式，在实际项目中可以使用。,70,5.3.1 风险分析过程-5.制定风险计划,风险计划是实施风险应对措施的依据与前提。 风险计划要包括： 确定风险设想 选择风险应对途径 其中，常用作选择风险应对途径的取舍标准是风险倍率和风险多样化。 风险多样化通过分散风险来减少风险。项目不要过分依赖一种方法、一种工具、一个人

26、或一个厂商等。 设定风险阈值 编写风险计划,71,风险倍率,风险倍率是一条风险应对法则，它通过减少风险影响来减少风险。 风险应对成本是实施风险行动计划的成本。 倍率的概仿有助于确定获得最高回报的行动。 主要的风险倍率多存在于软件生命周期的早期。,5.3.2 风险分析技巧与工具,因果关系分析法 决策分析法： 用于构建决策，用决策模型来代表真实世界里的问题。 决策模型的元素包括决策、不确定事件以及结果的价值。 差距分析法 确定变量的差距。描述了人们意识到的重要性和实际执行情况的差距，从而确定风险管理实践是否需要改进。 Pareto帕雷托分析法 只要找出项目风险的20%关键致因，就可以解决项目的大部

27、分问题 敏感度分析法 通过改变每一个输入变量，保持其它变量，来确定厝型对输入变量的敏感度。,73,因果关系分析法鱼骨图,74,5.3.3风险分析的成果,经过风险分析，可以得到一个按优先等级排 序的风险列表。,75,5.4 风险跟踪与应对,76,风险控制,风险管理计划 风险化解 风险监控,77,风险监控(1/2),检查风险的化解程度及其变化(概率、损失) 风险监控的方式 监控和跟踪重要的(前10个)风险，记录风险危险度的变化以及风险化解的进展 中间审查，在每个里程碑后进行小规模的走查 任命风险官员(适合于大项目)，警告项目风险，防止项目经理和开发人员忽略计划中的风险管理,78,风险管理计划(2/2),例子，小谢将在项目实施过程中离开公司 *项目组的小谢 项目组成员小谢由于出国离开公司 小谢可能会在6月1日前后出国 为了进一步学习和深造 和小谢协商能否在项目结束之后(大约7月中旬)离开 如果离开，计划让小王接