风险管理指南

风险管理指南

[ 0.2 版 ]

版号 0.1 0.2

履历记录 日期 内容 2007-09-08 根据模板拟定文档规范 2007-10-25 根据评审报告修改问题

责任人 廖永鸿 廖永鸿

审批人

1

目录

1. 概述 ........................................................................... 1 1.1. 目的 ...................................................................... 1 1.2. 读者 ...................................................................... 1 1.3. 角色与职责 ................................................................ 1 2. 风险管理概述 ................................................................... 2 2.1. 软件项目风险 .............................................................. 2 2.2. 项目风险管理 .............................................................. 2 2.3. 风险参数定义 .............................................................. 2 2.3.1. 影响度 .............................................................. 2 2.3.2. 可能性 .............................................................. 3 2.3.3. 紧急度 .............................................................. 3 2.3.4. 风险度 .............................................................. 3 2.4. 风险管理策略 .............................................................. 3 2.4.1. 风险缓解 ............................................................ 3 2.4.2. 转移风险 ............................................................ 3 2.4.3. 回避风险 ............................................................ 4 2.4.4. 接受风险 ............................................................ 4 2.4.5. 用于规避风险的后备措施 .............................................. 4 2.5. 常见风险分类与来源及一般对策 .............................................. 4 2.5.1. 项目管理的风险 ...................................................... 4 2.5.2. 软件技术风险 ........................................................ 4 2.5.3. 软件过程风险 ........................................................ 5 3. 项目风险管理过程 ............................................................... 6 3.1. 风险识别 .................................................................. 6 3.2. 建立风险的处理计划 ........................................................ 6 3.3. 风险监控 .................................................................. 6 4. 风险列表库 ..................................................................... 6

2

深圳市莱恩软件技术有限公司

1. 概述

1.1. 目的

风险管理是识别风险、评估风险、以及采取步骤降低风险到可接受范围内的过程。本指南提 供有效的风险管理方法， 它包括对 IT 系统中风险评估和规避的定义和实践的指南。 最终的目的是 为了帮助公司更好地管理和 IT 相关的业务面临的风险。

1.2. 读者

本指南为在其 IT 系统中支持或使用风险管理过程的人员提供了一个通用的基础， 无论他们富 有经验和经验不足，是技术人员或非技术人员。这些人包括： ◆ 总经理 ◆ 部门经理 ◆ ◆ ◆ ◆ ◆ 技术总监 项目经理 研发部成员 质量部人员 维护人员

1.3. 角色与职责

角色 项目经理 职责 进行全局把握，侧重于项目的商务方面，充当项目组同客户正式交流的接口环 节制定项目开发计划和开发策略，参与项目核心系统的分析设计，同时努力保 证开发 计划的按时完成和开发策略的真正贯彻落实。 质量监督组 编制软件质量控制计划，并负责落实；控制必要文档的生产，通过文档，监督 项目实施过程中软件的质量，并产生软件质量报告，提请项目经理和项目负责 人审阅；对于项目中出现的质量问题，主持召开质量复审会议。对各部门产生 的文档进行格式规范、版本编号和控制、存档文件的检索；协助质量监督组进 行软件质量监督。 通过适当的人员配备和职责划分，能有效的降低软件开发 在后期的失控的可能性，和软件对关键人员的依赖性。 系统分析员 协同项目负责人进行软件系统的分析和设计工作，书写软件需求分析和系统设 计相关文档。在软件实现阶段进行测试策略的编制和对性能测试的指导。 程序员 协助分析人员进行详细设计， 和软件系统的代码实现， 并进行适当的白盒测试。 协同系统分析人员听取用户需求，对需求分析进行参考性复审。协同测试人员

2007-09-04

第 1 页

深圳市莱恩软件技术有限公司

