2016年SPM05-软件项目风险管理

1、2016年SPM05-软件项目风险管理第一页，共74页。5.1.1 风险SEI将风险定义为损失的可能性。风险具有两大属性：可能性和损失。可能性是指风险发生的概率，损失是指预期与后果之间的差异。风险的根源在于事物的不确定性。第二页，共74页。软件风险管理的相关概念目标:明确定义的目标界定了可接受的风险范围。不确定性:未知的因素。损失:没有潜在的损失，就没有风险时间 选择决策应对风险 第三页，共74页。导致软件风险的原因进度过分紧迫；预算过分紧张；性能过分的超群，软件可靠性要求过高；人员缺乏经验，组织结构不适宜；期望过高而不现实；没有明确或理解合同的条款；软件规模估计不恰当；管理部门缺乏经验；风险

2、分析和管理不恰当；缺乏政策性支持；不熟悉技术或过程；不熟悉必要的硬件；需求不一致（或定义不充分）；需求不断变动；软件开发计划不恰当；软件开发过程模型不适用；缺乏软件工程技术和方法；缺乏自动化工具的支持6.1 软件项目风险管理概述第四页，共74页。5.1.2 软件风险软件风险由管理过程风险和技术过程风险组成第五页，共74页。5.1.3 软件项目风险管理风险管理与项目管理的关系可归纳如下：从项目的成本、时间和质量目标来看，风险管理与项目管理的目标一致。从项目管理的计划职能来看，风险管理为项目计划的制定提供了依据。从项目的成本管理职能来看，项目风险管理通过风险分析，指出有哪些可能的计划外费用。从项目

3、实施过程来看，许多风险都在项目实施过程中由潜在变为现实。定出风险反应计划。第六页，共74页。风险管理与项目管理的关系 目标一致为项目计划的制定提供了依据是成本管理的一部分许多分析都在项目实施过程中由潜在变为现实6.1 软件项目风险管理概述采购 计划风险 计划沟通计划人力 计划质量计划 成本 计划时间计划集成计划范围计划 项目 结束项目执 行控制 项目 计划 项目 初始第七页，共74页。第八页，共74页。风险管理的主要内容【概述中提到】1、制定风险管理计划2、风险识别3、风险分析4、风险计划5、风险跟踪6、风险应对7、风险管理验证第九页，共74页。5.1.4 软件项目风险管理意义141通过风险分

4、析,了解风险对项目的影响.为以后的规划与设计工作提供反馈，以便采取措施防止与避免风险损失。可推动项目管理层和项目组织积累风险资料，以便改进将来的项目管理。 第十页，共74页。风险管理是指在项目进行过程中不断对风险进行识别、评估、制定策略、监控风险的过程。通过风险识别、风险分析和风险评价去认识项目的风险，并以此为基础合理地使用各种风险应对措施、管理方法、技术和手段对项目的风险进行有效的控制，妥善处理风险事件造成的不利后果，以最小的成本保证项目总体目标的实现。第十一页，共74页。5.2 风险识别是试图通过系统化的方法寻找可能影响项目的风险（已知的和可预测的）以及确认风险特性的过程。目标是：辨识项目

5、面临的风险，揭示风险和风险来源，以文档及数据库的形式记录风险。活动包括：风险识别方法的确定；风险定义及分类；风险文档编写。第十二页，共74页。项目识别的依据项目计划历时经验外部制度制约项目内部的不确定性第十三页，共74页。风险识别的输入、输出输入标识风险评审风险输出风险列表项目的WBS、工作的陈述（Statement Of Work，SOW）、项目相关信息、项目计划假设、历史项目数据，其他项目经验文件、评审报告、公司目标等。第十四页，共74页。风险识别参与人员项目组成员风险管理人员学科专家（组织内）客户项目的其他管理人员外部专家第十五页，共74页。常见软件风险【142-143】人力资源风险需求

