软件项目管理方法与实践教学课件阳王东软件项目管理 10

《软件项目管理方法与实践教学课件阳王东软件项目管理 10 》由会员分享，可在线阅读，更多相关《软件项目管理方法与实践教学课件阳王东软件项目管理 10 （41页珍藏版）》请在金锄头文库上搜索。

1、软件项目管理 第10讲：风险管理,阳王东 ,复习,如何定义一个电子商务网站的质量特性 如何看待windows vista的质量问题,主要内容,风险识别 风险控制 风险应对 案例分析,风险的概念,什么是风险。风险是其损益结局具有不可确定性的活动。 任何可能出现的条件或事件，一旦发生，对项目会造成损害； 风险是不确定的条件或因素，不同于“测试中肯定会发现缺陷，但不知道是何时”。 风险的特征 所涉及的不确定性，这一不确定性通常被表示为可能性，也就是有发生的概率； 与风险相关的损失，如生活、健康、金钱、财产、名誉或机会等方面的损失； 它是可管理的，在这一意义下，人类活动可以改变风险的形式和程度。,风险

2、识别的方法,问询和探讨 头脑风暴法 咨询 分析历史数据 流程图法 逆向推导法,流程图法,逆向推导法,逆向推导法是从项目的结果出发，去推导导致结果的可能存在的风险因素 项目失败 项目中途终止； 当完成了项目开发的软件产品后，而客户或公司却放弃了对软件开发合同履行,逆向推导法（续）,导致第一种情况出现的风险可能有： 项目的经费供应终止。可能是投资方撤资或倒闭。 公司决策层放弃。可能由于市场、技术或者业务方向等问题，导致公司放弃了项目所开发的软件产品。 由于项目组主要的关键人员离开项目组，可能是被竞争对手挖走，或者是疾病与死亡等，而项目组一时找不到可替代的人员，并且项目缺乏这些人员不能继续。 项目开

3、发的软件产品违反国家有关法律或法规，被勒令终止。,逆向推导法（续）,可能导致第二种情况出现的风险可能有： 客户的业务发生重大变化，项目组开发的软件产品已经不能适应新的业务需要。 客户的组织发生了重大变化，新的组织不再履行以前组织签订的软件合同。这一方面在客户是行政事业单位更为明显。 项目组开发的软件产品存在重大质量问题，使得客户根本无法开展业务工作，从而导致客户根据软件合同相关条款终止合同的履行。 项目进度严重滞后，当项目组把软件产品开发出来后，客户已经不需要了。 由于硬件提供商违约，既定的硬件基础不能到位，导致客户根本无法运行项目开发的软件产品，并且不能在短时期能得到解决，因而客户终止对软件

4、合同的履行。 也可能是客户在软件合同经费的支付上违反合同的相关条款，公司放弃了对客户的软件合同的履行。,软件项目中常见的风险,需求风险 计划编制风险 组织和管理风险 人员风险 开发环境风险 客户风险 产品风险 设计和实现风险 过程风险,需求风险,需求已经成为项目基准，但需求还在继续变化； 需求定义欠佳，而进一步的定义会扩展项目范畴； 添加额外的需求； 产品定义含混的部分比预期需要更多的时间； 在做需求中客户参与不够； 缺少有效的需求变化管理过程。,计划编制风险,计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致； 计划是优化的，是“最佳状态”，但不现实，只能算是“期望状态”； 计划

5、基于使用特定的小组成员，而那个特定的小组成员其实指望不上； 产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大； 完成目标日期提前，但没有相应地调整产品范围或可用资源； 涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。,组织和管理风险,仅由管理层或市场人员进行技术决策，导致计划进度缓慢，计划时间延长； 低效的项目组结构降低生产率； 管理层审查、决策的周期比预期的时间长； 预算削减，打乱项目计划； 管理层作出了打击项目组织积极性的决定； 缺乏必要的规范，导致工作失误与重复工作； 非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。

