软件开发的风险管理

1小组软件开发过程TSPi软件开发的风险管理有位项目经理，曾经和他太太在天黑后上了未完工的19层楼，不巧遇上停电，一片漆黑中，感到危险，最后还是选择抹黑爬下19层楼，⊙﹏⊙b汗把摸黑下楼比作风险，可以规避它，拿一把手电，白天再来？。。。。。如果多一点风险意识，及早采取办法，就好了！没有风险意识，怎么未雨绸缪，若幸运女神不垂青，惨就一个字！全局意识，管理好了风险，可以避免手忙脚乱，少一些救火的事，一切尽在掌握！6项目案例案例角色和人物小王：软件项目负责人老王：公司技术老总开发小组：小李，老赵，小田，小谢7项目实施存在风险(1/4)项目已成功实施1个月，某天小谢突然告诉小王，他已办理好了去德国的签证，2周后他会辞职离开公司前往德国留学（人员）小谢的离开显然将会影响项目组的正常运作，影响项目的进度，为此将会给项目的实施带来损失可以想象，2周以后小谢的离开将会带来一系列问题：谁来接替小谢的工作？在此之前谁来负责交接小谢的工作？如何尽可能的避免由此给项目组带来的损失(包括进度损失和工作损失等)尽管还没发生，但必须考虑如何避免问题的发生，以及一旦发生后该采取得措施，以便将损失减少到最少8项目实施存在风险(2/4)按照软件开发计划，需求分析应该在12月31日之前完成，然而在软件项目实施过程中项目经理发现，由于原先对工作量估算过于乐观，需求分析在12月31日之前已经不可能完成（计划）显然，原先计划制定的不科学和不准确，导致了实施过程中进度难以控制，如果强行按照计划来执行显然是不可行的，为此，必须对计划重新进行分析和调整9项目实施存在风险(3/4)在软件设计阶段，软件设计负责人老王发现，用户需求中的某项需求(例如，将已有word文档的内容显示在Web页面上)至今尚未找到解决的技术途径（技术）显然，该问题将直接影响软件项目的后续开发工作，影响到软件项目能否成功完成10项目实施存在风险(4/4)在需求分析过程中，老王带领的需求分析小组和用户在进行交流的过程中发生了矛盾，出现了争吵，用户方说将不再配合需求分析小组的工作，而且他们确实没有配合开发方的工作（合作）显然，开发方和用户方出现这种状况显然是双方没有想到的这种状况延续下去必将对软件项目的实施产生影响，影响软件项目的进度，甚至会导致项目失败11案例提示我们风险在项目实施过程中大量存在软件风险形式多样软件风险事先难以确定软件风险会对软件项目的实施产生不良影响如果不对风险进行良好的管理，项目就很难保证按照计划、在成本和进度范围内，开发出高质量的软件产品，甚至会导致项目失败内容向导什么是软件风险风险管理的目的风险管理的基本原理当前项目的top10风险及规避方法■风险

定义

•

字典：“失败或者受伤的可能性”

魏氏字典,第10版

•

一般定义：将要发生的问题•

特征

•

隐含于任何一个项目中

•

从本质上来说，不是好的也不是坏的

•

不是可怕的，而是可管理的■风险的来源

风险可能来自多个方面:任务和目标决议制订者或者组织的管理客户或者最终用户预算，花费，进度和人事开发进程和环境新技术■风险的影响

风险可从不同的方面影响项目超支和进度赶不上功能不全项目取消突然的人事变动或团队士气受挫客户的不满意损害公司形象产品性能低下法律问题16一、什么是软件风险？

