软件风险管理

1、软件风险管理风险管理计划1 .引言1.1 本文件的范围和目的项目风险管理描述了在整个项目生命周期内项目团队如何组织 和开展项目风险识别，度量，应对和监控等项目管理活动，是一份指 导项目团队进行项目风险管理的纲领性文件。项目风险管理的目标在 于提高项目中积极事件的概率和影响，降低项目中消极事件的概率和 影响，确保项目在可控的范围内完成项目目标。L2概述目标提高项目中积极事件的概率和影响，降低项目中消极事件的概率 和影响，确保项目在可控的范围内完成项目目标。当不能很确定地预 测将来事情的时候，可以采用结构化风险管理来发现计划中的缺陷, 并且采取行动来减少潜在问题发生的可能性和影响o风险管理意味着

2、危机还没有发生之前就对它进行处理,这就提高了项目成功的机会并 减少了不可避免风险所产生的后果。需要优先考虑规避的风险(1)业务风险产品规模风险，商业风险，项目需求风险，客户特性风险，过程风险(2)技术风险技术情况风险，开发环境风险(3)组织风险人员数目及其经验风险1.3组织领导成员蒋妍，范楚楚，宋蕊蕊，谭琳琳，杨欣颖，赵术洁责任人员名称主要责任蒋妍负责调研市场，掌 控市场走向，及时掌握 需求走向，及时与客户 沟通作出风险调控。范楚楚根据项目内容，通过风 险调查，风险来源等作 出风险识别，并作出风 险分类。宋蕊蕊对所列的风险进行分 析，作出风险发生的概 率估计赵术洁对出现的风险进行风险 评价谭琳

3、琳规划应对风险，对风险 评价的结果提出建议并 作出规避风险的备选方 案及建议方案杨欣颖控制风险1.4风险规避策略的内容说明进度安排内容进度对存在的项目风险进行 识别从项目需求阶段开始对存在的项目风险进行 分析做出风险识别后开始对存在的项目风险制定 规避策略做出风险分析后开始风险监控统筹全局主要里程碑和审查行动(1)项目风险分析通过项目风险分析对项目进行宏观控制,作出风险发生的概率及时作 出规避策略，降低项目成本。(2)项目风险应对对于出现的不确定风险应及时做出应对措施,提出风险规避备选方案 及建议方案，降低项目的失败性。预算风险情况调查所需花费预算成本风险类别风险调查预算需求风险调查问卷 市场

4、调研10001000客户特性风险需求变动5000过程风险软件工程培训 评审结果后续30005000技术风险技术变动5000开发环境风险开发工具变动1000人员数目及经验风险人员管理50002风险识别2.1风险情况调查，风险来源收集资料项目产品或服务说明书，项目的前提，假设和制约因素，本项目可与 类比的项目。2. 2风险分类风险识别分类表风险类别规模估算可能非常低产品规模用户数量大大超出计划产品规模复用程度低于计划产品规模最终用户抵制该计划商业影响交付期限将被紧缩商业影响资金将会流失客户特性用户将改变需求产品规模技术达不到预期的效果技术情况缺少对工具的培训开发坏境人员缺乏经验人员数目及其经验人员

5、流动频繁人员数目及其经验3风险分析3. 1风险估计定性风险分析法风险发生概率的定性等级等级等级说明A极高B高C中D低E极低风险后果影响的定性等级等级等级说明I灾难性的n严重的m轻度的IV轻微的T影响评估类别'因素性能支持成本进度灾难性的1无法满足需求而导致任务失败错误将导致进度延迟和成本增加2严重退化使得根本 无法达到要求的技术性能无法作出响应或无法支持 的软件严重的资金短缺，很可 能超出预算无法在交付日期内完成严重的1无法满足需求而导致系统性能下降，使得任务 能否成功受到置疑错误将导致操作的延迟，并使成本增加2技术性能有所下降在软件修改中有少量的延理资金不足，可能会超支交付日期可能延

6、迟轻微的1无法满足要求而导致次要任务的退化成本、影响和即可饮豆的进度上的小问题2技术性能有较小的降低较好的软件支持有充足的资金来源实际的、可完成的进度计划I可忽略的1无法满足要求而导致使用不方便或不易操作错误对进度及成本的影响很小2技术性能不会降低易于进行软件支持可能低于预算交付日期将会提前注：1、未测试出的软件错误或缺陷所产生的潜在影响。2、如果没有达到预期的结果所产生的潜在影响.风险评估指数矩阵等级概率等级1 （灾难的）n （严重的）m （轻度的）IV （辂微的）A （极高）13713B （高）25916C （中）461118D （低）8101419E （极低）12151720定量风险分析

7、法项目临界点决策树高性能：P= 30%, outcome = 550 000EMV = 550 000 x 30% = 165 000成功：P=70%EMV = 95 000 * 70% - 66 500低性能：P= 70%, outcome = TOO 000EMV-100 000 x 70% = -70 000实施后：EMV = 6 500失败：P =30%, outcome = "200 000EM V = - 200 000 x 30% = - 60 000不实施EMV=03. 2风险评价风险评价使用方法风险分类，风险分析，风险排序3. 2. 2风险评价的结果风险分析结果风