进行测试，书写操作手册和在线帮助，在项目交付用户之后进行跟踪服务。 测试员 已经实现的软件组件、构件或系统进行正确性验证测试，整合后的系统的性能 测试等。书写测试报告和测试统计报告提请质量监督组复审。

2. 风险管理概述

2.1. 软件项目风险

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项 目的影响。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的 进度，增加项目的成本，甚至使软件项目不能实现。如果对项目进行风险管理，就可以最大限度 的减少风险的发生。

2.2. 项目风险管理

项目风险管理是指为了最好的达到项目的目标，识别、分配、应对项目生命周期内风险的科 学与艺术。 项目风险管理的目标是使潜在机会或回报最大化，使潜在风险最小化。风险管理涉及的主要 过程包括：风险识别，风险量化，风险应对计划制定，风险监控，风险规避和风险总结，风险识 别在项目的开始时就要进行，并在项目执行中不断进行。 在项目的整个生命周期内，风险管理是一个持续的过程。

2.3. 风险参数定义

2.3.1.影响度

风险影响度指的是风险产生后对整个项目造成的影响面的广度，影响度越高表示风险越大。 影响度的等级分别用高中低来表示，具体的定义如下： 等级 高 10 等级值 定义 风险一旦产生，进度滞后>=30%，费用增加>=30%，质量降低影响交付 导致验收困难，范围扩大到项目接受困难的程度 中 5 风险一旦产生，进度滞后 10%-30%，费用增加 10%-30%，质量降低影 响内部验收困难，范围主要方面收到影响 低 1 风险一旦产生，进度滞后

2007-09-04

第 2 页

深圳市莱恩软件技术有限公司

2.3.2.可能性

是一个 0-1 之间的值，值越大表示风险产生的可能性越大。

2.3.3.紧急度

紧急度越高，表示需要解决的迫切程度越高，越需要优先解决。 等级 高 中 低 10 5 1 等级值 定义 风险一个星期内可能发生，需要立即解决 风险一个月内可能发生 风险一个月以上可能发生

2.3.4.风险度

是风险产生的一个综合指标。它的计算公式： 风险度 = 影响度 × 紧急度 × 可能性。

2.4. 风险管理策略

在风险管理规划基础上进行风险控制，一旦监视到风险，就应采取合理措施进行风险规避， 可以从改变风险性质、改变风险发生的概率、改变风险的影响大小等多方面着手。 风险规避的策略一般有缓解、转移、回避、接受、后备措施等几种方式。 其中，预防风险尤其不能忽视项目的教育培训和按程序办事两个方面。由于项目实施成员的 任何不当行为都会构成项目的风险因素，要减轻与之相应的影响，就必须对有关人员进行详细和 有效的风险教育和项目培训，教育培训的内容应该包含项目相关的策略、计划、标准、规章规范、 项目知识、产品知识等。 在项目活动中，应该严格按照项目制度，如进度、人力调配、文档管理、资源分配等。

2.4.1.风险缓解

力图降低风险发生的概率和影响。

2.4.2.转移风险

在项目中使用最频繁的应该要数合作伙伴、项目外包、保险与担保等手段了。无论是与合作 伙伴的协同实施还是项目的外包，都能在人力资源、成本费用、项目进度等方面分散风险，开脱 责任。但转移风险的同时也必然带来利润的一部分流失。但是这不是在消除风险！

2007-09-04

第 3 页

深圳市莱恩软件技术有限公司

2.4.3.回避风险

是指当项目风险潜在威胁的可能性极大，并会带来严重的后果，无法转移又不能承受时，通 过改变项目来规避风险。通常会通过修改项目目标、项目范围、项目结构等方式来回避风险的威 胁。例如： 缩小范围 增加资源或延长工期 用熟悉的方法 使用成熟的分包商

2.4.4.接受风险

作为规避风险的常见方法，主要是指主动将风险事件的不利后果承担下来，这种后果通常主 要反映在实施周期、成本费用的有限增加上，以牺牲项目收益而不影响项目整体。主动接受：事 先制定应急计划，风险发生时实施。

