软件工程原理与实践（硕士）课件 08 软件风险管理

高级软件工程

SoftwareEngineering软件风险管理软件项目充满了风险这是一个VUCA的时代、不确定的时代不确定(Uncertain)易变性(Volatile)变化的不确定性复杂(Complex)结果的不确定性模糊(Ambiguous)当前或未来情况的不确定性风险就是不确定的事件2软件项目风险示例威胁用户需求常常被误解，使得项目大量返工突然遇到了以前未发现的技术难题项目范围总是在变，失控了糟糕的计划与估算导致项目严重误期、成本超预算软件有大量的bug，故障频发技术骨干流失了……机会不少用户开始放弃线下会议，而采用在线会议软件甲方有意向增加新的投资刚出现了预训练模型的新技术，据报导不少AI算法的精度大幅度得以提高公司新招聘了新的开发人员另一个项目组刚搭建了持续集成工具链，使得系统集成和上线的速度得到了提升……3软件风险案例分析你们的大作业项目的最大风险是什么？4代码大模型

三维操作系统

Segway自动平衡车02-风险管理的成熟度模型01-基本概念03-风险管理流程5风险的概念风险是一种不确定的事件或条件，一旦发生，会对至少一个项目目标造成影响，如范围、进度、成本和质量。事件可能性影响高风险中等风险低风险小大影响低高可能性事件6软件风险管理软件风险管理的定义：对影响软件项目、过程或产品的风险进行评估和控制的实践过程。软件风险管理是管理和开发软件系统必不可少的要素：软件风险是工作与生俱来的；软件风险随着系统复杂程度的增加而增加；软件风险影响人们实现目标。没有风险管理是最大的风险！7不同的风险承受力投资大小成功的概率1.00.0守成者冒险者风险中立者小大8风险策略被动风险策略（reactiveriskstrategy）被戏称为“印地安那·琼斯学派的风险管理”。印地安那·琼斯在以其名字为影片名的电影中，每当面临无法克服的困难时，总是一成不变地说：“不要担心，我会想出办法来的！”。主动风险策略（proactiveriskstrategy）早在项目启动之前就已经开始了，识别出潜在的风险，评估它们出现的概率及产生的影响，并且按重要性加以排序；然后建立一个计划来预防风险，以及在风险发生时采取有效的应急措施。风险策略的主动度多少才合适呢？这就要看风险的投资回报率。9风险管理的成本和收益风险管理是一种投资，它是为减轻潜在的不利事件或增加潜在的有利事件对项目的影响而采取的一项活动。风险投资回报率（ROIRM）＝收益/成本成本是为风险评估和控制投入的所有资源，包括评估风险、举行风险管理会议、制定和实施风险管理计划、风险发生时的应急措施、报告风险信息等的成本。收益是指实施风险管理后所带来的收益和损失减少。据统计，软件开发的风险投资回报率的基准大于20，因此，对于大多数软件项目，应积极进行主动风险管理。1002-风险管理的成熟度模型01-基本概念03-风险管理流程11风险管理的成熟度模型防范阶段(3)问题阶段(1)缓和阶段(2)机会阶段(5)预知阶段(4)12第一级：问题阶段危机管理、救火模式人们忙于解决问题，没有时间考虑将来风险(威胁)直到演变为问题后才着手处理管理层没有意识到风险，或者对风险可能发生的时间估计有误管理层一听说风险，就责怪报告者，因此大部分人不会报告坏消息我疲于救火!13第二级：缓和阶段引入了风险概念对风险管理了解不多，而且缺乏经验没有有计划地应对风险经理们采用应急计划以减少重大威胁发生的可能性或后果我想知道什么会出错!14第三级：防范阶段风险管理从经理的活动变为小组的活动主动管理，识别和消除威胁的根源大部分人有经验，能识别威胁，但对于如何量化风险没有把握。我想采取行动以便不留遗憾!15第四级：预知阶段量化的风险管理项目小组和客户运用风险管理，以合理的精度量化风险，以便能集中精力解除最关键的风险。主动迎接风险和评估备用方案我想知道成功的机会有多大!16第五级：机会阶段风险不一定是消极的，有风险的地方也蕴藏着机会风险被看作节约费用和比计划做得更好的机会风险，像质量一样，人人有责在开放和没有压力的环境中不断地识别、交流和应对风险我想超过我自已的期望!1702-风险管理的成熟度模型01-基本概念03-风险管理流程18风险管理流程RiskDatabase,RiskConceptsandProcessesLearnControlTrackandReportPlanandScheduleAnalyzeandPrioritizeRiskManagementPlanTopnRisks19RiskStatementIdentify风险识别RiskDatabase,RiskConceptsandProcessesIdentifyLearnControlTrackandReportPlanandScheduleAnalyzeandPrioritizeRiskManagementPlanTopnRisks20RiskStatement风险识别方法核对清单访谈头脑风暴Delphi法会议评审日常输入调查工作小组21项目各阶段典型威胁事件启动阶段计划阶段执行阶段收尾阶段缺少相应专业的专家对需求界定不清没有做可行性研究目标不清没有风险管理计划仓促计划缺少管理层支持职能界定差项目队伍缺乏经验人员技能不够材料短缺人员误工天气影响范围改变项目进度改变环境要求没有适当的控制体系产品或服务质量差客户不能接受成果现金流出现问题风险发生最高时期风险影响最高时期概率影响度时间各阶段典型的风险事件风险价值22十大软件风险(威胁)需求误解缺少上层的支持需求变更失控未能合理管理客户期望值不现实的进度计划和成本预算质量低劣人员薄弱技术和架构风险软件外包失败缺乏足够的用户参与23风险列表（示例）No条件结果1开发进度紧迫可能会牺牲质量换取时间2需求变更频繁大量的返工3开发人员遇到生疏的前端React框架开发时间将拉长4开发团队被分隔在上海和北京两地团队内部的交流将更加困难5开发人员同时担任测试角色更多bug未被发现24风险分析与划分优先级RiskDatabase,RiskConceptsandProcessesLearnControlTrackandReportPlanandScheduleAnalyzeandPrioritizeRiskManagementPlanTopnRisks25RiskStatementIdentify风险分析分析内容风险发生概率和可能性风险影响度风险暴露量=发生概率*影响度预测一组临界点以定义项目终止区域建立预警阈值26可能性定义为百分数、一个词组或一个相对数字五分制词语百分比1极不可能几乎没有机会1-20%2不可能可能不是21-40%3我们怀疑有点可能41-60%4可能我们相信61-80%5几乎一定非常可能>80%27影响度从四个风险因素分析影响度：性能产品能够满足需求且符合于其使用目的的不确定的程度成本项目预算能够被维持的不确定的程度进度项目进度能够被维持且产品能按时交付的不确定的程度支持软件易于纠错、适应及增强的不确定的程度28影响度评估成本进度支持性能低(0~29)低于1%落后1周稍有影响稍有影响中(30~59)低于5%落后2周有一定影响有一定影响高(60~79)低于10%落后1月有严重影响有严重影响关键(80~100)≥10%落后1月以上无法进行支持无法完成任务因素级别29概率－影响矩阵影响概率5102040800.9591836720.7471428560.5351020400.323612240.111248风险暴露量=概率*影响度30风险优先级可按风险暴露量排序，生成粗略的风险优先级列表可将影响最大的风险排在前面可将一些关联的风险排在前面重点考虑前10名的风险31更新后的风险列表(示例)按风险等级从高到低排序等级分类紧迫性条件结果概率影响暴露量高进度中开发进度紧迫可能会牺牲质量换取时间80%6048高需求高需求变更频繁大量的返工60%8048中技术中开发人员遇到生疏的前端React框架开发时间将拉长90%4036中组织高开发团队被分隔在上海和北京两地团队内部的交流将更加困难80%4032低角色低开发人员同时担任测试角色更多bug未被发现80%201632风险管理计划RiskDatabase,RiskConceptsandProcessesLearnControlTrackandReportPlanandScheduleAnalyzeandPrioritizeRiskManagementPlanTopnRisks33RiskStatementIdentify威胁的应对策略上报。如果某威胁不在项目范围内，或提议的应对措施超出了项目经理的权限，就应采用上报策略。规避。采取行动来消除威胁或不受之影响。转移。把某风险的部分或全部消极影响连同应对责任转移给第三方。减轻。把不利风险事件的概率和/或影响降低到可接受的临界值范围内。接受。因为几乎不可能消除项目的全部威胁，所以就需要采用风险接受策略。被动接受风险，只需要记录本策略，而不需要任何其他行动；待风险发生时再由项目团队进行处理。主动接受策略是建立应急储备，安排一定的时间、资金或资源来应对风险。34机会的应对策略上报。如果某机会不在项目范围内，或提议的应对措施超出了项目经理的权限，就应采用上报策略。开拓。采取行动来确保把握住高优先级的机会。分享。将应对机会的责任转移给第三方，使其享有机会所带来的部分收益。提高。提高机会出现的概率和（或）影响。接受。承认机会的存在，但不主动采取措施。被动接受风险，只需要记录本策略，而不需要任何其他行动；待风险发生时再由项目团队进行处理。主动接受策略是建立应急储备，安排一定的时间、资金或资源，以便在机会出现时加以利用。35风险应对措施示例1

