第9章软件工程风险管理-精.pptVIP

需求不明确，或需求分析缺陷，致使最终产品不符合（客户或市场）需要，导致项目目标偏离或在中途作重大变动，延误产品发布时间； 对项目工作量估计不足，造成工作不能按计划执行，甚至放弃计划性； 客户要求急，开发时间短，加班加点，放松了对过程的控制，导致缺陷不能及时发现，产品性能未达到要求，给后面的产品实施和维护工作带来了较大的压力； 测试手段和时间不足，不能充分覆盖所有需求项，导致交付的产品有较多缺陷不能发现。 常见风险类型 产品工程 开发环境 项目约束 1.需求 稳定性 完整性 清晰 有效性 可行性 先例 规模2.设计 功能 难点 接口 性能 可测试性 硬件约束 非开发软件 3. 编码和单元测试 可行性 单元测试 编码/实现4. 集成和测试 环境 产品 系统5. 工程特点 可维护性 可靠性 安全性 保密性 人的因素 特殊性 1.开发过程 正规性 适合性 过程控制 熟悉程度 产品控制 2.开发系统 容量 适合性 可用性 熟悉程度 可靠性 系统支持 交付能力 3.管理过程 计划项目组织管理经验项目接口 4.管理方法 监控措施 人员管理 质量保证 配置管理 5.工作环境 质量态势 合作 士气 1.资源 进度人员预算设备 2.合同 合同类型 约束 依赖关系3.项目接口 用户 联合承包方 子承包方 主承包方 协同管理 供货商策略 软件开发项目中风险分类表 分析风险 项目经理负责组织项目组成员对识别的风险项进行分析，评价风险发生的概率和影响度。必要时，可以邀请相关同行参与风险分析活动。 项目经理组织项目组成员，结合项目管理经验和当前项目实际情况，确定各个风险项的影响估算情况。风险影响是反映风险严重性的一个重要指标，可以按这样的公式计算：风险影响 = 风险发生概率×影响度。 风险发生概率（P）：是指风险发生的可能性。其量化评价方法可按下表描述打分： 定性表示 定量表示（P） 说明 很大 5 风险发生的可能性80% 较大 4 风险发生的可能性60%至80% 一般 3 风险发生的可能性40%至60% 不大 2 风险发生的可能性20%至40% 很小 1 风险发生的可能性20% 影响度（C）：是指当风险说明中所预料的结果发生时可能会对项目产生的影响，一旦风险发生而造成的损失，包括成本、进度等多种损失。其量化评价方法可按下表描述进行打分： 定性表示 定量表示（P） 说明 很严重 5 进度延误30%，或成本超支30% 严重 4 进度延误20%~30%，或成本超支20%~30% 一般 3 进度延误20%，或成本超支20% 不太严重 2 进度延误10%，或成本超支10% 不严重 1 进度延误5%，或成本超支5% 根据以上两个指标的打分情况，我们就可以按下表计算出风险影响量化的值，从而可以对风险进行优先级排序，其中表内的阴影部分表示风险影响比较大，应优先关注或处理。 风险影响 风险可能性 很大5 较大4 一般3 不大2 很小1 风险后果 很严重 5 25 20 15 10 5 严重 4 20 16 12 8 4 一般 3 15 12 9 6 3 不太严重 2 10 8 6 4 2 不严重 1 5 4 3 2 1 风险 风险陈述 风险背景 资源不足，进度延误 过分乐观的进度，有限的成本，导致进度拖后、成本超支。 人员配备不到位。没有时间进行必需的培训。无法达到进度要求的效率。将加班作为克服进度不够的标准选择。不充分的需求分析导致对产品功能需求的片面理解。 需求不定 不明确的用户需求导致项目软件需求不完整、不确定。 需求文档没有恰当地描述系统构成。接口文档未经确认或批准。需求细节来自现有代码。部分需求（如验收标准）不清楚。因客户方面人员变动引起需求变更或漂移。 人员流失 项目骨干人员中途流失造成项目中断或失败。 长期出差或长时间加班造成骨干人员有厌烦心理。激励不足缺乏激情。个人发展前景不明缺乏信心。团队内部沟通不畅心情不好。开发环境不好工作难度过大。外界吸引再某出路。 项目中途夭折 项目立项时对风险估计不足造成项目半途而废。 用户原因中途中止合同。产品失去市场前景中途停止。竞争对手先行推出或产品功能不及竞争对手，只好停止。骨干流失、技术方案失误造成项目长期拖延。决策失误中途停止项目。 效率低下 长时间的生产效率低下造成项目最终失败。 开发环境不好，影响工作效率。过程管理不严格，造成大量返工。员工培训不够，个人能力欠缺。职责不清、分工不明，造成时间浪费。员工缺少工作激情，影响进度。 软件项目常见前5项风险 制定风险应对策略 接纳风险（Acceptance），可以承担