6、风险项目接口风险设计风险管理风险开发过程风险项目集成与测试风险第十六页，共74页。风险识别过程进行风险评估系统地识别风险风险定义及分类确定风险驱动因素将风险编写为文档第十七页，共74页。风险识别方法德尔菲方法头脑风暴法情景分析法面谈法会议法SWOT分析法风险条目检查表第十八页，共74页。头脑风暴法召开项目组全体会议，进行关于项目风险的自由讨论，项目组成员在主持人的引导下完全自由地发言，不受限制，产生关于项目风险的概念。坚持不进行过多讨论，不对别人的意见进行判断性评论，甚至明确不许使用身体语言表达评判意见，如：咳嗽、冷笑等。险管理人员将会议结果进行分类整理，作为风险的基础和其他风险识别方法的结果

7、一起提交风险分析。第十九页，共74页。情景分析法通过对系统内外相关问题的系统分析，设计出多种可能的未来前景，然后用类似于撰写电影剧本的手法，对系统发展态势做出自始至终的情景和画面的描述。可用情景分析法来预测和识别其关键风险因素及其影响程度。第二十页，共74页。SWOT分析法(Strength, Weakness, Opportunities, and Threats) 是综合分析项目内部优势、弱势和项目外部机会与威胁的技术。SWOT作为一种系统分析工具，其主要目的是对项目的优势与劣势、机会与威胁各方面，从多角度对项目风险进行识别。第二十一页，共74页。风险条目检查表利用一组提问来帮助管理者了解

8、项目在各方面有哪些风险。检查表中，列出了所有可能的与每一个风险因素有关的提问，使得风险管理者集中来识别常见的、已知的和可预测的风险条目检查表一般根据风险要素进行编写，建立软件项目的风险条目列表，包括项目的环境、管理层的重视度、技术情况以及内部因素(如团队成员的技能或技能缺陷等)。 第二十二页，共74页。第二十三页，共74页。一、产品工程类Requirements（需求）Stability（稳定性）Completeness（完整性）Clarity（清晰）Validity（有效性）Feasibility（可行性）Precedent（案例）Scale（规模）第二十四页，共74页。Design（设计）

9、Functionality（功能性）Difficulty（困难）Interfaces（接口）Performance（性能）Testability（可测试性）Hardware Constraints（硬件约束）Non Developmental software（非开发软件）第二十五页，共74页。Code and Unit test（编码和单元测试）Feasibility（可行性）Testing（单元测试）Coding/Implementation（编码/实现）Integration and Test（集成和测试）Environment（环境）Product（产品）System（系统）第二十六页

10、，共74页。Engineering Specialties（工程特点）Maintainability（可维护性）Reliability（可靠性）Safety（安全性）Security（保密性）Human Factors（人的因素）Specification（特定性）第二十七页，共74页。二、Development Environment（开发环境）Development process（开发过程）Formality（正规性）Suitability（适宜性）Process Control（过程控制）Familiarity（熟悉程度）Product control（产品控制）第二十八页，共74页。

11、Development System（开发系统）Capacity（生产量）Suitability（适宜性）Usability（可用性）Familiarity（熟悉度）Reliability（可靠性）System Support（系统支持）Deliverability（可交付性）第二十九页，共74页。Management Process（管理过程）Planning（计划）Project Organization（项目组织）Management Experience（管理经验）Program Interfaces（项目接口）第三十页，共74页。Management Methods（管理方法）Mon

12、itoring（监控）Personnel Management（人事管理）Quality Assurance（质量保证）Configuration Management（配置管理）第三十一页，共74页。Work Environment（工作环境）Quality Attitude（质量态度）Cooperation（合作）Communication（交流）Morale（士气）第三十二页，共74页。三、Program Constraints（项目约束）Resources（资源）Schedule（进度）Staff（人员）Budget（预算）Facilities（设施）第三十三页，共74页。Contra

