作者：吴 锋 清华大学项目管理在职研究生 2006届春季班 小组论文
【摘要】软件项目所处自然、经济、社会、政治环境中，每一个项目都有风险。完全避开或消除风险，或只享受权益而不担风险，是不可能的。因此需要对项目风险进行认真分析和科学管理，可避开不利条件，少受损失，取得预期结果，实现项目的目标。本文系统的讲述了风险在项目中的概念、种类、避免以及应对方法。
【关键词】 风险 软件过程
1．软件开发的过程综述
众所周知，软件开发过程可分为：需求分析、设计、编码、测试、安装及维护等几个过程，实际上一个完整的软件项目前后还有其它过程，在这里列出的只是和软件开发相关的核心过程。软件项目的生命周期可以分为四个阶段（不同行业的项目生命周期不同），即初始阶段、设计阶段、实施阶段、收尾阶段。软件开发过程在软件项目的这四个阶段中的分布情况如下（括弧里面表示RUP方法中的过程）：
初始阶段：大部分需求分析，少部分设计（大部分业务建模和需求，少部分分析设计）
设计阶段：大部分设计，少部分编码（大部分分析设计，部分实施及测试，开始考虑部署）
实施阶段：大部分编码和测试，少部分设计（大部分实施及测试，部分部署）
收尾阶段：安装及维护（大部分部署）
而项目管理则贯穿在整个生命周期的每个阶段。根据PMBOK，项目管理可以从范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理等9个方面考虑，对于软件项目管理来讲软件配置管理（属于整体管理）、软件质量管理、软件风险管理及开发人员管理（属于人力资源管理）等四个方面的管理尤为重要，软件开发的每个阶段、每个过程都要重视这几方面的管理。
本文就以软件项目的风险管理为主题展开讨论。
2．项目风险的存在
系统开发是带有创造性的活动，这意味着人们不可能完全预测会发生的事情，因此制定一个详细的计划很难。当有预想不到的事情引起项目脱离正常轨道时，以上两种观点都会导致项目失败。
一般来说，软件工程师总是非常乐观。当他们在计划软件项目时，经常认为每件事情都会像计划那样运行，或者，又会走向另外一个极端。软件开发的创造性本质意味着我们不能完全预测会发生的事情，因此制定一个详细计划的关键点很难确定。当有预想不到的事情引起项目脱离正常轨道时，以上两种观点都会导致软件项目的失败。
下面我们举几个真实存在的项目风险的例子：
我们开发一个软件产品，或多或少会用到第三方的硬件设备或软件系统，而第三方设备或软件的不稳定就是一个风险。解决的办法有两个，尽量减少对第三方产品的依赖，或者和第三方商场建立良好的合作关系，共同进行二次开发和升级。
技术风险是大家都能预见，可又都不能完全预见的风险。在项目开始之前，最好就能做一些前瞻性的技术研究，作为技术储备。对项目所要采用的技术，尤其是新技术，一定要做技术可行性验证，对新技术进行风险评估，经过严格的评审才能确定采用。项目组最好能拥有一到两位该技术领域的技术专家，并对项目组全体成员进行技术培训。在采用新技术时，可以通过逐步过渡的方法，即先在某个模块试用新技术，然后再逐步推广，通过这种办法，可以在一定程度上减少新技术的风险，也可以给开发人员一个学习和试用的机会。或者采用快速原型法进行开发，先做出一个小的DEMO，验证和试用新技术。
如今网络日益发达，病毒也日益猖獗，所以病毒对软件开发的影响也不能忽视。预防这个风险，就是要做好病毒的预防和查杀工作，同时做好软件产品的备份工作。想到了机器病毒，就不难想到人类的病毒。员工生病也会影响开发进度。软件公司的员工一般都缺乏运动，生活不规律。公司除了尽量避免加班外，应鼓励员工进行体育锻炼，或组织一些体育活动。另外，当有员工生病时，应尽量保证生病员工的休息时间，以期尽早康复，恢复正常工作：当发生流行性疾病时，应做好预防工作。如果员工病假时间较长，应重新分配和安排工作内容(需要有技术备份)，以免影响项目进度。
3 什么是风险
软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。风险关注未来的事情，这意味着，风险涉及选择及选择本身包含的不确定性，在软件开发过程及软件产品都要面临各种决策的选择。风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。另一方面，风险将涉及思想、观念、行为、地点等因素的改变。 当在软件工程领域考虑风险时，我们要关注以下的问题：什么样的风险会导致软件项目的彻底失败？用户需求、开发技术、目标计算机、以及所有其它与项目有关的因素的改变将会对按时交付和总体成功产生什么影响？对于采用什么方法和工具，需要多少人员参与工作的问题，我们如何选择和决策？对软件质量要达到什么程度才是“足够的”？
当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了。在我们能够标识出软件项目中的真正风险之前，识别出所有对管理者和开发者而言均为明显得风险是很重要的。
IT行业中的软件项目开发是一项可能损失的活动，不管开发过程如何进行都有可能超出预算或时间延迟。项目开发的方式很少能保证开发工作一定成功，都要冒一定的风险，也就需要进行项目风险分析。在进行项目风险分析时，重要的是要量化不确定的程度和每个风险相当的损失程度，为实现这一点就必须要考虑以下问题：
要考虑未来，什么样的风险会导致软件项目失败？
要考虑变化，在用户需求、开发技术、目标、机制及其它与项目有关的因素的改变将会对按时交付和系统成功产生什么影响？
必须解决选择问题，应采用什么方法和工具，应配备多少人力，在质量上强调到什么程度才满足要求？
要考虑风险类型，是属于项目风险、技术风险、商业风险、管理风险还是预算风险等？
这些潜在的问题可能会对软件项目的计划、成本、技术、产品的质量及团队的士气都有负面的影响。风险管理就是在这些潜在的问题对项目造成破坏之前识别、处理和排除。目前，风险管理被认为是IT软件项目中减少失败的一种重要手段。当不能很确定地预测将来事情的时候，可以采用结构化风险管理来发现计划中的缺陷，并且采取行动来减少潜在问题发生的可能性和影响。风险管理意味着危机还没有发生之前就对它进行处理。这就提高了项目成功的机会和减少了不可避免风险所产生的后果。
4．风险的种类
风险分管理风险、技术风险和商业风险。
管理风险：是指在项目过程中由于项目的复杂性、规模、结构的不确定性而导致预算不准确，进度计划制定和资源配置不合理 ，计划粗糙、质量控制差，项目管理的基本原则使用不当等，都会给软件项目的风险。
技术风险：是指若项目采用了过时或太新的技术，或者采用了非常规的方法，而存在的潜在的设计、实现、接口、检验和维护方面的问题。另外，若技术目标制定过高，或技术标准发生变化等，也会产生技术风险。
商业风险：有五种
建立的软件虽然很优秀但不是市场真正所想要的；
建立的软件不符合公司整个产品战略；
建立的软件销售部门不清楚如何推销；
由于重点转移或人员变动而失去上级管理部门的支持；
没有得到预算或人员的保证。
组织风险：是指由于组织内部对目标未达成一致，高层对项目不重视，资金不足，项目组织的人员结构不合理或与其他项目有资源冲突等，都是潜在的组织风险。
外部风险：是指法律法规的变化，与项目相关的各方发生变化，这些事件和外部环境变化往往是不可控制的。但一般不把不可控制的“不可抗力”当作风险，而是把它们看作是灾难来对待。
此外，还可以将风险分为已知风险（如员工离职）、可预报风险（从以往经验或者相似项目得出的可能存在的风险）和不可预知风险（如政策变化等）。从经验来看，软件项目的外部环境，如采购方、分包商、客户等方面情况的变化是项目产生重大风险的主要原因；另外，项目实施所需的一些前提，如软件工具、设备、资源等不能满足，也会成为项目的风险。
5．风险管理
项目风险管理是对项目风险进行识别、分析和应对的系统的过程。它包括把对于项目而言正面事件的概率和影响结果扩到最大和把负面事件的概率和影响结果减少到最小。项目风险管理实际上就是贯穿在项目开发过程中的一系列管理步骤，其中包括风险识别、风险估计、风险管理策略、风险解决和风险监控。它能让风险管理者主动“攻击”风险，进行有效的风险管理。
在项目管理中，建立风险管理策略和在项目的生命周期中不断控制风险是非常重要的，风险管理包括四个相关阶段：
风险识别 识别风险的方法常用的有风险识别问询法（座谈法、专家法）、财务报表法、流程图法、现场观察法、相关部门配合法和环境分析法等。
风险评估 对已识别的风险要进行估计和评价，风险估计的主要任务是确定风险发生的概率与后果，风险评价则是确定该风险的经济意义及处理的费/效分析，常用的方法有：概率分布、外推法、多目标分析法等。
风险处理 一般而言，风险处理有三种方法，①风险控制法，即主动采取措施避免风险，消灭风险，中和风险或采用紧急方案降低风险。②风险自留，当风险量不大时可以余留风险。③风险转移。
风险监控 包括对风险发生的监督和对风险管理的监督，前者是对已识别的风险源进行监视和控制，后者是在项目实施过程中监督人们认真执行风险管理的组织和技术措施。
此外，还存在有很多的风险管理模型，但是多数都是类似的。下图是Barry Boehm在1989年提出的模型（详细介绍请参照相关资料）。
图1. Boehm模型
目前，风险管理被认为是IT软件项目中减少失败的一种重要手段。当不能很确定地预测将来事情的时候，可以采用风险管理来发现计划中的缺陷，并且采取行动来减少潜在问题发生的可能性和影响。对软件项目进行风险管理，在国际上已经成为项目管理的重要方面。例如，世界银行对每一个贷款项目都要进行风险分析，制定风险管理计划，写进有关文件，并付诸行动。
在IT软件项目管理中，应该任命一名风险管理者，该管理者的主要职责是在制订与评估规划时，从风险管理的角度对项目规划或计划进行审核并发表意见，不断寻找可能出现的任何意外情况，试着指出各个风险的管理策略及常用的管理方法，以随时处理出现的风险，风险管理者最好是由项目主管以外的人担任。
6．风险识别
识别风险是系统化地识别已知的和可预测的风险，在可能时避免这些风险，且当必要时控制这些风险。根据风险内容，我们可以将风险分为： （1）产品规模风险：与软件的总体规模相关的风险。 （２）商业影响风险：商业风险影响到软件开发的生存能力。商业风险包含的五个主要的风险是：
开发了一个没有人真正需要的优秀产品或系统（市场风险）；
开发的产品不符合公司的整体商业策略（策略风险）；
开发了一个销售部门不知道如何去卖的产品（销售风险）；
由于重点的转移或人员的变动而失去了高级管理层的支持的风险（管理风险）；
没有得到预算或人力上的保证（预算风险）
（３）客户特性风险：与客户的素质以及开发者和客户沟通能力相关的风险。
（４）过程定义风险：与软件过程定义相关的风险。
（５）开发环境风险：与开发工具的可用性及质量相关的风险。
（６）技术风险：技术风险是指在设计、实现、接口、验证、维护、规 约的二义性、技术的不确定性、陈旧的技术等方面存在的风险。技术风险 威胁到软件开发的质量及交付的时间，如果技术风险变成现实，则开发 工作可能变得很困难或根本不可能。
（７）人员数目及经验带来的风险：与参与工作的软件工程师的总体技术 水平及项目经验相关的风险。在进行具体的软件项目风险识 别时，可以根据实际情况对风险分类。但简单的分类并不是总行的通 的，某些风险根本无法预测。在这里，我们介绍一下美国空军软件项目风险 管理（Software risk abatement）手册中指出的如何识别软件风险。这种识别方法要求项目管理者根据项目实际情况标识影响软件风险因素的风险驱动因子，这些因素包括以下几个方面。
性能风险：产品能够满足需求和符合使用目的的不确定程度。
成本风险：项目预算能够被维持的不确定的程度。
支持风险：软件易于纠错、适应及增强的不确定的程度。
进度风险：项目进度能够被维持且产品能按时交付的不确定的程度。
每一个风险驱动因子对风险因素的影响均可分为四个影响类别－－－可忽略的、轻微的、严重的及灾难性的。具体内容可以用表2来描述：
图2 影响评估因素分析表
本表指出了由于错误而产生的潜在影响，或者是没有达到预期的结果而产生的影响，影响类别的选择是以最符合表中描述的特性为基础的。
7． 风险评估
对辨识出的风险进行进一步的确认后分析风险，即假设某一风险出现后，分析是否有其他风险出现，或是假设这一风险不出现，分析它将会产生什么情况，然后确定主要风险出现最坏情况后，如何将此风险的影响降低到最小，同时确定主要风险出现的个数及时间。进行风险评估时，最重要的是量化不确定性的程度和每个风险可能造成损失的程度。为了实现这点，必须考虑风险的不同类型。识别风险的一个方法是建立风险清单，清单上列举出在任何时候可能碰到的风险，最重要的是要对清单的内容随时进行维护，更新风险清单，并向所有的成员公开，应鼓励项目团队的每个成员勇于发现问题并提出警告。建立风险清单的一个办法是将风险输入缺陷追踪系统中，建立风险追踪工具，缺失追踪系统一般能将风险项目标示为已解决或尚待处理状态，也能指定解决问题的项目团队成员，并安排处理顺序。风险清单给项目管理提供了一种简单的风险预测技术，风险清单如表3所示：
图3.风险清单
在风险清单中，风险的概率值可以由项目组成员个别估算，然后加权平均，得到一个有代表性的值。也可以通过先做个别估算而后求出一个有代表性的值来完成。对风险产生的影响可以对影响评估的因素进行分析。 一旦完成了风险清单的内容，就要根据概率进行排序，高发生率、高影响的风险放在上方，依次类推。项目管理者对排序进行研究，并划分重要和次重要的风险，对次重要的风险再进行一次评估并排序。对重要的风险要进行管理。从管理的角度来考虑，风险的影响及概率是起着不同作用的，一个具有高影响且发生概率很低的风险因素不应该花太多的管理时间，而高影响且发生率从中到高的风险以及低影响且高概率的风险，应该首先列入管理考虑之中。
在这里，我们需要强调的是如何评估风险的影响，如果风险真的发生了，它所产生的后果会对三个因素产生影响：风险的性质、范围及时间。风险的性质是指当风险发生时可能产生的问题。风险的范围是指风险的严重性及其整体分布情况。风险的时间是指主要考虑何时能够感到风险及持续多长时间。可以利用风险清单进行分析，并在项目进展过程中迭代使用项目组应该定期复查风险清单，评估每一个风险，以确定新的情况是否引起风险的概率及影响发生改变。这个活动可能会添加新的风险，删除一些不再有影响的风险，并改变风险的相对位置。 在风险评估过程中，我们可以采取以下的步骤：
（１）定义项目的风险参考水平值要使风险评估发生作用，就要定义一个风险参考水平值，对于大多数项目而言，通过对性能、成本、支持及进度等因素的分析，可以找出风险的参考水平值，对于性能下降、成本超支支持困难或进度延迟（或者这四种的组合）等情况，超过这一参考水平值项目就会被终止。
（２）建立每一组（风险、风险发生的概率、风险产生的影响）与每一个参考水平值的关系。
（３）预测一组临界点以定义项目终止区域，该区域由一条曲线或不确定区域界定。
（４）预测什么样的风险组合会影响参考水平值。
简而言之，在进行了风险辨识后，我们就要进行风险估算，风险估算从以下几个方面评估风险清单中的每一个风险：
（１）建立一个尺度，以反映风险发生的可能性；
（２）描述风险的后果；
（３）估算风险对项目及产品的
（４）标注风险预测的整体精确度，以免产生误解。
8. 风险缓解、监控和管理
通过对风险的分析确定出风险的等级，对高级的风险要制定出相应的对策，采取特殊的措施予以处理，并指定专人负责重要风险项目的实施，同时在风险管理计划中进行专门的说明。所有风险分析的目的只有一个：辅助项目组建立处理风险的策略。一个有效的策略必须考虑三个问题：
（１） 风险避免；
（２） 风险监控；
（３） 风险管理及意外事件计划。
风险的策略管理可以包含在软件项目计划中，或者风险管理步骤也可以组
成一个独立的风险缓解、监控和管理计划（RMMM计划）。RMMM计划将所有风险分析工作文档化，并且由项目管理者作为整个项目计划的一部分来使用，RMMM计划的大纲主要包括：主要风险，风险管理者，项目风险清单，风险缓解的一般策略、特定步骤，监控的因素和方法，意外事件和特殊考虑的风险管理等。一旦建立了RMMM计划，我们就开始了风险缓解及监控，风险缓解是一种避免问题的活动，风险监控则是跟踪项目的活动。它有三个主要目的：
评估一个被预测的风险是否真的发生了。
保证为风险而定义的缓解步骤被正确地实施。
收集能够用于未来的风险分析信息。
9．风险处理
有些风险是无法预料的，当出现有利于项目的风险的时候要及时的抓住机会，如果出现不利于项目的风险要及时采取措施来把损失降到最低限度。下面我们着重讲解一下出现不利于项目的风险时采取的应对措施：
风险避免：通过改变项目计划或条件，完全消除项目风险，或保护项目目标不受风险影响。虽然完全消除项目风险是不现实的，但一些具体风险还是可以避免的。例如，项目早期澄清需求，听取专家的意见，用成熟的技术代替创新的方法，避免不熟悉的分包商，改善沟通等都是风险避免的例子。一些人命关天的项目，甚至要不惜时间与经济的代价去设法避免风险。
风险转移：是指将项目风险转移给另一方去承担。它只是将风险给了另一方，并没有消除风险。例如，通过合同或购买保险，将项目风险转移给分包商或保险商就是风险转移的例子。
风险缓解：是指降低一个不利风险事件的发生概率，或使它产生的后果达到一个可接受水平的措施。例如，可以通过开发原型以降低需求及人机交互的风险；增加资源或延长交付时间以降低实际进度严重滞后的风险；选择一个可靠的销售商以降低市场风险等。
风险接受：接受风险是指有意识地选择承担风险后果，或项目团队找不出任何风险应对措施。例如，项目经理可能选择接受一个初级开发人员流动带来的风险，如果项目雇佣顶替他的人并进行培训所花的费用与为留住此人所花费的费用大致差不多的话。
风险接受包括主动接受和被动接受。
主动接受包括开发一个风险应急处理计划，当项目风险发生时马上执行。
被动接受不需要采取任何行动，当风险出现时项目团队再去处理。
一个应急处理计划用于应对那些在项目进行 过程中出现的风险。事先开发一个风险应急处理计划可大幅降低风险处理的成本。
风险研究：是指通过调查研究以获得更多有关风险的信息的风险应对措施。例如，当系统需求不清时，通过开发原型系统与用户沟通以澄清用户要求；对于商业软件，通过市场调查常用的消费者调查问卷来获取用户的信息。
风险储备：是指对项目意外风险预留应急费用和进度计划。风险储备用于项 目较新或不确定性较多的场合，以防止项目进度或费用超支。
风险退避：如果风险影响巨大，或者采取的风险应对措施不完全有效，这种情况下就要开发风险退避计划。它可能包括：应急处理补贴、可选择的开发、改变项目范围等。
风险分担：在项目管理中，如果把可能发生的风险分散到更多的工作环节中去，就可以减少风险的损失程度。有两种方法：
分割风险单位：将面临损失的风险单位分割，即“勿把所有鸡蛋放在一个篮子里”。
复制风险单位：增加风险单位的数量，设置备用的资产或设备，当在用的资产或设备遭受损失时把它们投入使用。
结束语：IT项目风险管理研究和实践具有重大的学术和经济意义,但是健康有效地开展这项活动必须有正确的体系指导,同时还要注意不能夸大IT项目风险管理的作用。因为它不能保证辨识出的风险就一定会出现,也不能保证每次风险控制手段都能成功,所以良好的风险管理文化要求人们不能对风险管理活动求全责备。
参考文献：
[1]Keil M, Wallace L, Turk D. An investigation of risk perception and risk propensity on the decision to continue a software development project [J]. The Journal of Systems and Software, 2000, 53:145-157.[
[2]Lister T. Interview with Tim Lister[J].IEEE Software, 1997,14(3):18-19.
[3]
http://www.ciu.net.cn/ 中国软考联盟
[4] 微软项目求生法则 史蒂夫,麦克康奈尔
[5] IT项目管理 Kathy Schwalbe