6、,人员风险,作为先决条件的任务(如培训及其他项目)不能按时完成； 开发人员和管理层之间关系不佳，导致决策缓慢，影响全局； 缺乏激励措施，士气低下，降低了生产能力； 某些人员需要更多的时间适应还不熟悉的软件工具和环境； 项目后期加入新的开发人员，需进行培训并逐渐与现有成员沟通，从而使现有成员的工作效率降低； 由于项目组成员之间发生冲突，导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作； 不适应工作的成员没有调离项目组，影响了项目组其他成员的积极性； 没有找到项目急需的具有特定技能的人。,开发环境风险,设施未及时到位； 设施虽到位，但不配套，如没有电话、网线、办公用品等； 设施拥挤、杂乱或者破

7、损； 开发工具未及时到位； 开发工具不如期望的那样有效，开发人员需要时间创建工作环境或者切换新的工具； 新的开发工具的学习期比预期的长，内容繁多。,客户风险,客户对于最后交付的产品不满意，要求重新设计和重做； 客户的意见未被采纳，造成产品最终无法满足用户要求，因而必须重做； 客户对规划、原型和规格的审核 决策周期比预期的要长； 客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和产品生产周期的变更； 客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长； 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。,产品风险,矫正质量低下的不可接受的产品

8、，需要比预期更多的测试、设计和实现工作； 开发额外的不需要的功能(镀金)，延长了计划进度； 严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作； 要求与其他系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作； 在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题； 开发一种全新的模块将比预期花费更长的时间； 依赖正在开发中的技术将延长计划进度。,设计和实现风险,设计质量低下，导致重复设计； 一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发新的功能； 代码和库质量低下，导致需要进行额外的测试，修正错误，或重新制作； 过高估计了

9、增强型工具对计划进度的节省量； 分别开发的模块无法有效集成，需要重新设计或制作。,过程风险,大量的纸面工作导致进程比预期的慢； 前期的质量保证行为不真实，导致后期的重复工作； 太不正规(缺乏对软件开发策略和标准的遵循)，导致沟通不足，质量欠佳，甚至需重新开发； 过于正规(教条地坚持软件开发策略和标准)，导致过多耗时于无用的工作； 向管理层撰写进程报告占用开发人员的时间比预期的多； 风险管理粗心，导致未能发现重大的项目风险。,建议和忠告,考验一个项目经理和项目开发团队，不仅要看其在没有什么风险的环境中的做事的能力；更要看其在出现各种风险的环境下的做事能力； 风险并不可怕，可怕是不知道有风险； 不

10、能因为有风险就不去做，风险是锻炼一个人的最好的机会； 一般是高风险才能有高的回报。,风险控制,风险管理模型 风险控制计划 十个风险清单 风险控制方法,风险管理模型,Barry Boehm模型 。RE=P (UO)*L (UO) 。 其中RE表示风险或者风险所造成的影响，P(UO)表示令人不满意的结果所发生的概率，L(UO)表示糟糕的结果会产生破坏性的程度。Boehm思想的核心是10大风险因素列表。 SEI的CRM模型。 它将风险管理划分为五个步骤：风险识别、分析、计划、跟踪、控制。 SERIM模型 。 从技术和商业两个角度对软件风险管理进行剖析，考虑的问题涉及开销、进度、技术性能等。,风险控制

11、计划,风险管理计划 应急计划 应急储备,风险管理计划,(1) 项目中存在哪些风险； (2) 风险的发生可能性大小； (3) 不同风险对项目的影响程度； (4) 风险可能出现的阶段及其影响的阶段； (5) 谁对哪些风险具体进行跟踪和负责。 计划表中风险类别 BU-商业风险，CU-客户特性风险，DE-开发环境风险，TE-人员经验风险，ST-建造技术风险，PS-产品规模风险，PU-过程风险。,风险管理计划表,风险管理计划表（续）,十个风险清单,风险控制方法,为了有效的风险控制，项目组和项目经理必须具备： 衡量项目进展状态的标准； 监视项目实际进展所需要的信息； 必要时采取调整和纠正行动的权限； 从各