什么是软件风险？使软件项目的实施受到影响和损失、甚至导致失败的、可能会发生的事件例如，人员的临时流失，计划过于乐观，设计的低劣软件风险的特点事先难以确定带来损失，影响项目实施，甚至会导致项目失败17什么是软件风险管理?在风险影响软件项目成功实施前，对它进行识别和处理，并预防和消除风险的发生识别风险(会有哪些风险？)预防和消除风险(最好别让风险发生)制定风险发生后的处理措施(万一发生该怎么办？)二.风险管理的目的1.试图系统化地瓦解不确定因素对项目计划（质量、预算、进度、资源分配等）的威胁2.通过风险的管理变被动的面对风险，即消防状态为主动面对风险，即钓鱼状态。3.知道什么是紧急事件，让我们能够依据FIRSTTHINGFIRST的原则处理紧急事件1.识别二.风险管理的基本原理风险陈述2.分析3.计划4.跟踪风险Top105.控制风险消除整个过程的核心依据是需要一个不断优化更新的风险评估文档20风险管理的组成(1/3)风险管理风险评估风险控制风险识别风险分析风险优先级风险管理计划风险化解风险监控■

风险评估文档

￭作为剑，它是一个决策,使得：区分努力的优先次序。￭作为盾，它通过教育和自动的调整保护项目以免于：由管理做的随意改变滥定日期死板的项目变元整理团队的风险管理，并做成专门的文档,要从风险管理获得最大的收益，使用风险评估文档可以：■风险评估文档内容

■识别风险

风险识别：风险识别为项目团队将风险提到表层提供了机会和所需的信息。由于风险识别涉及所有的主要团队成员，因此，这也向团队显示了这些成员所持的设想和观点。风险识别的一个重要方面就是团队应该把它看作一个积极的而非消极的行动。有效识别风险的方法：从两个方向检查风险 ￭潜在的问题和可能的结果 ￭潜在的结果和可能的原因发现和认识项目潜在的问题如：认识到火灾是仓库的一个潜在风险■风险陈述￭在一个风险被管理前：它必须被清楚陈述，包括发生条件和结果——有效把握它必须易理解多个风险是否组成一个根本的问题￭条件－结果风险陈述帮助清晰明白地说明风险

条件易燃液体储存在仓库

结果仓库可能失火所以■风险分析

有效分析风险：估计风险的可能性估计风险的影响计算风险的威胁度项目团队从收集有关的风险原始数据转入对风险的分析。将风险数据转化成为风险做决策的信息（何种行动？）如：理解在仓库中易燃液体可能导致火灾的可能性？

将造成多大的损失？■评估风险可能性

分配一个值以代表这种可能性： ￭为了简便计算使用数值等级 ￭为你的项目选择运用起来最好的间隔尺度，但在整个项目中使用同样的等级 ￭

描绘了一个主观的数值等级如：High=3,medium=2,low=1

如：High=75％,medium=50%,low=25%

评估风险发生的可能性如：理解由于仓库放着易燃物,所以发生火灾的可能性很大

■

评估风险的影响分配一个值以代表损失的数量： ￭

为了简便计算使用数值的等级 ￭为你的项目选择运用起来最好的间隔尺度,但在整个项目中使用同样的等级 ￭描绘了一个主观的数值等级

如：High=3,medium=2,low=1

估计如果风险发生将造成的损失的严重性和大小如：理解仓库烧光将是多严重的后果■计算风险威胁度分配一个值以代表威胁的数量：

•

使用该公式计算（可能性×影响＝威胁度)

如：3×3＝9

•

利用它比较风险优先级

•

基于最高威胁度的值排列风险及对它们管理

量化每个风险构成的全面的威胁■创建一个10大风险列表

团队要关注高优先级的风险：•

将主要风险的数目限制在10个或者更少•

定期回顾列表——才见成效•

使列表保持更新以便显示优先级的改变用一个列表形式来识别最高优先级的风险30■创建一个10大风险列表统计表明，项目80%成本用于解决20%的问题风险管理重点关注20％重要的部分根据风险的危险度确定风险的重要性，忽略其他的部分

帕金森法则（Parkinson'sLaw）如果给你24小时去完成一项任务，时间的压力促使你集中精力去执行，别无选择只能做最重要的部分。同样的任务，如果给你1周去完成，它就换来了小题大作的6天。如果给你2个月的时间，但愿不要这样，它就变成了一场精神磨难。因为精力更高度集中，短时限内做出的最终产品通常不比长时限内做出来的差，甚至质量更高。1．只做重要的事情以减少工作时间（80/20法则）。2．减少工作时间来做最重要的事情（帕金森法则）。31■风险控制针对每一个重要的风险，制定一个处理该风险的计划风险由谁引起表现形式是什么可能什么时候发生为什么发生如何避免或者消除它的发生发生后的处理措施■设计风险计划•