使用公司后备风险基金（接受）在项目预算中设置不可预见费（接受）购买商业保险（转移）必要时补充或修改合同条款保证公司的利益（减轻）必要时可以将合同中风险较大的那一部分分包出去（转移）多种技术方案（减轻）选择低风险方案（回避）对已经发生严重延期的项目紧急补充人力（接受）36风险应对措施示例2风险#1：进度风险a.减轻：采用历史数据，基于经验模型进行科学的估算，和项目干系人进行有效沟通，建立切合实际的进度计划；对需求划分优先级，采用迭代开发过程，优先级高的需求在前面的迭代实现，同时通过迭代使集成和测试提前，以保证质量。b.接受：当进度落后超过10%时，及时分析原因，进行改进；当进度落后超过20%时，删除一些优先级最低的需求，决不牺牲质量。371）需求误解后果开发出的软件被客户否定而不得不返工。原因开发人员与客户的交流不够顺畅；客户未能把其需求准确、完整地陈述出来，遗漏了一些需求；自然语言表述的需求具有严重的二义性，使不同的读者对其的理解不一致；客户不能完全理解开发人员撰写的需求规约文档，未能发现需求的许多缺陷等。缓解措施采用访谈、研讨会、问卷调查等多种方式开展充分的需求调研，尽可能全面完整地获取需求；细致分析需求，建立术语表，使用详尽、准确的词汇描述需求，采用UML等（半）形式化语言进行需求建模；建立界面原型，以形象易懂的形式和用户进行沟通，获得用户的反馈；组织客户、最终用户、架构师、测试工程师、领域专家等对需求进行评审，尽早发现需求的缺陷；早期编写用户手册和测试用例，也是验证需求的一种有效方法。382）缺少上层的支持后果组织内部的其他上层人员会强迫项目组接受不现实的项目目标，或者进行不合理的变更，造成项目的失败。缓解措施和上层进行积极沟通，了解、理解和满足上层的需求和期望；让上层了解项目的意义和重要性，以获得上层的重视；有计划、高质量地开发软件，切实履行承诺，以获得上层的信任；定期向上层汇报项目进展和风险状态，提供项目良好的可视性；遇到问题，能提出建设性意见或解决方案，而不是停留在抱怨或反映的层面；适时向上层正式和非正式地培训软件开发过程和方法，使其能支持有效的软件开发实践。393）需求变更失控后果对项目的进度、人力资源、经费、质量等产生很大的影响原因变更是软件开发所固有的，平均每个软件项目会有25%的需求变更。可能对需求有了更深入的认识、市场可能发生变更、项目的资源可能发生变动、以及发现了需求中的缺陷需要纠正等等。缓解措施开展充分的需求调研，尽可能完整地、准确地获取和定义需求，以避免由于错误而变更需求；把需求排出优先级，根据项目进度和预算，选择优先级高的需求，建立一个与目标一致的需求基线；采用迭代开发过程，优先级高的需求在前面的迭代实现。当需求发生变更时，把变更的需求和现有的需求放在一起，重新排序。若进度来不及时，可抛弃优先级最低的需求；按变更控制流程对需求变更进行有效的控制，确保采纳最合适的变更，使变更产生的负面影响减少到最小；采取针对变更的设计策略，例如模块化、信息隐藏等，提高软件的可维护性，使变更引起的修改尽可能限制在局部范围内。404）未能合理管理客户期望值后果软件开发中的诸多问题，大都源于客户对项目持有的不现实的期望。StandishGroup的一项调查表明，10%的项目由于这个原因被取消了。缓解措施了解并理解客户的需求和期望。客户的要求分为明确的需求和隐含的期望，如果我们只是了解并努力满足客户的需求，最多只能达到客户一般的满意水准，要能使客户非常满意或是给客户带来喜悦，应更好地了解并理解客户的期望；培训客户以使他们更好地理解软件开发过程。客户对开发的认识，有助于开发人员和他们一起商讨建立合理的、现实的项目目标和计划；开发人员应采用历史数据进行科学的进度和成本估算，尽量客观准确地设定自己的期望，不要盲目乐观，以免客户有不现实的期望。415）不现实的进度计划和成本预算后果让开发人员缩短关键性的前期开发活动，例如需求和设计，从而导致后期大量的返工；同时它也向开发人员施加了额外的压力，给开发人员的自信和生产率造成长期的、巨大的伤害。缓解措施详细分析需求，采用历史数据，基于经验模型进行科学的估算。可由多个估算师独立估算，再进行综合；和项目干系人进行有效沟通，根据估算和目标，选择优先级高的需求，确定项目范围，建立切合实际的进度计划；采用迭代开发过程，把优先级高的需求在前面的迭代实现。当进度延误时，宁可取消优先级低的需求，也不牺牲质量；采用基于复用的软件开发方法，在需求、设计、编码、测试和管理等多个方面复用已有的成果，例如：框架、设计模式、构件、代码、测试案例等等。通过复用，可以节省成本，加快开发进度；同时这些可复用成果在多个应用中被反复使用，质量更好。426）质量低劣后果当项目达到功能完成的里程碑时，不得不为质量而大量返工，其代价是原来的3~10倍。原因当开发进度紧张、预算和资源不足等情况下，开发人员常常会减少质量保证措施，牺牲质量。缓解措施开展多层次的测试，包括单元测试、集成测试和系统测试，特别对易错模块重点进行测试。这些易错模块仅占总代码量的20%，但却隐藏了80%的缺陷；对需求、设计、源代码、计划和测试用例等进行评审，评审的方法有审查、走查、结对评审、桌查、轮查、小组评审等；采用迭代开发过程，让测试提前进行，及早发现问题；除此之外，还有静态分析、质量审核、形式化证明等技术，都能有效保证质量。437）人员薄弱现象人数不足人员的能力欠佳士气低下缺乏各种角色的齐心协力人员流失率过高后果极大影响了开发的进度、成本和质量。缓解措施招聘高级人才。不同软件开发人员的生产率水平会相差10倍甚至20倍，因此，在软件行业中，招聘1个“诸葛亮”可以顶上20个“臭皮匠”，同时还节省了管理和沟通成本；开展团队建设，激励士气，培养高业绩团队；进行有计划的培训，不断提升人员的能力和素质；在项目启动前，提前预定关键的开发人员，确保足够的核心人员；必要时，可以和其他组织合作，通过人员外包方式增加开发人手；留住人才，帮助其不断成长。448）技术和架构风险后果如果技术方案或软件架构不妥，就会导致软件大规模的返工；如果过高估计新技术或方法带来的效率，就会导致采购浪费和过于乐观的计划。缓解措施评审。组织技术人员和专家等，对技术方案或软件架构进行评审，及早发现缺陷；可行性原型。如果预计采用的技术和架构对项目组来说是新的，或者在新领域中进行应用，则应预先开发技术（或架构）原型，验证通过了才能采用；向专家咨询。咨询已掌握该技术或架构的专家，这能使项目组快速学习和掌握新的知识。459）软件外包失败现象外包方推迟交付时间交付的软件质量低下而无法满足预计要求。缓解措施采有模块化方法设计软件结构，并确保设计质量，使外包的部分尽可能独立，需求稳定，接口明确；确定一名专门的外包负责人负责建立和管理外包；从技术手段、管理方法、历史绩效、价格等多方面综合评价外包方的能力，从中选择合格者签约；在外包执行过程中，跟踪监督外包方的开发（包括进度、质量、资源等），协商解决有关变更，定期进行阶段评审；在外包结束时，按合同进行验收测试，包括功能测试、性能测试、易用性测试、可靠性测试、可支持性测试和交付文档检查。4610）缺乏足够的用户参与现象用户常常由于业务过忙或者对需求分析不够重视，使得参与人员的数量、能力或时间不足，甚至选派新手作为用户代表。开发人员也可能不重视用户的参与后果项目充满着需求误解的