8、险类 别概率影响排序用户变更需求产品规模80%51规模估算可能非常低产品规模60%52人员流动人员数目及其经验60%43最终用户抵制该计划商业影响50%44交付期限将被紧缩商业影响50%35用户数居大大超出计划产品规模30%46技术达不更赖期的效果技术情况30%27缺少对工具的培训开发环境40%18人员缺乏经验人员数目及其经醛10%39 * 4.风险应对及监控4.1 根据风险评价的结果提出建议(1)消极风险或威胁采用规避，转移，减轻，接受等方法(2)积极风险或机会采用开拓，分享，提高等方法。4. 2可用于规避风险的备选方案及建议方案项 目风险识别风险评估风险应对措施潜在的风险事风险发生的后可严

9、不风应对措施预防措施负管理过程件果能 性重 性可控性险等级责人需求分析需求不 明确客户不 接受产 品或拒 绝付款596B派遣经验 丰富的需 求分析师 与客户进 行深入的 交流，明 确客户的 主要需求，引导 客户对项 目做出正 确的描 述。事先进行需 求评审项目范 围定义 不明确项目没 完没了895B要求需 求小组按 照客户的 要求变更 项目范 国。需求要在 事先定义清 楚并获得客 户的确认。项目目 标不明 确导致项 目进度 拖期或 成本超 支。685C修改项目 目标。事先明确项 目目标与客户 沟通不 够软件不 能满足 客户需 求596C立即与客 户进行沟 通制定沟通管 理计划需求， 组对: 户

10、业， 了解:够小 客 务 不软件不 能实现 业务功 能695C修改软件加强与了解 并让客户参 与需求小 组没有 真止埋 解客户 需求软件不 能萍踪 客户需 求8107A根据客户 需求修改让客户确认 需求报告需求二 析报， 没有彳分 上客户拒 绝签字、 验收5105C取消项目或修改项 目事先获得客 户确认到客户 的确认需求不 断变化项目变 得没完 没了895B提交CCB 讨论、决 定建立范围变 更程序缺乏有 效的需 求变化 管理过 程项目不 能按时、 按预算 完成584D对需求变 化进行评 审建立需求变 更程序任务定 义不够 充分项目不 能按时、 按预算 完成685C重新定义事先与客户 达成共识

11、设 计缺乏有 经验的 分析员分析错 误或不 可行4105C培训或换 人配备有经验 的分析员设计偏 离客户 需求软件不 能萍踪 需求，客 户拒绝 接受5105C修改设计进行设计评 审软件功 能漏项客户不 满意485D增加相应 的功能进行设计评 审、获得客 户确认m ja软件实 现不了 设计的 功能，客 户拒绝 接受69ATV进行设计评 审程序员 对系统 设计的 理解上 出现偏 差4D修改代码编 码程序员 开发能 力差项目进 度拖期495D培训或换 人配备精兵强 将程序员 不熟悉 开发工 具项目进 度拖期、 质量问 题384E立即改进提前准备设计错 误导致 编码实 现困难质量问4105c修改设计编

12、码之前进题行设计评审客户要 求增加项目进 度拖期、875C修改程序事先确定范 围目标功能成本超 支项目将 会时间 提前质量问 题485D加班加点 或增加资 源合同固定交 付时间项目执 行不卜 去510与相关人员 签订合同程序员 离开4C临时替补 人开发团 队内部 沟通不 够接口混乱、质量 问题584D修改程序制定内部沟 通计划测没有切 实可行 的测试 计划项目拖 期、质量 问题发 现不了295E修改测试 计划事先评审测 试计划试测试人 员不能 按时到 位项目进 度拖期273E临时安排 测试人员制定出人力 资源计划测试人 员经验程序问 题发现463E培训或换 人选择有经验 的人员不够不了测试设

13、备故障项目拖 期384E修理或换 设备加强设备预 防性维修测试期 间出现 重大问 题客户拒 绝接受 产品4105C修改程序分步测试没有有 效的备 份方案数据丢 失无法 挽救494D重新开始异地双重备 份测试发 现的问 题迟迟 解决不 T项目进 度拖期395D加快解决专家会诊解 决安 装设备不 能按时 到位项目进 度拖期3384E催设备供 应商提前采购或 合同约束运行时 质量问 题多客户投 诉684D即时解决 问题事先进行局 部运行客户突 然要求 增加功 能项目进 度拖期、 成本超 支785C作出相应 修改事先确定项 目范围和功 能要求重要的 记录、文 件、数据 丢失客户投 诉、要求 赔偿395D重新生成 数据做好备份系统崩 溃客户要 求承担 损失2103E加紧修复事先备份维 护出现故 障，用户 维护人 员