13、ct（合同） Type of Contract（合同类型）Restriction（约束）Dependence（依赖关系）第三十四页，共74页。Program Interfaces（项目接口）Customer（客户）Associate Contractors（联合承包方）Subcontractors（子承包方）Prime Contractor（主承包方）Corporate Management（共同管理）Vendors（供货商）Politics（策略）第三十五页，共74页。5.3 风险分析提炼风险背景，确定风险来源，确定行动时间框架和确定前10相首要风险名单5.3.1 风险分析过程第三十六页，共

14、74页。5.3.1 风险分析过程定义风险度量准则预测风险影响评估风险对风险进行排序制定风险计划【设想、应对】第三十七页，共74页。分析风险发生的概率，确定发生的可能性（P）风险后果，发生后对项目目标的影响（I）风险值，风险的严重程度R=F(P,I)确定优先次序按风险的严重性排序确定最需要关注的TOP 10风险第三十八页，共74页。前10位首要风险列表第三十九页，共74页。制定风险计划第四十页，共74页。风险列表示例第四十一页，共74页。5.3.2 风险分析技巧与工具一般，在定性风险分析之后就可以进行定量风险分析。定量风险分析量化分析每一个风险的概率及其对项目目标造成的后果，也分析项目总体风险的

15、程度。方法：访谈、因果关系分析、决策树分析、模拟法第四十二页，共74页。因果关系分析第四十三页，共74页。决策树分析提供项目所有可供选择的行动方案，行动方案之间的关系，行动方案的后果以及发生的概率提供选择一个最佳的方案的依据损益期望值(Expected Monetary Value，EMV)是决策树的一种计算值，根据风险发生的概率计算例如：某行动方案成功的概率是50%，收益是10 EMV=1050%=5第四十四页，共74页。决策树分析风险值？EMV=0失败：P=30%, outcome= -200000 成功：P=70%EMV=9500070%=66500实施后：EMV=6500不实施EMV=

16、-20000030%=-60000低性能：P=70%, outcome=-100000EMV=-10000070%=-70000高性能：P=30%, outcome=550000EMV=55000030%=1650006.3 风险评估第四十五页，共74页。决策树分析例子6.3 风险评估第四十六页，共74页。差距分析法【151】帕累托分析法敏感度分析法【152】第四十七页，共74页。5.3.3 分析成果6.3 风险评估第四十八页，共74页。5.4 风险跟踪与应对5.4.1 风险跟踪的目标和依据5.4.2 风险跟踪的成果5.4.3 风险跟踪的过程第四十九页，共74页。风险控制通过对风险的规划和对项

17、目全过程的控制，保证风险管理能达到预期的目标。其目的是核对风险管理的策略和实施的实际效果是否和预见相同，同时获取反馈信息，改善风险计划和管理。第五十页，共74页。5.4.3 风险跟踪的过程监视风险设想对比项目状态与风险阈值风险信息的通知报告风险的度量第五十一页，共74页。风险度量及定义6.5 风险控制第五十二页，共74页。风险应对计划（top 10 清单）6.5 风险控制任务可能的风险产生的阶段产生的原因避免的措施后处理制定设计阶段的规范和标准时间风险项目准备需制定的规范和标准较多，而同时需完成其他工作，使得可使用的时间和资源有限开发环境确认资源风险系统设计由于设备未到位导致延误开发管理系统设

18、计技术风险系统设计基于TeMIP平台开发SDH专网管理系统对于公司乃至国内都是全新的课题，由于技术的掌握程度和经验仍很欠缺在系统设计前请TeMIP专家进行相关培训换成其他的技术实现第五十三页，共74页。应对计划（top 10 清单）实例（续）任务可能的风险产生的阶段产生的原因避免的措施后处理对功能规格和系统设计的调整时间风险0版本开发评测结果对功能规格和系统设计影响较大0版本开发时间风险0版本开发由于学习曲线过长延误时间系统测试资源风险0版本开发开发人员与SQA人员对工作站和服务器使用的争夺MD现场调试资源风险1版本开发由于设备问题延误现场调试现场运行环境确认资源风险2版本开发由于设备问题延误

