软件项目管理实用教程第9章 软件项目风险管理.pptVIP

回避风险 回避风险是对可能发生的风险尽可能地规避，采取主动放弃或者拒绝使用导致风险的方案。 例如放弃采用新技术。 消除了风险的起因，将风险发生概率降为零。具有简单和彻底的优点。 回避风险 注意事项： 对风险要有足够的认识； 当其他风险策略不理想的时候，可以考虑； 可能产生另外的风险； 不是所有的情况都适用，有些风险无法回避，如用户需求变更； 转移风险 转移风险是为了避免承担风险损失，有意识地将损失或与损失有关的财务后果转嫁出去的方法。 例如： 采购 分包 免责合同 保险 缓解风险 在风险发生之前采取一些措施降低风险发生的可能性或减少风险可能造成的损失。 例如，为了防止人员流失，提高人员待遇，改善工作环境；为防止程序或数据丢失而进行备份等。 接受风险 项目团队有意识地选择由自己来承担风险后果。 当风险很难避免，或采取其它风险应对方案的成本超过风险发生后所造成的损失时，可采取接受风险的策略。 主动接受：在风险识别、分析阶段已对风险有了充分准备，当风险发生时马上执行应急计划。 被动接受：风险发生时再去应对。在风险事件造成的损失数额不大，不对软件项目的整体目标造成较大影响时，项目团队将风险的损失当做软件项目的一种成本来对待。 风险规划示例 人员的频繁流动是一项风险，基于过去的历史和管理经验，人员频繁流动可能性的估计值为70%，会造成开发时间增加15%，总成本增加12%。对于这一风险，项目经理采取了以下风险缓解策略： 与现有人员讨论人员流动的原因。 项目启动时，做好会出现人员流动的准备，采取一些技术以确保人员的一旦离开后，项目仍然能继续。 建立良好的项目组织和通信渠道，以使大家能够了解每个有关的开发活动的信息。 指定文档标准并建立相应的机制，以保证文档能够及时建立。 对所有工作组织细致的评审，使大多数人能够按计划进度完成自己的工作。 风险规划示例 风险分析表 排序 输入 风险事件 可能性 影响 风险值 采取的措施 1 系统设计评审 没有足够的时间进行产品测试 70% 50% 35% 1．采取加班的方法 2．修改计划去掉一些任务 3．与客户商量延长一些时间 2 WBS 对需求的开发式系统标准没有合适的测试案例 ? 20% 80% 16% 找专业的测试公司完成测试工作 3 需求和计划 采用新技术可可能导致进度的延期 50% 30% 15% 1．培训开发人员 2．找专家作指导 3．采取边开发边学习的方法，要求他们必须在规定的时间内掌握技术 …… ? ? ? ? ? ? 风险识别方法 检查表法 德尔菲方法 头脑风暴法 情景分析法 检查表法 风险检查表中列出了项目中常见的风险的检查条目。 项目相关人员通过核对风险检查表，判断哪些风险会出现在项目中。 可根据项目经验对风险检查表进行修订和补充。 该方法可以使管理者集中识别常见类型的风险。 有研究表明：IT项目常常存在一些共同的风险。 如：人员缺乏、不现实的人员和成本估计、晚期需求变化、外购构件缺陷等。 检查表法 1. 基于关键域的检查表 2. 基于三层结构的检查表 3. 基于生存期的检查表 风险检查表中的风险条目属于以下几个关键域：项目规模、商业影响、项目范围、客户特性、过程定义、技术要求、开发环境、人员数目及其经验。其中每一关键域都包含很多风险检查条目。项目管理者将主要精力放在这些关键域方面来关注风险，通过对每个关键域中的风险检查条目的回答，可以识别项目可能存在的风险。 1.基于关键域的检查表 基于关键域的检查表（举例） 项目规模风险检查表： 对于估算出的产品规模的信任程度如何？ 产品规模与以前产品的规模的平均值的偏差百分比是多少？ 产品创建或使用的数据库大小如何？ 产品的用户数有多少？ 产品的需求改变多少？交付之前有多少？交付之后有多少？ 复用的软件有多少？ 2. 基于三层结构的检查表 用类（class）、元素（Element）、属性（Attribute）三个层次描述风险列表。 每个类下包含若干元素，每个元素下又包含若干属性。 通过属性值来识别、评估风险。 三层结构的风险检查表 Product Engineering Requirements Stability Completeness Clarity Validity Feasibility Precedent Scale Design Functionality Difficulty Interfaces Performance Testability Hardware Constraints Non Developmental software Code and Unit test Feasibility Testing Coding/Implementation