2.4.5.用于规避风险的后备措施

主要体现在后备费用、预留进度时间、后备技术力量三个方面，这些后备措施在项目计划中 就应预留，保证在项目实施过程中，能充分调用后备力量解决问题。

2.5. 常见风险分类与来源及一般对策

主要归类为三大类型：项目管理风险、软件技术风险、软件过程风险。

2.5.1.项目管理的风险

2.5.1.1. 描述

主要体现在：合同风险、计划风险、预算/成本风险、进度风险、资源风险、性能风险以及支 持风险。

2.5.1.2.

一般的对策

在该项目中项目监督由项目开发中的质量监督组来实施。 建立明确的角色和职责是任何风险管理计划的关键成功因素。一般参与项目的人员包括管理 者和技术人员。

2.5.2.软件技术风险

2.5.2.1. 描述

软件技术的飞速发展和经验丰富的员工的缺乏，意味着项目可能因为技能的原因而影响到项 目的成功。

2007-09-04

第 4 页

深圳市莱恩软件技术有限公司

2.5.2.2.

一般对策

回避和控制这部分风险可以采取下列措施： 根据员工技能表对项目组成员进行必要的技能培训。例如工具，技术的培训。

2.5.3.软件过程风险

2.5.3.1.

2.5.3.1.1.

软件需求阶段的风险

描述

软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方诱导才能保证 需求的完整，再以书面的形式形成《需求说明书》这一重要的文档。需求分析更多的是开发方确 认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析 的任何疏漏造成的损失会在软件系统的后续阶段被一级一级地放大，因此本阶段的风险最大。

2.5.3.1.2. 一般对策

严格按照公司制定的 《需求工程规范》 实施。 尤其关注需求采集的全面性、 直观的需求确认 (例 如，界面原型)、正式的需求确认(例如，签字)。

2.5.3.2.

2.5.3.2.1.

设计阶段的风险

描述

设计的主要目的在于软件的功能正确的反映了需求。 设计阶段的主要任务是完成系统体系结构的定义，使之能够完成需求阶段的既定目标；另一 方面也是检验需求的一致性和需求分析的完整性和正确性。 系统结构的设计过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成 本的激增。对用户来说系统的使用比例会有明显的折扣，甚至造成软件寿命过短。 反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升， 这又会在实现和测试阶段带来风险，系统的稳定性也会受到影响。 设计阶段蕴涵的另一种风险来自于设计文档。文档的不健全不仅会造成实现阶段的困难，更 会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本升级，甚至是发现 的简单错误都无从更正。

2.5.3.2.2. 一般对策

严格按照公司制定的《概要设计规范》《详细设计规范》实施。尤其关注系统架构/关键技术 、 /技术平台选择、严格的方案评审、严格的需求跟踪。

2.5.3.3.

2.5.3.3.1.

实现阶段引入的风险

描述

软件的实现从某种意义上讲是软件代码的生产。源代码本身也是文档的一部分，同时它又是 将来运行于计算机系统之上的实体。源代码书写的规范性、可读性以及对设计文档的符合性是该 阶段的主要风险来源。规范的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到 最低限度，从而减小了系统整合的风险。

2007-09-04

第 5 页

深圳市莱恩软件技术有限公司

2.5.3.3.2.

一般对策

严格按照公司制定的《代码编写规范》实施。尤其关注代码风格的培训与检查、严格的代码 评审。

2.5.3.4.

2.5.3.4.1.

测试阶段引入的风险

描述

软件的测试直接影响到软件的产品的质量，进而影响到客户验收。

2.5.3.4.2. 一般对策

严格按照公司制定的《测试规范》实施。尤其关注严格的测试方案评审、严格的测试案例评 审。

3. 项目风险管理过程

3.1. 风险识别