12、种备用措施中选取最优者加以实施的能力。 风险控制策略 降低风险发生的概率 为事件的发生做好准备，减轻风险的影响 制度化、规范化的运作，可以降低人为因素的风险 转移风险有时也是一种好的方法 凡是留有回旋余地，不至于到时一筹莫展 惹不起，躲得起 默默得承受有时既是无奈的选择，但可能是明智的选择,降低风险发生的概率,公司在制定开发流程一定要从实际出发，是真正为了提高开发效率与质量而制定的，而不是为了制度而制度； 项目经理要根据项目的实际情况进行适当裁减； 要对开发人员进行培训，让他们能够掌握开发流程的精髓； 在执行过程中，能够不断进行改进，让开发人员切实感觉到遵照开发流程进行开发，确实能够提高效率，

13、还能保证质量。,转移风险的方式,出售 发包 开脱责任合同 保险 担保。,回避的项目,开发的软件系统存在法律障碍。 客观上不需要的项目，没有必要去冒险。 一旦造成损失，软件公司无力承担后果的项目。,建议与忠告,将风险管理集成到项目管理； 使用工具； 开始时不要对量化过于强调； 不要期待实施风险管理的费效分析； 记住风险计划可能引入新的风险或增加成本。 风险回避应是最后一招，采用时应非常清醒 使用组织层的风险数据库以便项目间相互借鉴,风险的应对,关注风险，但不焦虑风险 发现苗头，及时处理 当风险变成现实时，不要回避,关注风险，但不焦虑风险,要有一个良好的心态 要树立能解决风险所带来影响的信心 要树

14、立能解决风险所带来影响的信心 让项目组每个人都能够了解风险 记录风险，并不是时时刻刻讲风险 不同风险让专人去跟踪 周期性汇报风险的状态,发现苗头，及时处理,发现苗头，及时处理 客户需求不确定 客户推迟项目验收 开发人员的变动 模块质量不过关 开发进度延迟,建议与忠告,承认风险是不可避免的； 公开交流风险讨论本身似乎能减少风险的影响； 奖励阻止风险发生的人，而不仅仅是惩罚那些造成风险的人； 同一时刻不要管理太多风险； 记下风险； 不要仅关注容易处理的风险。,当风险变成现实时，不要回避,要承认风险发生的现实 要有一个良好的心态 要迅速的行动 要有针对地行动 事态严重必须向上级汇报 事故的处理结果要

15、及时公布 风险的处理要有记录，并且要形成正式的处理报告,高风险数据分析项目的风险管理,风险识别 需求不确定性的风险； 决策层沟通障碍的风险； 分析技术路线的风险； 其他风险。 风险分析 风险规避,风险分析,需求不确定性风险还会导致项目进度、成本、质量、资源、合同等相关风险，使项目处于失控状态。在实际工作中，往往遇到当项目快要收尾时，依然出现客户对系统提出“在客户分析方面需要拔高”，“在经营指标分析方面要加强体现某领导讲话精神”之类模糊不清的需求。 决策层沟通障碍风险容易使最终决策领导对项目的期望保留在项目竞标阶段，理想而抽象，项目组不能真正理解领导的需求，甚至无所适从，大量工作“跑题”浪费，使

16、时间和成本的投入成倍增长。 技术路线风险可以直接导致项目失败。项目的目标有时会超过项目组所选技术能够支持的范围，再加上项目组对产品并不熟悉，选用了看似完美而实际并不成功的分析模型，无疑会使项目处于毁灭性的风险中。像某国家级银行采用SAS和Cognos实现的全国性信贷分析系统几乎无法使用就是典型案例。,风险规避,项目经理同客户最高决策层拥有畅通的沟通渠道； 项目开发模型采用迭代模型； 审慎运用尚处于研究阶段的分析技术与模型； 层次较高、结构合理的项目组织结构； 多参考专家意见。,思考题,一个玩具销售公司决定开发一个网站实现网上销售玩具，决定开发时间为9月份，必须赶上圣诞节的销售旺季，你作为一个负责人，请进行风险识别和分析。 下面是实际情况，请进行分析总结出现这种情况的原因，应该采取什么措施去避免。 在项目的初期一个负责服务器端开发的人员一直兼任另一个项目，而到了中期又因病离职，导致服务器端的开发几乎没有任何进展。项目组在12月份调入另一名能力较强的开发人员来接班。在项目组的努力下终于在12/24如期发布了beta版。 到这里似乎一切顺利，但接下