第5章 软件项目风险管理

1第五章软件项目风险管理2案例场景模拟(1/4)项目已成功实施1个月，某天项目组成员小谢突然告诉项目负责人，他已办理好了去德国的签证，2周后他会辞职离开公司前往德国留学（人员）小谢的离开显然将会影响项目组的正常运作，影响项目的进度，为此将会给项目的实施带来损失可以想象，2周以后小谢的离开将会带来一系列问题：谁来接替小谢的工作？在此之前谁来负责交接小谢的工作？如何尽可能的避免由此给项目组带来的损失(包括进度损失和工作损失等)尽管还没发生，但必须考虑如何避免问题的发生，以及一旦发生后该采取得措施，以便将损失减少到最少3案例场景模拟(2/4)按照软件开发计划，需求分析应在12月31日前完成，然而在软件项目实施过程中项目经理发现，由于原先对工作量估算过于乐观，需求分析在12月31日之前已经不可能完成（计划）显然，原先计划制定的不科学和不准确，导致了实施过程中进度难以控制，如果强行按照计划来执行显然是不可行的，为此，必须对计划重新进行分析和调整4案例场景模拟(3/4)在软件设计阶段，软件设计负责人发现，用户需求中的某项需求(例如，将已有word文档的内容显示在Web页面上)至今尚未找到解决的技术途径（技术）显然，该问题将直接影响软件项目的后续开发工作，影响到软件项目能否成功完成5案例场景模拟(4/4)在需求分析过程中，软件设计负责人带领的需求分析小组和用户在进行交流的过程中发生了矛盾，出现了争吵，用户方说将不再配合需求分析小组的工作，而且他们确实没有配合开发方的工作（合作）显然，开发方和用户方出现这种状况是双方没有想到的这种状况延续下去必将对软件项目的实施产生影响，影响软件项目的进度，甚至会导致项目失败6案例启示：风险在项目实施过程中大量存在软件风险形式多样软件风险事先难以确定软件风险会对软件项目的实施产生不良影响如果不对风险进行良好的管理，项目就很难保证按照计划、在成本和进度范围内，开发出高质量的软件产品，甚至会导致项目失败75.1概述5.1.1风险5.1.2软件风险5.1.3软件项目风险管理5.1.4软件项目风险管理的意义85.1.1风险卡内基.梅隆大学的软件工程研究所SEI：风险是损失的可能性Webster’sDictionary：风险是遭受损失、伤害、破坏的可能性。风险的根源是不利的情况(或损失)发生的不确定性，即不期望发生事件的客观不确定性。风险是在给定情况下和特定时间内，那些可能发生的结果之间的差异，差异越大则风险越大。95.1.1风险风险具有两大属性：可能性：风险发生的概率损失：指预期与后果之间的差异风险的损失=可能性×损失10项目风险函数表达式项目风险具有不同的组成要素，如项目不希望发生的事件、事件发生的概率、事件的后果等。每个项目的风险可定义为不确定性和后果的函数：风险=f（事件，不确定性，后果)风险=f(事故，安全措施)115.1.2软件风险什么是软件风险？使软件项目的实施受到影响和损失、甚至导致失败的、可能会发生的事件例如，人员的临时流失，计划过于乐观，设计的低劣软件风险的特点事先难以确定带来损失，影响项目实施，甚至会导致项目失败125.1.2软件风险软件风险由管理过程风险和技术过程风险组成，又可分为：1、软件项目风险2、软件过程风险3、软件产品风险135.1.3软件风险管理1.什么是软件风险管理？2.软件风险管理与项目管理的关系3.软件风险管理的主要内容14什么是软件风险管理？(1/3)面对软件风险，一般有两类方法：被动救火型主动防火型软件风险管理属于主动防火型方法15什么是软件风险管理？(2/3)软件风险管理是对影响软件项目、过程或产品的风险进行估计和控制的实践过程。定义目标。从目标逆向思维可发现软件风险。根据不确定性、损失和时间来描述风险。16风险管理的涵义根据美国项目管理学会（PMI）的报告，风险管理有三个涵义：1.系统识别和评估风险因素的形式化过程。2.识别和控制能够引起不希望的变化的潜在领域和事件的形式、系统的方法。3.在项目期间识别、分析风险因素，采取必要对策的决策科学和决策艺术的结合。17什么是软件风险管理？(3/3)在风险影响软件项目成功实施前，对它进行识别和处理，并预防和消除风险的发生。识别风险(会有哪些风险？)预防和消除风险(最好别让风险发生)制定风险发生后的处理措施(万一发生该怎么办？)18软件风险管理未来是我们所关心的——什么样的风险会导致软件项目彻底失败呢？改变也是我们所关心的——用户需求、开发技术、目标计算机、以及所有其他与项目相关的因素的改变将会对按时交付和总体成功产生什么影响呢？最后，我们必须抓住机会——我们应该采用什么方法及工具？需要多少人员参与工作？对质量的要求要达到什么程度才是“足够的”？19软件风险管理过程风险管理过程就是从一堆模糊不清的问题、担心和未知开始，逐步将这些不确定因素加以辨识、分析，并进而转化为可接受的风险。风险管理过程是一个持续不断的过程，贯穿于项目周期的始终。20软件风险管理与项目管理的关系软件风险管理是整个项目管理的一部分。风险管理与项目管理的关系可归纳如下：从项目的成本、时间和质量目标来看，风险管理与项目管理的目标一致。从项目管理的计划职能来看，风险管理为项目计划的制定提供了依据。从项目的成本管理职能来看，项目风险管理通过风险分析，指出有哪些可能的计划外费用，并估计它的多少。从项目实施过程来看，许多风险都在项目实施过程中由潜在变为现实。定出风险反应计划。21软件风险管理的主要内容22项目风险管理内容RiskManagementPlanning－风险管理计划RiskIdentification－风险识别QualitativeRiskAnalysis－风险定性分析QuantitativeRiskAnalysis－风险定量分析RiskResponsePlanning－风险应对计划Riskmonitoringandcontrol－风险监控235.1.4软件项目风险管理的意义KPMG即毕马威，著名的BIGFOUR——国际四大会计师事务所之一（其他三大事务所为PwC普华永道，DTT德勤和E&Y安永）的一项调查指出55%失控的项目是没有进行了风险管理；38%的失控项目作了一些,但是其中的一半在项目进行后就没有使用风险监督；剩余7%情况不明。项目实施风险管理的意义，见P141的8点245.2风险识别255.2风险识别风险识别，或称风险辨识，是寻找可能影响项目的风险以及确认风险特性的过程。风险识别活动的参加人员一般包括：项目组成员、风险管理人员、学科专家（组织内）、客户、项目的其他管理人员以及外部专家等。风险识别的目标是：辨识项目面临的风险，揭示风险和风险来源，以文档及数据库的形式记录风险。265.2.1风险识别依据项目计划历史与经验信息外部制度约束风险项目内部的不确定性275.2.2常见软件风险风险的类别计划编制组织和管理开发环境最终用户客户承包商需求产品外部环境人员设计和实现过程28政府客户供货商分包商潜在的客户最终用户项目经理团队竞争者同事自然环境•人员•时间•资金•技术•其他要素项目风险来源29计划编制风险计划、资源和产品的定义完全由客户或上层领导决定，忽略了项目组的意见，并且这些决定不完全一致计划忽略了必要的任务和活动计划不切实际计划基于特定小组成员，而这样的小组成员根本得不到产品规模估算过于乐观工作量估算过于乐观进度的压力造成生产率的下降目标日期提前，但没有相应地调整产品范围和可用资源一个关键任务的延迟导致其他相关任务的连锁反应……30组织和管理风险缺乏强有力、有凝聚力的领导(项目组、企业)解雇员工导致项目小组能力下降削减预算打乱项目计划仅由管理层和市场人员进行技术决策，导致进度延长低效的项目组组织结构降低生产率管理层审查/决策的周期比预期时间长管理层作出了打击项目组积极性的决定非技术的第三方的工作比预期要长(如,采购硬件设备)计划性太差，无法适应期望的开发速度项目计划由于压力而放弃，导致开发混乱管理方面的英雄主义，忽视客观确切的状态报告，降低发现和改正问题的能力31开发环境风险设施不能及时到位设施到位，但不配套开发工具未能及时到位开发工具不如期望的那样有效，开发人员需要更多的时间，或者更换工具开发工具的学习期比预期的要长开发工具的选择不是基于技术需求，不能提供计划要求的功能32最终用户风险最终用户坚持新的需求最终用户对最后交付的产品不满意，要求重新设计和重做最终用户不买进项目产品，无法提供后续支持最终用户的意见未被采纳，造成产品最终无法满足用户要求33组织和管理风险缺乏强有力、有凝聚力的领导(项目组、企业)解雇员工导致项目小组能力下降削减预算打乱项目计划仅由管理层和市场人员进行技术决策，导致进度延长低效的项目组组织结构降低生产率管理层审查/决策的周期比预期时间长管理层作出了打击项目组积极性的决定非技术的第三方的工作比预期要长(如,采购硬件设备)计划性太差，无法适应期望的开发速度项目计划由于压力而放弃，导致开发混乱管理方面的英雄主义，忽视客观确切的状态报告，降低发现和改正问题的能力34开发环境风险设施不能及时到位设施到位，但不配套开发工具未能及时到位开发工具不如期望的那样有效，开发人员需要更多的时间，或者更换工具开发工具的学习期比预期的要长开发工具的选择不是基于技术需求，不能提供计划要求的功能35最终用户风险最终用户坚持新的需求最终用户对最后交付的产品不满意，要求重新设计和重做最终用户不买进项目产品，无法提供后续支持最终用户的意见未被采纳，造成产品最终无法满足用户要求36客户风险(1/2)客户坚持新的需求客户对规划、原型和规格的审核/决策超出预期客户没有参与规划、原型和规格的审核，导致需求不稳定，以及长时间的变更客户答复的时间比预期的要长客户坚持技术决策而导致计划延长客户对开发进度管理过细，导致实际进度变慢客户提供的组件无法与开发的产品匹配，导致需要额外的设计和集成工作客户提供的组件质量欠佳，导致额外的测试、设计或者功能不完善37客户风险(2/2)客户要求的支持工具与环境不兼容，性能差或者不完善，导致生产率降低客户不接受交付的软件，尽管它满足了所有的规格客户期望的开发速度是开发人员所无法达到的38承包商风险承包商没有按照承诺交付产品承包商提供的产品质量低下，必须花时间改进质量承包商提供的产品性能达不到要求39需求风险需求已经成为项目基准，但仍在变化需求定义欠佳：不清晰、不准确、不一致增加额外的需求40产品风险错误发生率高的模块，需要更多的时间对它进行测试、设计和实现矫正质量低下的不可接受的产品需要更多的时间对它进行测试、设计和实现由于功能错误，导致需要重新进行设计和实现开发额外不需要的功能延长了进度要满足产品规模和速度要求，需要更多的时间严格要求与现有系统兼容，需要更多的时间要求软件重用，需要更多的时间……41外部环境风险产品依赖政府规章，而规章的改变不可预期产品依赖草拟中的技术标准，而最后的标准不可预期42人员风险(1/3)招聘人员所需的时间比预期要长作为人员参与工作的先决条件(如培训、其他项目的完成等)不能按时完成开发人员与管理层关系不佳导致决策迟缓、影响全局项目组成员没有全身心地投入到项目中，因而无法达到所需的产品功能和性能需求缺乏激励措施、士气低下，降低生产能力缺乏必要的规范，增加工作失误，重复工作，降低工作质量缺乏工作基础(语言、经验、工具等)项目结束前，项目组成员离开项目组43人员风险(2/3)项目后期，加入新的开发人员，额外的培训和沟通降低了项目组成员的开发效率项目组成员不能有效的在一起工作由于项目组成员之间的冲突，导致沟通不畅，设计欠佳，接口错误和额外重复的工作有问题的项目组成员