项目经理组织项目组成员进行风险识别。 识别的周期：每周一次。 识别的方式： 参考公司风险库识别出风险。 确定风险的参数（包括：可能性、影响度、紧急度） 。 项目经理在做项目进展报告时要将风险识别结果写入进展报告。具体格式参见《项目进展报 告》 。

3.2. 建立风险的处理计划

项目经理制定详细风险应对方案，至少包括应对策略及具体的措施。 若项目风险超出了项目组的处理能力，项目经理必须发送邮件给部门经理，同时抄送给总经 理。 项目经理在做项目进展报告时要将风险计划写入进展报告。具体格式参见《项目进展报告》 。

3.3. 风险监控

项目经理每周跟踪风险应对措施的实施情况及风险的状态，必要时采取规避和应急的措施。 直到风险关闭。项目经理在做项目进展报告时要将风险状态写入进展报告。具体格式参见《项目 进展报告》 。

4. 风险列表库

风险列表库需要不断更新与维护，作为以后风险识别的重要资料。 项目管理风险 风险类型 检查项 对策

2007-09-04

第 6 页

深圳市莱恩软件技术有限公司

计划编制风险

组织管理风险

人员风险

项目经理基于估计结果与客户、上级领导、 市场部门等相关人员进行协调， 强调各种情 况下的项目承受能力和风险， 并最终与各方 达成一致。 计划是优化的，是"最佳状态"，但 制定计划时，一定要考虑后备资源，富余时 计划不现实，只能算是"期望状态" 间。 产品规模(代码行数、功能点、与前 基于估计结果与相关各方协调， 缩减项目范 一产品规模的百分比)比估计的要 围、提高生产效率、增加项目成员或者延长 大 项目时间 完成目标日期提前，但没有相应地 遵循公司的变更管理规范调整产品范围或 调整产品范围或可用资源 可用资源 涉足不熟悉的产品领域，花费在设 在需求阶段多收集产品的资料， 或者调研竞 计和实现上的时间比预期的要多 争对手的产品； 在制定项目计划时适当调低 项目的生产率 管理层审查、决策的周期比预期的 在制定项目计划时考虑到审查、决策的周 时间长 期，事先预留；向 EPG 建议优化审查、决策 的流程 预算削减，打乱项目计划 做项目计划时，考虑预算削减的风险；遵循 公司的变更管理规范缩减项目范围乃至取 消项目 缺乏必要的规范，导致工作失误与 按照《项目管理规范》严格实施 重复工作 开发额外的不需要的功能(镀金)， 按照《需求规格说明书》开发 延长了计划进度 严格要求与现有系统兼容，需要进 设计之前要求对现有系统有深入的理解 行比预期更多的测试、设计和实现 工作 要求与其他系统或不受本项目组控 设计之前要求其他系统给出明确的接口 制的系统相连，导致无法预料的设 计、实现和测试工作 开发人员和管理层之间关系不佳， 项目经理加强和开发人员间的沟通 导致决策缓慢，影响全局 缺乏激励措施，士气低下，降低了 项目经理要学习一些常用的激励下属的方 生产能力 法 由于项目组成员之间发生冲突，导 项目经理组织一些活动， 加强成员组之间的 致沟通不畅、设计欠佳、接口出现 沟通 错误和额外的重复工作 不适应工作的成员没有调离项目 调换成员 组，影响了项目组其他成员的积极 性 软件过程风险

计划、资源和产品定义全凭客户或 上层领导口头指令，并且不完全一 致

风险类型 需求风险

检查项 添加额外的需求

对策 视为需求变更处理

批注 [S1]: 表头颜色不一。下表 同。

2007-09-04

第 7 页

2007-09-04 第 8 页

风险管理指南

[ 0.2 版 ]

版号 0.1 0.2

履历记录 日期 内容 2007-09-08 根据模板拟定文档规范 2007-10-25 根据评审报告修改问题