19、验收测试的进行第五十四页，共74页。风险管理是一个连续的过程6.5 风险控制第五十五页，共74页。5.4.4 风险应对策略避免是指通过改变项目计划或条件完全消除项目风险或保护项目目标不受风险影响。转移是指风险转移给另一方去承担。缓解是指寻求降低一个不利风险事件的发生概率或使它产生的后果达到一个可接受的水平接受是指有意识地选择承担风险后果，或者项目组找不出任何风险反应策略。风险研究是指通过调查研究以获得更多信息的风险应对策略。风险储备是指对项目意外风险预留应急费用和进度计划。假如风险影响巨大，或者采取的措施不完全有效，这种情况下就要开发风险退避计划。第五十六页，共74页。5.4.5 风险应对过程

20、对触发事件作出反应【定期事件、时间、相对变化、阈值触发器】执行风险计划对照计划，报告进展修正与计划的偏差第五十七页，共74页。5.5风险管理验证评审风险计划：计划的质量一定程度上决定着结果的质量。计划应满足下列要素：完整性、可理解性、详细程度、 一致性、现实性审计管理过程【三种标准：ISO9000、SEI-CMM和MIL-STD-498】风险管理回报第五十八页，共74页。5.6 风险管理实践以一个教育管理系统项目为例。某教育管理系统项目是一个基于J2EE技术的Web应用项目。它主要为个公司或者一个部门的所有员工提供教育培训的管理。这个项目的需求来自一家大型公司，我们要在规定期限内提交产品，并保

21、证软件的质量。教育管理系统项目项目被划分成多个较小的模块或单元，分配给项目的各个小组的成员，每个小组成员承担一个或几个任务。第五十九页，共74页。功能分解第六十页，共74页。风险分析风险分析是在事前的一种估计，凭借一定的技术手段和丰富的经验，基本能够对项目的风险做出比较准确的估计，经过慎重的考虑提出可行的风险回避措施。下面主要关注软件开发中的主要风险，但是这只是项目风险中的一部分，在资金、预算、合同等方面都存在风险。项目过程中在几乎每个阶段都会出现风险。正确评估每个阶段可能的风险是保证项目按时按质完成的重要环节。第六十一页，共74页。问题：请分析软件开发各个阶段的风险第六十二页，共74页。需求

22、分析阶段的风险以用户的需求开始，以书面的形式形成 用户需求。需求分析更多的是开发方确认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级级地放大，因此本阶段的风险最大。第六十三页，共74页。设计阶段的风险需求分析的不完整和错误，在设计阶段被成倍地放大。设计阶段的主要任务是完成系统体系结构的定义，使之能够完成需求阶段的即定目标；另一方面也是检验需求的一致性和需求分析的完整性和正确性。设计本身的风险主要来自于系统分析人员。分析人员在设计时过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担。 设计阶段蕴涵的另一种风

23、险来自于设计文档。文档的不健全，这不仅会造成实现阶段的困难，更会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本升级，甚至是发现的简单错误都无从更正。 第六十四页，共74页。开发测试阶段的风险软件的实现从某种意义上讲是软件代码的生产。代码本身也是文档的一部分，同时它又是将来运行于计算机系统之上的实体。源代码书写的规范性，可读性是该阶段的主要风险来源。规范的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到最低限度，从而减小了系统整合的风险。第六十五页，共74页。维护阶段的风险从软件工程的角度看，软件维护费用约占总费用的 55%-70%。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内，业务规则肯定会不断发展，科学的解决此问题的做法是不断对软件系统进行版本升级，在确保可维护性的前提下逐步扩展系统。在软件系统运营期间，主要的风险源自于技术支持体系的无效运转。科学的方法是有一支客户支持队伍不断收集运行中发现的问题，并将解决问题的方法传授给软件系统的所有使用者。第六十六页，共74页。体系结构方面的风险本项目采用J2EE技术和三层结构，在技术的成熟度上来说，不存在风险。但是，在实现上，对开发人员的技术要求，以及在实现良好的软件构架和稳定的组件方面，也存在风险性。软件体系结构影响到软件的如下质量因素：软件的可伸