软件工程项目风险管理课件.pptVIP

风险识别（V） 技术风险： 该技术对于你的公司而言是新的吗； 待开发软件是否需要使用新的或未经证实的硬件接口； 待开发软件是否需要与开发商提供的未经证实的软件产品接口 需求是否要求开发某些程序构件，这些构件与你的公司以前开发的构件完全不同 需求中是否要求使用非传统的软件开发方法 需求中是否有过分的对产品性能的约束 ? 风险识别（VI） 开发环境风险： 是否有可用的软件项目管理工具； 是否有可用的分析及设计工具； 是否有可用的编译器或代码生成器 是否有可用的软件配置管理工具 项目组的成员是否接受过每个所使用工具的培训 工具的联机帮助及文档是否适当 ? 风险识别（VII） 与人员数目及经验相关的风险： 是否有足够的人员可用； 人员在技术上是否配套； 开发人员是否能够自始至终地参加整个项目的工作 开发人员对自己的工作是否有正确的期望 开发人员是否接受过必要的培训 开发人员的流动是否仍能保证工作的连续性 ? 评估整体项目风险 下面的提问是基于对世界各地的有经验的软件项目管理人员的调查而得到的风险数据导出的，这些提问按它们对项目成功的相对重要性排序。 1. 顶层的软件和客户管理者已经正式承诺支持该项目吗？ 2. 终端用户对项目和待建造的系统/产品热烈支持吗？ 3. 需求已经被软件工程队伍和他们的客户完全理解了吗？ 4. 客户已经完全地参与到需求的定义了吗？ 评估整体项目风险 5. 终端用户的期望现实吗？ 6. 项目范围稳定吗？ 7. 软件工程队伍拥有合适的技能吗？ 8. 项目需求稳定吗？ 9. 项目小组对将实现的技术有经验吗？ 10. 项目小组的人员数目适合于完成该工作吗？ 评估整体项目风险 11. 所有的客户/用户对项目的重要性和待建造的系统/产品的需求有共识吗？ 如果这些提问的任意一个的回答是否定的，则应该确定无疑地启动缓解、监控和管理步骤。项目处于风险的程度直接正比于这些提问的否定回答的数量。 风险因素和驱动因子 识别影响风险因素的风险驱动因子 风险因素 软件项目的不确定性 性能风险：产品能够满足需求且符合其使用目的不确定程度 成本风险：能够维持项目预算的不确定程度 支持风险：开发出的软件易于纠错、修改及升级的不确定程度 进度风险：能够维持项目进度且按时交付产品的不确定程度 风险因素和驱动因子 风险驱动因子 可导致软件项目的不确定性程度改变的事物，如未识别出的软件失误，开发成员变动等。 风险驱动因子对于风险因素的影响可分成四类：可忽略的、轻微的、严重的或灾难的。 图19－1 影响评估 [BOE89] 注：（1）未测试出的软件错误或缺陷所产生的潜在影响。  （2）如果没有达到预期的结果所产生的潜在影响。 风险预测 风险预测，又称风险估算，试图从两个方面评估每一个风险――风险发生的可能性或概率，以及如果风险发生了，所产生的后果。 项目计划者，以及其它管理人员和技术人员，一起执行四个风险预测活动： （1）建立一个尺度，以反映风险发生的可能性； （2）描述风险的后果； （3）估算风险对项目及产品的影响； （4）标注风险预测的整体精确度，以免产生误解。 建立风险表 风险表给项目管理者提供了一种简单的风险预测技术。 项目组一开始要在表中的第一列列出所有风险（不管多么细微）。 每一个风险在第二列上加以分类（如，PS指产品规模风险，BU指商业风险）。 每个风险发生的概率则输入到第三列中。每个风险发生的概率值可以由项目组成员个别估算，个体成员通过循环的方式投票，直至他们的风险概率评估开始会聚。 建立风险表 下一步是评估每个风险所产生的影响。使用特性评估每个风险元素，并确定其影响的类别。 四个风险元素――性能、支持、成本、及进度――的影响类别被求平均以得到一个整体的影响值。 一旦完成了风险表的前四列内容，就要根据概率及影响来进行排序。高发生概率、高影响的风险放在表的上方，而低概率风险则移到表的下方。这样就完成了一阶风险优先序。 建立风险表 项目管理者研究已排序的表，并定义一条中截线。该中截线（表中某一点上的一条水平线）表示：只有那些在线之上的风险才会得到进一步的关注。 而在线之下的风险则需要再评估以完成二阶风险优先序。风险影响及概率从管理的角度来考虑，是起着不同的作用。 网络互连技术与应用 第九章 过 程 软件工程 Visual Basic程序设计 软件工程 V i s u a l B A S I C 程序设计 第二十一讲 风 险 管 理 项目风险 什么会出问题? 出某个问题的概率如何? 会带来多大损害? 我们可以做什么? 风险的概念 Robert Charette在他的关于风险分析和管理的书中给出了风险的概念定义如下：? 首先，风险关注未来将要发生的事情。今天和昨天已不再被关心，