责任人 廖永鸿 廖永鸿

审批人

1

目录

1. 概述 ........................................................................... 1 1.1. 目的 ...................................................................... 1 1.2. 读者 ...................................................................... 1 1.3. 角色与职责 ................................................................ 1 2. 风险管理概述 ................................................................... 2 2.1. 软件项目风险 .............................................................. 2 2.2. 项目风险管理 .............................................................. 2 2.3. 风险参数定义 .............................................................. 2 2.3.1. 影响度 .............................................................. 2 2.3.2. 可能性 .............................................................. 3 2.3.3. 紧急度 .............................................................. 3 2.3.4. 风险度 .............................................................. 3 2.4. 风险管理策略 .............................................................. 3 2.4.1. 风险缓解 ............................................................ 3 2.4.2. 转移风险 ............................................................ 3 2.4.3. 回避风险 ............................................................ 4 2.4.4. 接受风险 ............................................................ 4 2.4.5. 用于规避风险的后备措施 .............................................. 4 2.5. 常见风险分类与来源及一般对策 .............................................. 4 2.5.1. 项目管理的风险 ...................................................... 4 2.5.2. 软件技术风险 ........................................................ 4 2.5.3. 软件过程风险 ........................................................ 5 3. 项目风险管理过程 ............................................................... 6 3.1. 风险识别 .................................................................. 6 3.2. 建立风险的处理计划 ........................................................ 6 3.3. 风险监控 .................................................................. 6 4. 风险列表库 ..................................................................... 6

2

深圳市莱恩软件技术有限公司

1. 概述

1.1. 目的

风险管理是识别风险、评估风险、以及采取步骤降低风险到可接受范围内的过程。本指南提 供有效的风险管理方法， 它包括对 IT 系统中风险评估和规避的定义和实践的指南。 最终的目的是 为了帮助公司更好地管理和 IT 相关的业务面临的风险。

1.2. 读者

本指南为在其 IT 系统中支持或使用风险管理过程的人员提供了一个通用的基础， 无论他们富 有经验和经验不足，是技术人员或非技术人员。这些人包括： ◆ 总经理 ◆ 部门经理 ◆ ◆ ◆ ◆ ◆ 技术总监 项目经理 研发部成员 质量部人员 维护人员

1.3. 角色与职责

角色 项目经理 职责 进行全局把握，侧重于项目的商务方面，充当项目组同客户正式交流的接口环 节制定项目开发计划和开发策略，参与项目核心系统的分析设计，同时努力保 证开发 计划的按时完成和开发策略的真正贯彻落实。 质量监督组 编制软件质量控制计划，并负责落实；控制必要文档的生产，通过文档，监督 项目实施过程中软件的质量，并产生软件质量报告，提请项目经理和项目负责 人审阅；对于项目中出现的质量问题，主持召开质量复审会议。对各部门产生 的文档进行格式规范、版本编号和控制、存档文件的检索；协助质量监督组进 行软件质量监督。 通过适当的人员配备和职责划分，能有效的降低软件开发 在后期的失控的可能性，和软件对关键人员的依赖性。 系统分析员 协同项目负责人进行软件系统的分析和设计工作，书写软件需求分析和系统设 计相关文档。在软件实现阶段进行测试策略的编制和对性能测试的指导。 程序员 协助分析人员进行详细设计， 和软件系统的代码实现， 并进行适当的白盒测试。 协同系统分析人员听取用户需求，对需求分析进行参考性复审。协同测试人员

2007-09-04

第 1 页

深圳市莱恩软件技术有限公司

进行测试，书写操作手册和在线帮助，在项目交付用户之后进行跟踪服务。 测试员 已经实现的软件组件、构件或系统进行正确性验证测试，整合后的系统的性能 测试等。书写测试报告和测试统计报告提请质量监督组复审。

2. 风险管理概述