考虑5个主要方面

•

调查：您对风险了解的足够多吗？

•

承受度：您能忍受它的结果吗？

•

避免：您能避免该风险吗？

•

缓解：您能减小发生的可能性吗？

•

应急：您能减少影响吗？阐明怎样防止和减小风险的发生及如果发生应该怎么做如：计划怎样防止仓库失火及若失火该怎么办？33风险管理计划例子，小谢将在项目实施过程中离开公司**项目组的小谢项目组成员小谢由于出国离开公司小谢可能会在6月1日前后出国为了进一步学习和深造和小谢协商能否在项目结束之后(大约7月中旬)离开如果离开，计划让小王接替他的工作，同时让小刘分担小王的一部分工作■缓减风险减小风险威胁度

•

关注高威胁度级别的风险

•

处理风险发生的条件以减少可能性

•

寻找风险的根本原因而非现象

•

处理结果以减小影响提前计划和采取行动将风险威胁度控制在可接受的级别如：创立无烟方针以减少失火的可能性■风险缓解策略减少风险 如：减小可能性（条件的可能性）用防火材料 如：减小影响（结果级别）安装自动洒水装置转移风险 如：改用不同的硬件和第三方订约保证防火安全 如：转包到第三方避免风险 如：不承接一定的项目 如：使用被证明过的、非前沿的技术36风险化解(1/2)风险化解方式避免风险：推迟小谢的离开时间将风险从系统的一部分转移到另一部分：让客户来做消除发生风险的根源：加薪发布风险：不会突然和惊讶接受和控制风险：接受并提供处理计划，安排小王接替小谢的工作记录风险：为将来项目风险管理提供历史数据37风险化解(2/2)■风险应急计划减小发生的事情的影响：关注高威胁度的风险，对那些不可缓解又影响深厚的风险应该特别注意。为了有效地管理风险，团队应提前做好应急计划计划好对后果做怎样的反应以减小影响设置触发器来决定执行计划的时间

陈述若风险发生您将怎么办，注重风险发生的后果和怎样减小风险的影响。如：呼叫消防队以扑灭仓库的火灾39风险应急计划危机管理救火模式，风险造成麻烦后才着手进行处理例如，小谢离开公司1个月后，其他小组需要小谢所负责子系统的模块以便进行集成和测试，但是相关代码还没写，此时已经影响其他小组计划和项目进度，为此抽调其他人接替小谢工作■设置应急触发器选择恰当类型的触发器时间点

如:若一个主要团队成员离职,培训一个取代者的最近时间极限

如:当故障数达到一定的水准,就得雇佣更多的测试者

决定执行应急计划的标准如：让火灾的物理迹象提示人应呼叫消防队■风险追踪(监控)有效追踪风险:将风险追踪看作整个项目生命期都要进行的作业追踪风险发现其条件和后果的改变衡量缓解计划的效果监视应急触发器风险追踪要求确保有效的行动计划实施。

监控风险和它们的缓解计划如：回顾为优先级改变而列举的10条顶端风险42■风险追踪(监控)检查风险的化解程度及其变化(概率、损失)风险监控的方式监控和跟踪重要的(前10个)风险，记录风险危险度的变化以及风险化解的进展中间审查，在每个里程碑后进行小规模的走查任命风险官员(适合于大项目)，警告项目风险，防止项目经理和开发人员忽略计划中的风险管理■风险控制

要有效控制风险：适应风险优先级的改变反应到计划的变动▉撤掉风险

撤走风险的原因风险已经发生风险已经解决风险及其管理计划已经存档从活动的风险管理过程中移走风险■成功的风险管理

•

