软件风险管理

1. 引言

1.1本文件的范围和目的

项目风险管理描述了在整个项目生命周期内项目团队如何组织和开展项目风险识别，度量，应对和监控等项目管理活动，是一份指导项目团队进行项目风险管理的纲领性文件。项目风险管理的目标在于提高项目中积极事件的概率和影响，降低项目中消极事件的概率和影响，确保项目在可控的范围内完成项目目标。 1.2概述 1.2.1目标

提高项目中积极事件的概率和影响，降低项目中消极事件的概率和影响，确保项目在可控的范围内完成项目目标。当不能很确定地预测将来事情的时候，可以采用结构化风险管理来发现计划中的缺陷，并且采取行动来减少潜在问题发生的可能性和影响。风险管理意味着危机还没有发生之前就对它进行处理，这就提高了项目成功的机会并减少了不可避免风险所产生的后果。 1.2.2 需要优先考虑规避的风险 （1）业务风险

产品规模风险，商业风险，项目需求风险，客户特性风险，过程风险 （2）技术风险

技术情况风险，开发环境风险 （3）组织风险 人员数目及其经验风险 1.3组织 1.3.1领导成员

蒋妍，范楚楚，宋蕊蕊，谭琳琳，杨欣颖，赵术洁 1.3.2责任

人员名称 蒋妍 范楚楚 宋蕊蕊 赵术洁 谭琳琳 杨欣颖 主要责任 负责调研市场，掌控市场走向，及时掌握需求走向，及时与客户沟通作出风险调控。 根据项目内容，通过风险调查，风险来源等作出风险识别，并作出风险分类。 对所列的风险进行分析，作出风险发生的概率估计 对出现的风险进行风险评价 规划应对风险，对风险评价的结果提出建议并作出规避风险的备选方案及建议方案 控制风险 1.4 风险规避策略的内容说明 1.4.1 进度安排

内容 对存在的项目风险进行识别 对存在的项目风险进行分析 进度 从项目需求阶段开始 做出风险识别后开始 对存在的项目风险制定规避策略 风险监控 做出风险分析后开始 统筹全局 1.4.2 主要里程碑和审查行动 （1）项目风险分析

通过项目风险分析对项目进行宏观控制，作出风险发生的概率及时作出规避策略，降低项目成本。 （2）项目风险应对

对于出现的不确定风险应及时做出应对措施，提出风险规避备选方案及建议方案，降低项目的失败性。 1.4.3预算

风险情况调查所需花费预算成本

风险类别需求风险客户特性风险过程风险技术风险开发环境风险人员数目及经验风险风险调查预算调查问卷1000市场调研1000需求变动5000软件工程培训3000评审结果后续5000技术变动5000开发工具变动1000人员管理5000

2 风险识别

2.1风险情况调查，风险来源 收集资料

项目产品或服务说明书，项目的前提，假设和制约因素，本项目可与

类比的项目。 2.2风险分类

风险识别分类表

风险 规模估算可能非常低 用户数量大大超出计划 复用程度低于计划 最终用户抵制该计划 交付期限将被紧缩 资金将会流失 用户将改变需求 技术达不到预期的效果 缺少对工具的培训 人员缺乏经验 人员流动频繁 类别 产品规模 产品规模 产品规模 商业影响 商业影响 客户特性 产品规模 技术情况 开发坏境 人员数目及其经验 人员数目及其经验 3风险分析 3.1风险估计

3.1.1定性风险分析法

风险发生概率的定性等级

风险后果影响的定性等级

V 可忽略的 影响评估 类别＼因素 1 灾难性的 2 性 能 支 持 成 本 进 度 无法满足需求而导致任务失败 严重退化使得根本无法达到要求的技术性能 错误将导致进度延迟和成本增加 无法作出响应或无法支持严重的资金短缺，很可无法在交付日期内的软件 能超出预算 完成 1 严重的 2 1 轻微的 2 1 2 无法满足需求而导致系统性能下降，使得任务能否成功受到置疑 技术性能有所下降 在软件修改中有少量的延迟 错误将导致操作的延迟，并使成本增加 资金不足，可能会超支 交付日期可能延迟 成本、影响和即可恢复的进度上的小问题 有充足的资金来源 实际的、可完成的进度计划 无法满足要求而导致次要任务的退化 技术性能有较小的降低 较好的软件支持 可忽略的 无法满足要求而导致使用不方便或不易操作 技术性能不会降低 易于进行软件支持 错误对进度及成本的影响很小 可能低于预算 交付日期将会提前 注： 1、未测试出的软件错误或缺陷所产生的潜在影响。 2、如果没有达到预期的结果所产生的潜在影响。 风险评估指数矩阵

3.1.2定量风险分析法

项目临界点

决策树

3.2风险评价

3.2.1风险评价使用方法 风险分类，风险分析，风险排序 3.2.2风险评价的结果

风险分析结果

4.风险应对及监控

4.1根据风险评价的结果提出建议