2.1. 软件项目风险

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项 目的影响。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的 进度，增加项目的成本，甚至使软件项目不能实现。如果对项目进行风险管理，就可以最大限度 的减少风险的发生。

2.2. 项目风险管理

项目风险管理是指为了最好的达到项目的目标，识别、分配、应对项目生命周期内风险的科 学与艺术。 项目风险管理的目标是使潜在机会或回报最大化，使潜在风险最小化。风险管理涉及的主要 过程包括：风险识别，风险量化，风险应对计划制定，风险监控，风险规避和风险总结，风险识 别在项目的开始时就要进行，并在项目执行中不断进行。 在项目的整个生命周期内，风险管理是一个持续的过程。

2.3. 风险参数定义

2.3.1.影响度

风险影响度指的是风险产生后对整个项目造成的影响面的广度，影响度越高表示风险越大。 影响度的等级分别用高中低来表示，具体的定义如下： 等级 高 10 等级值 定义 风险一旦产生，进度滞后>=30%，费用增加>=30%，质量降低影响交付 导致验收困难，范围扩大到项目接受困难的程度 中 5 风险一旦产生，进度滞后 10%-30%，费用增加 10%-30%，质量降低影 响内部验收困难，范围主要方面收到影响 低 1 风险一旦产生，进度滞后

2007-09-04

第 2 页

深圳市莱恩软件技术有限公司

2.3.2.可能性

是一个 0-1 之间的值，值越大表示风险产生的可能性越大。

2.3.3.紧急度

紧急度越高，表示需要解决的迫切程度越高，越需要优先解决。 等级 高 中 低 10 5 1 等级值 定义 风险一个星期内可能发生，需要立即解决 风险一个月内可能发生 风险一个月以上可能发生

2.3.4.风险度

是风险产生的一个综合指标。它的计算公式： 风险度 = 影响度 × 紧急度 × 可能性。

2.4. 风险管理策略

在风险管理规划基础上进行风险控制，一旦监视到风险，就应采取合理措施进行风险规避， 可以从改变风险性质、改变风险发生的概率、改变风险的影响大小等多方面着手。 风险规避的策略一般有缓解、转移、回避、接受、后备措施等几种方式。 其中，预防风险尤其不能忽视项目的教育培训和按程序办事两个方面。由于项目实施成员的 任何不当行为都会构成项目的风险因素，要减轻与之相应的影响，就必须对有关人员进行详细和 有效的风险教育和项目培训，教育培训的内容应该包含项目相关的策略、计划、标准、规章规范、 项目知识、产品知识等。 在项目活动中，应该严格按照项目制度，如进度、人力调配、文档管理、资源分配等。

2.4.1.风险缓解

力图降低风险发生的概率和影响。

2.4.2.转移风险

在项目中使用最频繁的应该要数合作伙伴、项目外包、保险与担保等手段了。无论是与合作 伙伴的协同实施还是项目的外包，都能在人力资源、成本费用、项目进度等方面分散风险，开脱 责任。但转移风险的同时也必然带来利润的一部分流失。但是这不是在消除风险！

2007-09-04

第 3 页

深圳市莱恩软件技术有限公司

2.4.3.回避风险

是指当项目风险潜在威胁的可能性极大，并会带来严重的后果，无法转移又不能承受时，通 过改变项目来规避风险。通常会通过修改项目目标、项目范围、项目结构等方式来回避风险的威 胁。例如： 缩小范围 增加资源或延长工期 用熟悉的方法 使用成熟的分包商

2.4.4.接受风险

作为规避风险的常见方法，主要是指主动将风险事件的不利后果承担下来，这种后果通常主 要反映在实施周期、成本费用的有限增加上，以牺牲项目收益而不影响项目整体。主动接受：事 先制定应急计划，风险发生时实施。

2.4.5.用于规避风险的后备措施

主要体现在后备费用、预留进度时间、后备技术力量三个方面，这些后备措施在项目计划中 就应预留，保证在项目实施过程中，能充分调用后备力量解决问题。