在整个项目生命周期中连续地评估风险使用基于风险的决策制定法建立一些正式的标准涉及包括业务和技术领域在内的所有关键人员和过程.积极对待风险识别(积极、有价值/无意义)46例子:风险列表47风险分析评估风险发生的概率估算风险造成损失的大小计算风险危险度(RiskExplosure)48评估风险发生的概率(1/2)主观性较强，采用方法熟悉系统、有经验的人参与评估多人独立评估，综合折中采用分类：非常可能(3)很可能(2)不太可能(1)不可能(0)49评估风险发生的概率(2/2)50评估风险发生造成的损失可以基于“进度”，“成本”或者“工作量”来进行估算51计算风险危险度风险危险度=风险概率×风险损失52风险优先级(2/2)三.软件项目常见风险的分析和规避1.产品定位错误（包括市场定位）

2.人员流动

3.项目管理失败

4.开发目标不明确或摇摆不定

5.开发计划执行受到严重影响

6.技术方案有缺陷

7.项目经费超支或不足

8.开发环境及过程管理混乱

9.产品质量低劣

10.需求发生变化

Top1054风险识别风险的类别计划编制组织和管理开发环境最终用户客户需求产品外部环境人员设计和实现过程55计划编制风险计划、资源和产品的定义完全由客户或上层领导决定，忽略了项目组的意见，并且这些决定不完全一致计划忽略了必要的任务和活动计划不切实际计划基于特定小组成员，而这样的小组成员根本得不到产品规模估算过于乐观工作量估算过于乐观进度的压力造成生产率的下降目标日期提前，但没有相应地调整产品范围和可用资源一个关键任务的延迟导致其他相关任务的连锁反应涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多……57组织和管理风险缺乏强有力、有凝聚力的领导(项目组、企业)解雇员工导致项目小组能力下降削减预算打乱项目计划仅由管理层和市场人员进行技术决策，导致进度延长低效的项目组组织结构降低生产率管理层审查/决策的周期比预期时间长管理层作出了打击项目组积极性的决定非技术的第三方的工作比预期要长(如,采购硬件设备)项目计划由于压力而放弃，导致开发混乱管理方面的英雄主义，忽视客观确切的状态报告，降低发现和改正问题的能力58开发环境风险设施不能及时到位开发工具未能及时到位开发工具不如期望的那样有效，开发人员需要更多的时间，或者更换工具开发工具的学习期比预期的要长开发工具的选择不是基于技术需求，不能提供计划要求的功能59最终用户风险最终用户坚持新的需求最终用户对最后交付的产品不满意，要求重新设计和重做最终用户不买进项目产品，无法提供后续支持最终用户的意见未被采纳，造成产品最终无法满足用户要求60客户风险(1/2)客户坚持新的需求客户对规划、原型和规格的审核/决策超出预期客户没有参与规划、原型和规格的审核，导致需求不稳定，以及长时间的变更客户答复的时间比预期的要长客户坚持技术决策而导致计划延长客户对开发进度管理过细，导致实际进度变慢客户提供的组件无法与开发的产品匹配，导致需要额外的设计和集成工作客户提供的组件质量欠佳，导致额外的测试、设计或者功能不完善61客户风险(2/2)客户要求的支持工具与环境不兼容，性能差或者不完善，导致生产率降低客户不接受交付的软件，尽管它满足了所有的规格客户期望的开发速度是开发人员所无法达到的62需求风险需求已经成为项目基准，但仍在变化需求定义欠佳：不清晰、不准确、不一致增加额外的需求63产品风险错误发生率高的模块，需要更多的时间对它进行测试、设计和实现矫正质量低下的不可接受的产品需要更多的时间对它进行测试、设计和实现由于功能错误，导致需要重新进行设计和实现开发额外不需要的功能延长了进度要满足产品规模和速度要求，需要更多的时间严格要求与现有系统兼容，需要更多的时间要求软件重用，需要更多的时间……产品风险要求在不同操作系统下运行将花费比预期更长的时间在不熟悉或没有经验的软件环境中运行产生没有预料的问题在不熟悉或者没有经验的硬件环境中运行产生没有预料的问题

开发一种对组织全新的模块将比预期花费更长的时间

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