（1）消极风险或威胁采用规避，转移，减轻，接受等方法 （2）积极风险或机会采用开拓，分享，提高等方法。 4.2可用于规避风险的备选方案及建议方案

项目管理过程 需求不明确 客户不接受产品或拒绝付款 5 9 6 B 派遣经验丰富的需求分析师与客户进行深入的交流，明确客户的主要需求，引事先进行需求评审 风险识别 潜在的风险事件 风险发生的后果 可能风险评估 严重不可风险等应对措施 风险应对措施 预防措施 负责人 性 性 控性 级 需求分析 缺乏有经验的分析员 设计偏离客户需求 分析错误或不可行 软件不能萍踪需求，客户拒绝接受 4 10 5 C 与客户沟通不够 项目范围定义不明确 项目没完没了 8 9 5 B 导客户对项目做出正确的描述。 要求需求小组按照客户的要求变更项目范围。 修改项目目标。 需求要在事先定义清楚并获得客户的确认。 事先明确项目目标 项目目标不明确 导致项目进度拖期或成本超支。 软件不能满足客户需求 软件不能实现业务功能 软件不能萍踪客户需求 客户拒绝签字、验收 项目变得没完没了 项目不能按时、按预算完成 项目不能按时、按预算完成 6 8 5 C 5 9 6 C 立即与客户进行沟通 修改软件 制定沟通管理计划 需求小组对客户业务了解不够 需求小组没有真正理解客户需求 需求分析报告没有得到客户的确认 需求不断变化 6 9 5 C 加强与了解并让客户参与 让客户确认需求报告 8 10 7 A 根据客户需求修改 5 10 5 C 取消项目或修改项目 提交CCB讨论、决定 对需求变化进行评审 重新定义 事先获得客户确认 8 9 5 B 建立范围变更程序 缺乏有效的需求变化管理过程 任务定义不够充分 5 8 4 D 建立需求变更程序 6 8 5 C 事先与客户达成共识 培训或换人 配备有经验的分析员 5 10 5 C 修改设计 进行设计评审 设计 编码 软件功能漏项 客户不满意 4 8 5 D 增加相应的功能 进行设计评审、获得客户确认 程序员对系统设计的理解上出现偏差 程序员开发能力差 程序员不熟悉开发工具 设计错误导致编码实现困难 客户要求增加功能 项目将会时间提前 程序员离开 软件实现不了设计的功能，客户拒绝接受 项目进度拖期 6 9 4 D 修改代码 进行设计评审 4 9 5 D 培训或换人 配备精兵强将 项目进度拖期、质量问题 质量问题 3 4 8 4 E 立即改进 提前准备 10 5 C 修改设计 编码之前进行设计评审 项目进度拖期、成本超支 质量问题 8 7 5 C 修改程序 事先确定范围目标 4 8 5 D 加班加点或增加资源 临时替补人 合同固定交付时间 项目执行不下去 5 10 4 C 与相关人员签订合同 开发团队内部沟通不够 接口混乱、质量问题 5 8 4 D 修改程序 制定内部沟通计划 没有切实可行的测试计划 测试人员不能按时到位 测试人员经验不够 测试设备故障 项目拖期、质量问题发现不了 项目进度拖期 2 9 5 E 修改测试计划 事先评审测试计划 2 7 3 E 临时安排测试人员 制定出人力资源计划 程序问题发现不了 项目拖期 4 6 3 E 培训或换人 选择有经验的人员 3 8 4 E 修理或换设备 加强设备预防性维修 测试 测试期间出现重大问题 没有有效的备份方案 测试发现的问题迟迟解决不了 客户拒绝接受产品 数据丢失无法挽救 项目进度拖期 4 10 5 C 修改程序 分步测试 4 9 4 D 重新开始 异地双重备份 3 9 5 D 加快解决 专家会诊解决 安装 设备不能按时到位 运行时质量问题多 客户突然要求增加功能 重要的记录、文件、数据丢失 系统崩溃 项目进度拖期3 3 8 4 E 催设备供应商 提前采购或合同约束 客户投诉 6 8 4 D 即时解决问题 事先进行局部运行 项目进度拖期、成本超支 客户投诉、要求赔偿 客户要求承担损失 客户投诉 7 8 5 C 作出相应修改 事先确定项目范围和功能要求 做好备份 3 9 5 D 重新生成数据 2 10 3 E 加紧修复 事先备份 维出现故障，用户维护人员解决不了 用户手册错误多 8 8 8 A 派技术人员帮助解决 修改错误 事先培训客户系统维护人员 专人检查 客户投诉 3 6 4 72 培训手册没有按时准备好 培训效果差 客户投诉，培训不能按时进行 客户不满意 3 5 3 45 加班加点准备 提前准备出来 3 6 3 54 重新培训 护 确定标准、充分准备、把好培训师质量关 4.3风险监控

4.3.1风险监控的方法

风险再评估，风险审计，技术指标分析，储备金分析，状态审查会，变差和趋势分析。