2.5. 常见风险分类与来源及一般对策

主要归类为三大类型：项目管理风险、软件技术风险、软件过程风险。

2.5.1.项目管理的风险

2.5.1.1. 描述

主要体现在：合同风险、计划风险、预算/成本风险、进度风险、资源风险、性能风险以及支 持风险。

2.5.1.2.

一般的对策

在该项目中项目监督由项目开发中的质量监督组来实施。 建立明确的角色和职责是任何风险管理计划的关键成功因素。一般参与项目的人员包括管理 者和技术人员。

2.5.2.软件技术风险

2.5.2.1. 描述

软件技术的飞速发展和经验丰富的员工的缺乏，意味着项目可能因为技能的原因而影响到项 目的成功。

2007-09-04

第 4 页

深圳市莱恩软件技术有限公司

2.5.2.2.

一般对策

回避和控制这部分风险可以采取下列措施： 根据员工技能表对项目组成员进行必要的技能培训。例如工具，技术的培训。

2.5.3.软件过程风险

2.5.3.1.

2.5.3.1.1.

软件需求阶段的风险

描述

软件的开发是以用户的需求开始，在大多数情况下，用户需求要靠软件开发方诱导才能保证 需求的完整，再以书面的形式形成《需求说明书》这一重要的文档。需求分析更多的是开发方确 认需求的可行性和一致性的过程，在此阶段需要和用户进行广泛的交流和确认。需求和需求分析 的任何疏漏造成的损失会在软件系统的后续阶段被一级一级地放大，因此本阶段的风险最大。

2.5.3.1.2. 一般对策

严格按照公司制定的 《需求工程规范》 实施。 尤其关注需求采集的全面性、 直观的需求确认 (例 如，界面原型)、正式的需求确认(例如，签字)。

2.5.3.2.

2.5.3.2.1.

设计阶段的风险

描述

设计的主要目的在于软件的功能正确的反映了需求。 设计阶段的主要任务是完成系统体系结构的定义，使之能够完成需求阶段的既定目标；另一 方面也是检验需求的一致性和需求分析的完整性和正确性。 系统结构的设计过于定制，系统的可扩展性较弱，会给后期维护带来巨大的负担，和维护成 本的激增。对用户来说系统的使用比例会有明显的折扣，甚至造成软件寿命过短。 反之，软件结构的过于灵活和通用，必然引起软件实现的难度增加，系统的复杂度会上升， 这又会在实现和测试阶段带来风险，系统的稳定性也会受到影响。 设计阶段蕴涵的另一种风险来自于设计文档。文档的不健全不仅会造成实现阶段的困难，更 会在后期的测试和维护造成灾难性的后果，例如根本无法对软件系统进行版本升级，甚至是发现 的简单错误都无从更正。

2.5.3.2.2. 一般对策

严格按照公司制定的《概要设计规范》《详细设计规范》实施。尤其关注系统架构/关键技术 、 /技术平台选择、严格的方案评审、严格的需求跟踪。

2.5.3.3.

2.5.3.3.1.

实现阶段引入的风险

描述

软件的实现从某种意义上讲是软件代码的生产。源代码本身也是文档的一部分，同时它又是 将来运行于计算机系统之上的实体。源代码书写的规范性、可读性以及对设计文档的符合性是该 阶段的主要风险来源。规范的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到 最低限度，从而减小了系统整合的风险。

2007-09-04

第 5 页

深圳市莱恩软件技术有限公司

2.5.3.3.2.

一般对策

严格按照公司制定的《代码编写规范》实施。尤其关注代码风格的培训与检查、严格的代码 评审。

2.5.3.4.

2.5.3.4.1.

测试阶段引入的风险

描述

软件的测试直接影响到软件的产品的质量，进而影响到客户验收。

2.5.3.4.2. 一般对策

