9软件项目风险管理

软件项目风险管理山东大学计算机学院21.软件项目风险管理概述•风险概念•软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失•美国软件工程研究所将风险定义为：损失的可能性•风险同人们有目的的活动有关，同未来的活动有关，同人们变化的行为方式有关•风险具有两大属性：可能性(Likelihood)和损失(Loss)，可能性是风险发生的概率，损失是指预期与后果之间的差异•风险的根源在于事物的不确定性，虽然无法避免不确定性，但是可以通过适当的方法对其进行控制与管理山东大学计算机学院31.软件项目风险管理概述•风险类型（从范围角度上看）•项目风险•预算、进度、个人、资源、用户和需求•技术风险•商业风险•已知风险、可预测风险、不可预测风险山东大学计算机学院42.软件风险管理的主要内容•风险管理•是指在项目进行过程中不断对风险进行识别、评估，制定策略，监控风险的过程。合理地使用各种风险应对措施、管理方法、技术和手段对项目的风险进行有效的控制，妥善处理风险事件造成的不利后果，以最小的成本保证项目总体目标的实现•制定风险管理计划•风险识别•风险分析•风险计划•风险跟踪•风险应对•风险管理验证山东大学计算机学院52.1风险管理计划•风险管理计划的内容•目标•目的•任务•范围•策略•政策•途径•项目角色•过程•识别风险•分析风险•计划风险•跟踪风险•应对风险•验证•评审标准•审计过程•审计报告•机制•风险核对清单•风险管理表•风险数据库模式山东大学计算机学院62.2风险识别•风险识别或称风险辨识，是寻找可能影响项目的风险以及确认风险特性的过程。风险识别的目标是：辨识项目面临的风险，揭示风险和风险来源，以文档及数据库的形式记录风险。•风险识别的输入与输出输入可能是项目的WBS、工作的陈述（StatementOfWork，SOW）、项目相关信息、项目计划假设、历史项目数据，其他项目经验文件、评审报告、公司目标等。风险识别的输出是风险列表。•风险识别包括以下活动风险识别方法的确定；风险定义及分类；风险文档编写风险识别•风险识别的方法•(1)风险条目检查表——风险条目检查表是最常用也是比较简单的风险识别方法，它是利用一组提问来帮助管理者了解项目在各方面有哪些风险。•在风险条目检查表中，列出了所有可能的与每一个风险因素有关的提问，使得风险管理者集中来识别常见的、已知的和可预测的风险(如产品规模风险、依赖性风险、需求风险、管理风险及技术风险等)。•风险条目检查表一般根据风险要素进行编写，包括项目的环境、管理层的重视度、技术情况以及内部因素(如团队成员的技能或技能缺陷等)。山东大学计算机学院8山东大学计算机学院92.2风险识别•风险识别的方法•(2)德尔菲（Delphi）方法•又称专家调查法•由项目风险小组选定与该项目有关的领域专家，并与这些适当数量的专家建立直接的联系•通过收取专家意见，然后加以综合整理，再匿名反馈给各位专家，再次征询意见•这样反复，逐步使专家的意见趋向一致，作为最后预测和识别的根据。风险识别•(3)情景分析法——情景分析法是根据项目发展趋势的多样性，通过对系统内外相关问题的系统分析，设计出多种可能的未来前景，然后用类似于撰写电影剧本的手法，对系统发展态势做出自始至终的情景和画面的描述。•当一个项目持续的时间较长时，往往要考虑各种技术、经济和社会因素的影响，对这种项目进行风险预测和识别，就可用情景分析法来预测和识别其关键风险因素及其影响程度。•(4)会议法/头脑风暴法——定期的项目组会议，如项目转折点或重要变更时举行的会议，项目月、季度总结会，项目专家会议都适宜于谈论风险信息，将风险讨论列为会议议题。山东大学计算机学院11风险识别的结果•如：•规模估算可能非常低•用户数量大大超出计划•复用程度低于计划•最终用户抵制该计划山东大学计算机学院122.3风险分析•风险分析/评估•对识别出的风险做进一步分析，对风险发生的概率进行估计和评价，对风险后果的严重程度进行估计和评价，对风险影响范围进行估计和评价，以及对于风险发生时间进行估计和评价。山东大学计算机学院132.3风险分析•风险分析/评估•对识别出的风险做进一步分析，对风险发生的概率进行估计和评价，对风险后果的严重程度进行估计和评价，对风险影响范围进行估计和评价，以及对于风险发生时间进行估计和评价。山东大学计算机学院14山东大学计算机学院15山东大学计算机学院16山东大学计算机学院17山东大学计算机学院18山东大学计算机学院19山东大学计算机学院202.3风险分析•1.风险分析过程•(1)确定风险类别•将类似的风险归为一组•(2)确定风险驱动因素•如成本驱动因素•进度的驱动因素•(3)判定风险来源•(4)定义风险度量准则•可能性•后果：影响程度•行动实践框架：指采取时有效措施规避风险的时限•(5)预测风险影响•风险影响(RE)=可能性（P）*后果（C）•(6)评估风险•(7)对风险进行排序•(8)将风险分析结果归档山东大学计算机学院21•2.软件项目的主要风险•资源风险•人员风险：人员配备不合理、团队成员缺乏合作精神、忽略或没有时间进行必要的项目培训、人员缺乏必胜的进取心、人员工资环境低劣等•过分自信的进度加上固定的成本预算，必然会导致进度与成本方面的风险•不切实际的过高生产效率要求，把加班当作是克服进度过慢的标准过程•缺乏项目分析时间可能导致对产品功能需求的片面理解山东大学计算机学院22•需求风险•模糊或变换的用户需求必然导致系统需求的混乱•文档没有准确记录系统的需求•接口文档不同意，或存在灰度与歧义•需求因为客户方面人员的变动而改变•软件可靠性分析和可接受标准需求与定义不清楚•对系统不切实际的期望，包括进度、技术等•商业软件产品定位不清导致的需求混乱山东大学计算机学院23•项目接口风险•依靠外部软件交货很可能导致进度落后•分承包商的技术能力低于期望值•硬件没有检验，文档记录不全•分承包商的方法论与客户要求的标准不符•设计风险•未经检验的设计可能会引发系统的性能问题，使之无法达到既定的性能要求山东大学计算机学院24•管理风险•角色与责任不明确或定义不当，会引起不协调的活动、不合理的工作负担以及工作重点不突出•项目角色与责任没有被充分理解•项目缺乏或没有有效的人员激励机制•缺乏时间与人员对产品进行必要的内部评审•项目报告不真实或重点不突出•管理制度不落实山东大学计算机学院25•开发过程风险•不切实际的进度与成本要求•项目缺少富于经验的资深开发人员•使用未经充分验证的新技术、新开发平台导致最终系统崩溃•软件开发计划的调整没有充分考虑项目的大小与实际情况•开发工具没有全集成•客户文件格式和维护能力与现有开发环境不合山东大学计算机学院26•项目集成与测试风险•集成与测试由于受到进度与成本的制约而受到压缩•测试过程没有良好定义•一些需求不能测试•系统稳定性测试由于时间限制不充分2.4风险计划•风险计划针对风险分析的结果，为提高实现项目目标的机会并降低风险的负面影响而制定风险应对策略和应对措施的过程，即通过制定一系列的行动和策略来对付、减少以至于消灭风险事件。•降低风险的主要策略回避风险、转移风险、损失控制山东大学计算机学院28•风险计划的成果•已辨识风险、它们的描述、影响项目的区域、风险原因以及它们如何影响项目目标•风险责任人以及应对的责任•已确认的风险反应计划，包括避免、缓解、转移、研究或接受等•在采取风险反映策略之后留存的残余风险水平•应急计划与分线退避计划•风险反应的预算和时间山东大学计算机学院292.4风险计划•风险计划过程•确定风险设想•确定风险应对策略•避免•转移•缓解•接受•研究•储备•退避•选择风险应对途径•建立风险示警阈值•如去除缺陷效率目标：大于95%，阈值：小于85%•制定风险反应计划山东大学计算机学院302.5风险跟踪•风险跟踪的依据•风险设想•风险阈值•风险状态•风险跟踪的成果•风险度量•触发器•风险跟踪过程•监视风险设想•对比项目状态与风险阈值•风险信息的通知•报告风险度量山东大学计算机学院312.6风险应对•风险应对的依据•风险行动计划•风险应对的成果•风险状态•校正行动•问题防范•风险应对过程•对触发事件做出反应•执行风险行动计划•对照计划报告进展•修正与计划的偏差山东大学计算机学院322.7风险管理验证•评审风险管理计划•审计执行者及其典型产物•生成审计报告•跟踪行动项目3案例分析•以一个教育管理系统项目为例。某教育管理系统项目是一个基于J2EE技术的Web应用项目。它主要为个公司或者一个部门的所有员工提供教育培训的管理。这个项目的需求来自一家大型公司，我们要在规定期限内提交产品，并保证软件的质量。这里我们将探讨软件项目风险管理等内容在软件项目管理中的具体应用，总结出一些有价值的软件项目管理经验，为以后在软件项目中实施项目管理提供了有益的借鉴。教育管理系统项目项目被划分成多个较小的模块或单元，分配给项目的各个小组的成员，每个小组成员承担一个或几个任务。首先是子系统和模块的分解，子系统和模块的分解着重于功能，本系统的分解，依据需求所要求的三个角色的不同操作进行划分。系统被划分员工操作子系统、部门领导管理子系统以及系统管理员子系统这样三个子系统。然后，根据功能，将各个子系统又划分成几个模块。整个教育管理系统的功能划分如图7-1所示。案例分析案例分析•由于风险是在项目开始之后才开始对项目的开发起负面的影响，所以风险分析的不足，或是风险回避措施不得力，都很有可能造成软件开发的失败。风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施，是避免损失的重要环节。下面主要关注软件开发中的主要风险，但是这只是项目风险中的一部分，在资金、预算、合同等方面都存在风险。案例分析•项目过程中在几乎每个阶段都会出现风险。因此，正确评估每个阶段可能的风险是保证项目按时按质完成的重要环节。软件在需求分析阶段、设计阶段、实现阶段以及测试维护阶段等，会出现不同的风险。•需求分析阶段的风险•软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方的引导才能保证需求的完整，再以书面的形式形成《用户需求》这一重要的文档。需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级级地放大，因此本阶段的风险最大。案例分析•设计阶段的风险•设计的主要目的在于软件的功能正确的反映了需求。可见需求的不完整和对需求分析的不完整和错误，在设计阶段被成倍地放大。设计阶段的主要任务是完成系统体系结构的定义，使之能够完成需求阶段的即定目标;另一方面也是检验需求的一致性和需求分析的完整性和正确性。•设计本身的风险主要来自于系统分析人员。分析人员在设计系统结构时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成本的激增。•设计阶段蕴涵的另一种风险来自于设计文档。文档的不健全不仅会造成实现阶段的困难，更会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本升级，甚至是发现的简单错误都无从更正。案例分析•开发测试阶段的风险•软件的实现从某种意义上讲是软件代码的生产。原代码本身也是文档的一部分，同时它又是将来运行于计算机系统之上的实体。源代码书写的规范性，可读性是该阶段的主要风险来源。规范的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到最低限度，从而减小了系统整合的风险。•维护阶段的风险•从软件工程的角度看，软件维护费用约占总费用的55%-70%，系统越大，该费用越高。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。案例分析•在软件系统运营期间，主要的风险源自于技术支持体系的无效运转。科学的方法是有一支客户支持队伍不断收集运行中发现的问题，并将解决问题的方法传