严格按照公司制定的《测试规范》实施。尤其关注严格的测试方案评审、严格的测试案例评 审。

3. 项目风险管理过程

3.1. 风险识别

项目经理组织项目组成员进行风险识别。 识别的周期：每周一次。 识别的方式： 参考公司风险库识别出风险。 确定风险的参数（包括：可能性、影响度、紧急度） 。 项目经理在做项目进展报告时要将风险识别结果写入进展报告。具体格式参见《项目进展报 告》 。

3.2. 建立风险的处理计划

项目经理制定详细风险应对方案，至少包括应对策略及具体的措施。 若项目风险超出了项目组的处理能力，项目经理必须发送邮件给部门经理，同时抄送给总经 理。 项目经理在做项目进展报告时要将风险计划写入进展报告。具体格式参见《项目进展报告》 。

3.3. 风险监控

项目经理每周跟踪风险应对措施的实施情况及风险的状态，必要时采取规避和应急的措施。 直到风险关闭。项目经理在做项目进展报告时要将风险状态写入进展报告。具体格式参见《项目 进展报告》 。

4. 风险列表库

风险列表库需要不断更新与维护，作为以后风险识别的重要资料。 项目管理风险 风险类型 检查项 对策

2007-09-04

第 6 页

深圳市莱恩软件技术有限公司

计划编制风险

组织管理风险

人员风险

项目经理基于估计结果与客户、上级领导、 市场部门等相关人员进行协调， 强调各种情 况下的项目承受能力和风险， 并最终与各方 达成一致。 计划是优化的，是"最佳状态"，但 制定计划时，一定要考虑后备资源，富余时 计划不现实，只能算是"期望状态" 间。 产品规模(代码行数、功能点、与前 基于估计结果与相关各方协调， 缩减项目范 一产品规模的百分比)比估计的要 围、提高生产效率、增加项目成员或者延长 大 项目时间 完成目标日期提前，但没有相应地 遵循公司的变更管理规范调整产品范围或 调整产品范围或可用资源 可用资源 涉足不熟悉的产品领域，花费在设 在需求阶段多收集产品的资料， 或者调研竞 计和实现上的时间比预期的要多 争对手的产品； 在制定项目计划时适当调低 项目的生产率 管理层审查、决策的周期比预期的 在制定项目计划时考虑到审查、决策的周 时间长 期，事先预留；向 EPG 建议优化审查、决策 的流程 预算削减，打乱项目计划 做项目计划时，考虑预算削减的风险；遵循 公司的变更管理规范缩减项目范围乃至取 消项目 缺乏必要的规范，导致工作失误与 按照《项目管理规范》严格实施 重复工作 开发额外的不需要的功能(镀金)， 按照《需求规格说明书》开发 延长了计划进度 严格要求与现有系统兼容，需要进 设计之前要求对现有系统有深入的理解 行比预期更多的测试、设计和实现 工作 要求与其他系统或不受本项目组控 设计之前要求其他系统给出明确的接口 制的系统相连，导致无法预料的设 计、实现和测试工作 开发人员和管理层之间关系不佳， 项目经理加强和开发人员间的沟通 导致决策缓慢，影响全局 缺乏激励措施，士气低下，降低了 项目经理要学习一些常用的激励下属的方 生产能力 法 由于项目组成员之间发生冲突，导 项目经理组织一些活动， 加强成员组之间的 致沟通不畅、设计欠佳、接口出现 沟通 错误和额外的重复工作 不适应工作的成员没有调离项目 调换成员 组，影响了项目组其他成员的积极 性 软件过程风险

计划、资源和产品定义全凭客户或 上层领导口头指令，并且不完全一 致

风险类型 需求风险

检查项 添加额外的需求

对策 视为需求变更处理

批注 [S1]: 表头颜色不一。下表 同。

2007-09-04

第 7 页

2007-09-04 第 8 页