软件项目风险

软件项目风险（精选十篇）

软件项目风险 篇1

1.1 风险的定义

风险定义有好几种, 一是不希望事物发生变化, 二是事物存在很多的, 三是事件产生的影响。可以概括为“人们因对未来行为的决策及客观条件的不确定性而可能引起的后果与预定目标发生多种负偏离的综合。”公式表现为:风险f (事件, 不确定性, 后果) 。用数学表达式则为:R=f (s, P, X) , 其中R表示风险, S表示时间, P表示不利事件发生的概率, X表示该事件发生的后果。

1.2 风险管理的背景

随着社会对软甲的需求增大, 软件的开发技术不断更新, 难度不断增大, 但软件的数量却依然增加很多, 同时随着社会节奏加快, 软件的供应商需要提供不间断的软件更新服务。但与此同时, 各种难度的上升, 给企业在开发软件的过程中加大了风险。软件项目能否开发成功, 关系着一个企业的生死存亡。但矛盾的是, 随着开发软件的业务增大, 但对软件的质量和用途也随之提高, 这对软件开发商造成了巨大的压力, 在这种情况下, 软件风险管理和控制成为软件开发成败的关键点。

根据有关资料调查显示, 有百分之十五到百分之三十五的软件项目在开发的过程中被取消, 剩下的软件项目有的是没有在预期内完成而夭折, 或者又是软件开发的过程中超出了经费的预算。除此之外还有软件项目因为风险管理和控制失败的大约占百分之九十。目前国内的大多数软件开发企业还缺乏对软件开发项目的风险认识, 缺少进行系统、有效的度量和评价的手段。所以能建立有效的风险识别、风险分析、风险计划、风险跟踪和风险对策的机制, 是有效提高软件开发成功率的方法之一。

2 风险管理的内容

为了最大化的减少软件风险的发生, 可对软件项目进行风险管理。而软件项目风险管理过程是指软件风险从认识到采取措施的过程包括风险识别、风险分析、风险计划、风险跟踪和风险对策等, 从而将可控因素最大化, 将不可控因素到最小, 从而对未知的风险消灭, 从而对风险进行回避或者缓解。

2.1 风险识别

风险识别的常用方法通常有现场观察法, 财务报表法、环境分析法、流程图法、座谈法、相关部门配合法等。风险识别要确定影响本项目的潜在威胁的来源以及在何种条件有影响, 怎么产生并有什么特性等, 风险识别并不是一次就可以后顾无忧的, 需要贯彻到整个软件的生命周期中。

2.2 风险评估

风险评估时对风险影响力进行衡量的活动, 即衡量风险发生的概率和风险发生后对项目目标的影响程度, 从而为后面制定风险对策提供依据。对已识别的风险要进行估计和评价, 常用的方法有:概率分布、外推法、多目标分析法等。

2.3 风险计划

风险计划:风险计划是通过技术手段或者其他方法来降低风险的发生, 将风险评估后的结果进行处理。风险计划就是在软件开发的过程中起指导作用, 如先处理那个风险, 怎么消除风险, 如何避免风险等。

2.4 风险应对

风险应对就是对风险计划的执行, 共有三种方向来进行风险应对。一是风险控制法, 对存在风险进行主动出击进行消灭或许能避免风险:二是转移风险, 将存在的风险进行转移:三是风险存留, 就是风险威胁不大时, 可以对风险不采取任何措施。当然在软件的开发过程中, 要想有效的消灭风险, 就得让风险还在初级阶段的时候消灭。再者就是风险发生时, 要考虑后果再最大化的缓解风险。

3 风险的分类及各类风险产生的影响

3.1 组织和管理风险

一是管理层做出了错误决定, 技术决策导致计划进度缓慢, 延长计划时间;二是低效的项目组结构降低生产率;三是管理层审查决策的周期比预期的时间长;四是预算削减, 打乱项目计划;五是工作失误与重复工作;六是非技术的第三方的工作时间比预期的延长。

3.2 需求风险

在软件开发的过程中, 如果不能控制和需求有关的风险因素, 那么将会产生不好的结果, 如软件有可能是错误的软件或者质量不合格的软件。当然很多软件开发项目都会面对这些不确定的威胁, 如果早期对于这些不确定的风险置之不理, 那么在项目过程中也得不到解决, 那么“千里之堤, 溃于蚁穴”, 这些不能控制的威胁将对软件成功的开发造成巨大的威胁。

与客户相关的风险因素有, 第一客户对软件缺少清晰的认识, 没有对开发的软件各方面的特性以及功能有个全面了解。第二对产品需求缺少认同, 当软件成功开发时, 但对软件由于认识度不够或者别的原因导致对开发出来的软件缺少认同感。同时还存在一些需求风险因素如在做需求中客户参与不够, 又或者是没有优先需求, 再就是由于不确定的需要导致新的市场, 其次是不断变化需求和缺少有效的需求变化管理过程以及对需求的变化缺少相关分析等。

3.3 合同风险

风险存在的概率很大, 大多是因为合同里的条款比较多引起的。比如如果在软件开发的过程中, 没有对开发软件的范围有准确的定义, 并且成为合同中一部分时, 此项目即便成功了, 也很难验收, 并且项目开发的时间加长了, 极大的加大了开发的成本。这就符合了软件项目经常以一定的价格签订合同, 但签约方却希望更多的功能。

3.4 设计和实施的风险

在软件开发的准备工作, 因为设计不满足要求, 导致软件重复设计。在无法使用已有的代码或者库实现新开发软件, 导致软件的必要功能有问题, 因此软件开发人员需要重新设计代码或库现实又或者重新开发软件的功能。其次认为增强工具能节省很多时间, 但却没达到应有的预期效果。最后, 不能有效的连接整合开发的模块, 需要重新设计和开发。

3.5 人员风险

软件开发需要大量的人才, 所以人员也是风险的一个因素, 如果软件开发前, 不能对员工进行有效的培训, 那么软件开发必然受到一定的影响。再就是开发员工们和领导的关系不好, 那么必然导致领导的决策执行缓慢, 且效率不高, 工作积极性不佳, 必然影响全局。领导层不仅要和开发人员交流沟通, 塑造一种团结合作的气氛, 同时必须鼓励员工可以是口头赞许或者是物质奖励激发开发人员的工作积极性。对于员工有可能不熟悉公司的开发环境和开发工具, 其次是在软件开发过程中, 有可能后来加入的开发员工, 不熟悉开发软件的现状, 所以就需要加大开发员工之间的沟通。对于一些评估不好的开发人员, 在软件开发的过程, 由于自身的缺点而影响到其他开发人员的积极性又或者同个组里的人员因为某些事情而发生争吵, 导致沟通不利, 所以导致设计不妥或者其他一些小错误出现。最后就是企业没有招到拥有特定的人才来开发一些特别的软件。

3.6 过程风险

在软件开发的过程中, 过程因素也是一个不容忽视的风险, 在开发过程中, 如果纸面上的设计跟不上该项目工程的实施, 那么将会导致进程的计划严重推迟。如果软件开发的前期, 没有做好充分的准备工作, 那么将会导致后期工程的风险大大增加, 基础没打牢, 将会导致后期需要重复的做基础工作。其次是, 编程人员与设计人员没有良好的沟通交流, 导致软件的出炉不能符合设计员的想法, 导致质量不达标, 严重时需要重新开发软件。有时候过于守旧即就是对软件的规则反反复复的提及, 这将会导致无用功做的过多, 而实际工作少, 这也会推荐软件完成计划推迟。其次是软件开放程序员大部分时间用于软件开发的实时过程报告而占用过多的时间, 这也会将原定计划打乱。最后, 由于风险管理不细心, 没有发现软件存在的风险。

3.7 质量风险

质量风险通俗来说就是质量没达到客户的期望, 但产品质量如何好, 其风险总是存在的。在软件测试时, 即便开发商在模拟用户的各种场景及用途, 但也不能保证万无一失, 因为无法覆盖全部的操作路径, 总会存在一定的差异, 所以无法使客户百分百的满意。但是纠结如何消灭质量风险是毫无意义的, 关键是如何降低质量风险, 提高顾客的满意度, 因为提高了软件的质量, 客户的满意度也会随之上升, 这也就是控制质量风险。导致软件质量低下的原因是在原则上对软件的质量实行了保证, 但在实际过程中对软件测试的忽略或不看重;软件的复杂性导致水平要求较高以致很难实现;没能全面理解客户的需求, 导致客户对产品不满意甚至拒收;需求变更导致测试不足, 新产生的严重缺陷没能被发现;设计评审、代码评审不足都可能错过某些严重的问题。

4 风险分析和控制

4.1 风险分析

软件项目风险经常会包括许多方面, 是指软件项目开发风险在其包括开发过程、运作过程、维护过程几个阶段, 它们覆盖了需求、设计、实现、确认以及维护等活动所遇到的所有预算、进度和控制等各方面的问题, 或者是由这些问题而产生对软件项目的影响。如:软件缺乏用户的测试、软件开发没有领导层的支持, 模糊要求, 没有计划和管理等。

为了对风险分析从而进行控制以及管理又或者将风险降到最小, 而这些对软件项目开放的成败具有巨大的影响, 尤其是上述都是软件项目成败的隐患, 所以常常利用风险分析软件对风险进行分析。常用方法有风险条目检查表, 它是利用一组提问来帮助项目风险管理者了解在项目和技术方面有哪些风险。在风险条目检查表中, 列出了所有可能的与每一个风险因素有关的提问, 使得风险管理者集中来识别常见的、已知的和可预测的风险, 如产品规模风险、依赖性风险、需求风险、管理风险及技术风险等。风险条目检查表可以不同的方式组织, 通过假设分析、成本效益分析、风险剖面分析、判定树等, 给出这些提问确定的回答, 就可以帮助项目管理人员估算风险的影响。

为了让软件管理人员和开发人员能够直观的看到在软件开放的各个阶段存在的风险的状况以及每个风险危险的大小, 通常我们可以凭借风险条目检查表来做到。当一个团队接到软件开发的项目时, 通常都是按照自己已有的习惯来开发软件, 但这其中存在风险发生概率比较大, 尤其是在需求风险方面和管理风险方面, 往往决定软件开发的成败。在软件开发完成时存在很多必要的内容缺失, 是因为在软件的分析阶段不够细致, 需求风险意识淡薄所致。在整个软件的开发过程, 如果需求风险控制不好, 那么对软件开发的不利影响是巨大的或者是直接导致软件开发失败。管理风险是软件开发的管理层对与软件开放的风险意识的预见和解决的综合反映。

4.2 风险识别

在软件项目的开发过程中, 风险无处不在。如果不能正确的识别和控制风险, 那么点滴的疏漏就有可能把项目推向崩溃的边缘。

首先, 软件项目风险具有繁殖能力。如果不能识别初级风险, 那么这个风险很可能在项目推进过程中衍生出其他风险

其次, 软件项目风险具有变异能力。如用户需求的定义, 不同设计人员, 定义的结果就会发生差异。

最后, 软件项目风险具有依赖性。风险们互相依赖, 互为因果。它们就像一张无形的网, 如果找不到正确的节点, 那么它们会越搅越乱。

4.3 风险控制

为了转移或避免风险而利用一些技术, 如原型化、软件自动化、软件心理学、可靠性工程学以及某些项目管理方法等叫风险控制。发现问题要立即上报, 尽快解决。并建立风险监管日志, 实行“岗位负责制”, 将软件开发项目的风险降到最低。

参考文献

[1]俞立伟, 薛胜军.软件风险管理[J].电脑知识与技术, 2006 (35) .

[2]梁涛, 欧立雄, 黄柯鑫.基于聚类分析的软件项目风险趋势研究[J].信息工程大学学报, 2006 (01) .

[3]曹光忠.软件项目的风险管理[J].计算机时代, 2005 (06) .

[4]付玉, 邱冠周, 冯其明, 高阳.应用软件开发的需求风险及控制[J].计算机工程与应用, 2005 (13) .

[5]]孟祥睿.软件项目风险管理研究[J].经济论坛, 2005 (07) .

[6]郭研.软件项目管理[J].物流科技, 2005 (02) .

[7]蒋国萍, 陈英武.基于面向对象贝叶斯网络的软件项目风险评估[J].系统工程与电子技术, 2005 (02) .

[8]蒋国萍, 陈英武.基于关键链的软件项目进度风险管理[J].计算机应用, 2005 (01) .

[9]陈忠.软件项目的风险管理[J].经济与社会发展, 2004 (12) .

[10]王敏晰.软件项目管理中人员流动风险的管理[J].商业研究, 2004 (17) .

软件项目风险研究（共） 篇2

摘要： 阐述了软件项目风险的概念和风险定义，并且分析了在软件项目中的风险类型，最后根据风险的定义和类型，分析出相应的风险避免措施。

关键词：风险的概念；风险定义；风险类型；避免措施；

The Analysis Of Software Project Risk

WengHuaBin 10703080227

（ChongQing University Of Technology-Software Engineering）

Abstract: Describes the concept and definitions of software project risk ,And analyzed the types of software projects risk ,Finally, according to the definition and types of Software project risk analysis to avoid the risk of the corresponding measures.Key words: The concept of risk;The definition of risk;The risk types;The avoid measures;

软件行业在社会各界（包括政府、教育机构以及各个企业）的日益剧增的信息化需求下，已经成为高速信息化建设中必不可少的一个元素。所以软件行业要不断的提高稳定程度和运行效率，然而软件项目本身就是一个高风险的项目类型，任何项目都是存在一定的风险性，软件项目更是不例外，所以软件项目需要更好的风险避免措施，只有做到更好更科学的防御措施，才能在最大程度上降低软件项目成本和提高软件项目的成功率。再者，国内外的一些成功的软件项目案例告诉我们，软件项目风险分析是一个相当重要不容忽视的环节，只有做好了软件项目风险分析才能致使软件项目成功地进行，得到用户满意的软件，这也是众多软件公司的最终目的，所以科学的风险分析和必备的防御措施是一个好的软件项目的先决条件。软件项目风险概念

首先，我们知道任何项目都是有一定的不确定性和风险性，然而，软件项目是一个风险 比较大的项目种类，所以总而言之，零风险的项目基本上是不存在，项目中的风险分为多种类型的，只是我们在遇到风险的多少、大小以及严重程度是不同的。

再者，我们分析一下，在软件项目中，我们一般遇到的软件项目风险是怎么样的。在软件项目风险分析中，基本上所有的软件项目管理者都会很大程度上地关注软件项目的进展程度、完成情况以及对成本的控制等等，但是我们必须不可以忽视的问题是我们在项目进行当中遇到的风险，这些风险虽然一时半会可能会隐藏于软件开发中，但是一旦这些问题暴露出来，就会给软件项目带来不可挽回的灾难，任何一个技术人员、管理人员的一个失误或者软件开发中的任何一个负面的因素都有可能成为软件项目成功的威胁，所以我们不能忽视任何的失误，更不能忽视任何一个可能的风险。然后在我们的软件项目中，有可能就是因为一种侥幸的心理往往让我们得不偿失，因为风险本来就是一个不及时出现而又可能本质存在的客观因素，所以我们说它是一种潜在的风险，但是当它真正威胁到我们的时候，也就是我们发现风险存在的时候，这个时候它已经给我们带来了很大的麻烦，并且严重的有可能是不能挽回的损失，所以作为一个软件项目技术人员或者管理人员，我们都应该及时的关注软件的发

展进度，并且的不断的尝试有可能出现的风险的分析。

所以，我们要对软件项目进行规划来查找可能的风险，这样软件项目的期望值才会由低变高，进行了风险分析，这样软件项目的成功率也会大大提高，根据成功软件项目的经验和失败软件项目的教训，我们得知成功的软件项目都必须采取积极的步骤对要发生或者有可能存在的风险进行分析，从而才可能采取有效的措施避免软件项目的失败。软件项目风险定义

风险是潜在的对软件项目的威胁，未来可能发生损失的一种度量，当然也有可能不发生，但是一旦这种危险出现了，就会对软件项目带来很大甚至不可估量的损失，也是对公司的一种负面消极影响。软件项目风险是是未来的一种关注，本来风险就是不确定性的，所以这种潜在的危险就给开发过程中带来了各种决策的选择，另，风险还和人为因素（例如思想、行为）和环境因素（例如时间、地点）有关，等等这些因素都会导致软件项目的风险，所以在对软件项目进行分析的时候这些因素都是不容忽视的。

软件项目风险一旦出现就会影响软件的开发进度、成本，这些都可能导致最后的软件项目的失败，这些都应该是软件项目组所关心的重点。在软件项目的开发过程中，我们都知道现在软件行业的技术是日新月异的，所以必然会用到一些新技术，以及我们的人力方面，这些都是影响项目开发的主要因素，然而正是这些因素的复杂性，也就造就了软件项目风险的复杂性，这些因素本身就是不确定的，当我们面对这些复杂的未知数时，要进行科学的分析得出更加合理的答案，才能使软件项目不断地向成功的方向发展，并且对软件开发做出一个正确的引导，反而言之，项目损失带来的将是项目的无法如期完成或者大量的超出成本预算，这些都将给企业带来直接的损失和消极的影响，所以我们在这里可以定位软件项目风险的重要性。

综合上述的分析，我们可以总结出风险的几个要素，风险首先是一个不确定的风险因素，然后会导致一个风险事件，这样带来的结果就是直接的损失，这样开发出来的软件就和企业以及客户的预期值相差太远，最后就有了风险结果，我们可以用一个图来表示这个风险描述：软件项目风险类型

软件项目风险的类型可以从不同角度进行分类，以下就范围角度和预测角度进行风险类 型的分析：

从范围角度，风险主要分为：商业风险、管理风险、人员风险、技术风险、开发环境风险、客户风险、过程风险和产品规模风险等等。

1）商业风险：是指与管理或市场所加诸的约束相关的风险，主要包括市场风险、策略风险、管理风险和预算风险等；

2）管理风险：是指在项目开发进程中，对潜在的人力和物力以及相关资源的管理风险，这

其中包括对时间、技术人员和项目相关资源的分配不合理，还有对项目计划实施没有做到足够好的预期安排等；

3）人员风险：人员风险主要是指在开发和实施的过程中技术人员自己的相关因素，其中主

要包括技术人员自身的不稳定性和错误判断，还有包括项目参与人员的经验不够丰富以至于做出错误的决定，这些都会影响项目的质量；

4）技术风险：是指在不断更新的软件开发技术中，会有某些不稳定的技术的参与，或者与

正在进行的项目不兼容的现象等等，所以在做技术风险分析的时候，我们先要对技术的稳定性和兼容性进行准确的测试，这样才能给软件项目进行准备的技术定位；

5）开发环境风险：主要是指开发环境以及工具可能会对项目造成的风险；

6）客户风险：在软件项目开发中，我们可以很明确的感觉到用户的需求的确定是一件具有

一定复杂性的工作，这样往往在我们的开发过程中，可能是因为客户的理解的差异造成客户修改需求的风险，这样的风险是最常见的，我们不能随时的变更需求，但是客户又必须要求更改需求的时候，这时候我们的客户风险就大大的出现在软件项目中了，所以为了避免这种风险或者减小这种风险发生的可能性，所以我们在分析客户需求的时候就要尽量想到以后可能会出现的风险；

7）产品风险：产品风险主要是指在产品成型之后，所出现的产品质量与客户或者开发人员

自己所预期的不相符合的情况；

8）过程风险：过程风险是与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险；

从预测角度分析风险类型：

1）已知风险：在软件开发过程中，已经知道的风险是通过评估项目计划、开发项目的商业

及技术环境以及其他的可靠的信息来源而得来的；

2）可预测风险：这种风险类型是通过以往的项目经验来进行预测的风险类型；

3）不可预测风险：不可预测的风险往往是隐藏在项目开发过程中，这种风险是很难在其中

得知的，但是这种风险出现几率就没有那么大了，所以一个强大的企业需要有能够承担这种风险的能力；软件项目风险避免措施

当我们了解了风险的概念、定义以及类型以后，就应该根据风险的一些特性制定出相应 的避免措施。

在软件开发的初级阶段，最重要的工作当然是需求分析，当然这个里面包含了风险分析，做一个好的风险分析就等于为软件项目的成功打下了坚实的基础。首先，我们在需求分析的时候，必须要深刻的了解客户的使用情况，要深入到企业或者试用人员的周围调研用户需求，这样得到的需求才是真正的用户需求，如果我们只是一味的听从客户所描述的需求来定义软件需求的话，那么我们就大错特错了，在一般情况下，用户描述需求都不能全面的或者专业的转达他们理解下的需求，所以软件项目人员必须自己做好需求调研工作，这是一个至关重要的阶段，做好了这个阶段，也就减小了后续开发中的风险。其次，在软件开发的过程中，我们应该合理科学地安排技术人员以及其它与项目相关的资源，安排好这些资源后，才能减小开发中人员风险存在的可能性。还要做好其他相关风险的安排和考查工作，这里就每个风险类型不做一一介绍。最后，软件项目参与人员还应该根据已有的成功项目和失败项目的经验和教训，对此加以总结和比较，得出影响软件项目的相关重要因素，并且对这些可能存在的因素进行分析，尽可能地得出已知的和潜在的风险，根据相应的风险类型，及时的做出最合理的避免措施，以至于有效的防止风险的扩大化和普遍化。结束语

本论文主要介绍了软件项目风险的概念、风险的定义、风险的类型以及避免措施。我们 了解了风险的危害性，风险会对项目的成功造成决定性的威胁，所以当我们知道了风险危害性以后，应该怎么地去避免措施，做好合理科学的检查和预测，才能高效的防御风险发生的可能性，所以，要想做好一个软件项目，软件项目中的风险分析是一个重中之重的环节，不容忽视的，我们要总结已有的软件项目的成功和失败之处，然后运用到自己的项目中来，这样才可以最好的做到软件项目风险分析工作。参考文献：

【1】韩万江 姜立新 软件项目管理案例教程（第二版）机械工业出版社，2009.04.【2】卢有杰 卢家仪 项目管理系列教材 清华大学出版社 2001.08

【3】王卓甫 工程项目风险管理 中国水利水电出版社 2003.02

【4】Elaine M.Hall（王海鹏 周靖译）风险管理 清华大学出版社 2002.09

如何走出软件项目风险的旋涡 篇3

一个软件项目，无论其规模大小，必然会受被实施方（用户）所处行业、自身特点、组织结构等多方面因素的影响而带来变革，这就使软件项目必然具有高风险性的特点。由于风险是在项目开始之初就对其整个过程起各种影响的，所以在项目过程中对风险分析不足，或是风险回避措施不得力，都很有可能造成项目的夭折、中断甚至失败。就项目所涉及到的人、财、技术、时间、计划以及市场等方方面面的因素，可将项目风险归结为以下几种：

人力资源风险

项目中的关系人作为项目的主体在项目中起着主导作用，优秀而富有经验的项目经理、用户/顾客参与项目的热忱度、项目团队的技能与协作精神、高层管理者的支持、角色明确而高效率的项目发起人以及其它利害相关者都会是项目不同程度风险的来源，所以协调处理好项目中各关系人的职权、需求和关系等方方面面的因素，对角色认真评估，保证合适的人选，以足够的精力参与到项目中来，以解决项目中因人力资源而引起的风险，保证项目的实施成功。

时间风险

时间风险主要是指超出进度安排限度的风险。由于很多软件项目的失败正起因于项目进度出现拖延而导致项目团队士气低落，效率低下，所以项目的时间管理需要充分考虑各种潜在的风险。在进度计划时，一味求快、甚至刻意追求某个特殊意义的日期作为项目里程碑，将会对项目进度控制造成很大的压力。在执行过程中，应强调项目按进度执行的重要性，在考虑任何问题时，都要将保持进度作为先决条件；同时，合理利用赶工及快速跟进等方法。

计划风险

项目计划及其变更与项目的实际进程不协调、频繁改变项目计划、计划考虑不周全、项目计划本身有错等都会引起项目中的计划风险。如制定计划阶段，项目管理人员与项目实施人员之间的沟通不善，或者对项目中出现的风险问题预估不够，造成项目计划与实际操作方式产生较大偏移；在项目进行过程中计划的变更和跟进与实际进度不符，或是根本就是计划与实际进度相分离；项目计划中没有考虑到在实施中可能会出现的某些不确定性因素或是对项目的时间、费用等估计不够等都会导致风险的产生，所以计划应该准确地反映完成项目的时间和各阶段的任务。计划必须跟随项目的发展保持最新状态，为了让计划与时俱进，项目计划就必须反映实际完成的工作，同时还要预计将要完成的工作。

技术风险

技术风险主要指由于不能满足项目的技术而导致的风险，由于额外的资源将被使用以满足项目的技术性要求，成本溢出将非常巨大。在项目开始时应对项目所涉及到的技术以及设备进行评估分析，确定此项目在技术上可行，在产品开发出来之前，该技术不会过时，而且硬件、软件、网络功能均适合，并且能够满足项目的目标，达到用户的需求。

财务风险

财务风险主要指项目超预算成本的风险。要降低财务风险就要对项目的有关财务情况多加分析，要了解并搞清楚此项目是否很好的利用公司的资源？项目干系人对此项目的财务预算是否可靠？项目是否满足回报估计？如果不满足公司还愿意继续此项目吗？……等一系列的财务问题。

在一个项目中不只是以上几种风险外，同时还有质量风险、市场风险、项目管理风险和其他项目外部的风险都会以不同程度的影响着项目的成功。作为项目管理者，就必须成功地控制项目的风险，从项目的各个方面着手，研究项目进展各阶段可能出现的各种已知、未知的风险，分清轻重缓急，有侧重的控制好风险，采用有效的防范措施，把风险损失降到最低程度，从而使项目顺利进行，发挥其最大的投资效益。

风险是不以人的意志为转移并超越人们主观意识的客观存在，而且在项目的全寿命周期内，风险是无处不在、无时没有的。虽然人类一直希望认识和控制风险，但只能在有限的空间和时间内改变风险存在和发生的条件，降低其发生的频率，减少损失程度，而不能也不可能完全消除风险，并且风险的产生是无规可循、杂乱无章的，在消除控制已有风险的时候也会产生新的风险或导致风险的变更，所以说风险存在客观性和普遍性，风险的发生具有偶然性和必然性，风险的控制消除过程又具有可变性，同时风险还具有多样性和多层次性的特点。

项目管理中建立风险管理策略和计划，并在项目的生命周期中不断控制风险是非常重要的。通常风险控制可以分为四个阶段：风险识别、风险分析、风险应对和风险监控，这里重点讲一下风险应对和监控。

风险应对计划 在对风险进行了识别及分析之后，就要对风险可能产生的结果或影响进行应对计划，风险应对计划的目的在于通过制定相应的措施，来应对风险对项目可能造成的威胁。常采用规避、转移、缓解、接受的措施来应对风险的威胁。

风险应对计划是针对已识别的风险进行的；对于未知的风险，不可能预先制定相应的应对计划或应急计划，因此，可以利用管理储备来准备应急措施。

风险监控 制定了风险应对计划之后，风险并非不存在，在项目推进过程中还可能会增大或者衰退。因此，在项目执行过程中，需要时刻监督风险的发展与变化情况，并确定随着某些风险的消失而带来的新的风险。风险监控就是要跟踪识别的风险，识别剩余风险和出现的新风险，修改风险管理计划，保证风险计划的实施，并评估消减风险的效果。

风险监控包括两个层面的工作：其一是跟踪已识别风险的发展变化情况。其二是根据风险的变化情况及时调整风险应对计划，并对已发生的风险及其产生的遗留风险和新增风险及时识别、分析，并采取适当的应对措施。

在项目管理过程中，成功而有效的风险管理可以防止和减少项目中潜在问题和负面影响的干扰，它是处理危机的有效处方。

浅析软件项目风险管理 篇4

软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。现阶段在众多软件公司开发软件过程中必不可少的会涉及到软件项目的风险管理, 当公司对软件项目风险管理不当时, 风险就会成为现实, 就有可能影响到项目的进度, 增加项目的成本, 甚至使软件项目不能实现。恰当的对软件项目进行风险管理, 可以最大限度的减少风险的发生。

2 软件项目风险管理涉及以下几个方面:

1) 识别软件项目风险

识别软件项目风险是系统化地确定对软件项目项目计划 (估算、进度、资源分配) 顺利实施产生威胁的因素。通过识别已知和可预测的风险, 项目管理者就有可能避免这些风险, 且当必要时控制这些风险。在项目的整个生命周期内, 风险识别是一个连续的过程。一般情况下软件项目风险划分为以下几个种类: (1) 资源风险; (2) 产品规模风险; (3) 需求风险; (4) 相关性风险; (5) 管理风险; (6) 技术风险。

2) 对软件项目风险进行评估

软件项目风险评估主要采取以下方法: (1) 建立软件项目风险清单。风险清单是关键的风险预测管理工具, 风险清单中应列出在任何时候碰到的风险名称、类别、概率及该风险所产生的影响; (2) 对软件项目风险进行评估。风险评估的具体做法是:根据风险的不确定性和损失两个基本特征, 为每个风险计算风险值。风险值=可能性×影响值, 两者的乘积越大表明该风险越高, 越值得重视; (3) 软件项目风险划分。在进行了风险的量化分析后, 需要对已经确定需要进行管理的风险进行优先级的划分。在风险划分中必须强调的是由于每个项目的资源都是有限的, 所以风险管理必须把精力集中在最重要的风险子集上, 并且在项目进行中条件和优先级发生改变的情况下, 组成此子集的风险种类也要随之改变。

3) 软件项目风险的应对措施

软件项目风险分析活动都是为了建立一个具有良好效果的处理风险的策略。风险管理策略一般包含3个内容: (1) 风险规避; (2) 风险监控; (3) 构建风险管理模型。

风险规避就是通过变更项目计划, 从而消除或形成风险的条件, 或者保护项目目标免受风险的影响。虽然项目队伍永远不可能消除所有的风险, 但某些特定的风险还是可以规避的。在项目早期出现的某些风险事件可以通过澄清需求、获取信息、

加强沟通、听取专家意见的方式加以应对。减少项目范围以规避高风险的工作;增加项目资源或时间;采用一种熟悉的而不是创新的方法;

风险监控是项目管理过程, 它跟踪已识别的风险, 监测残余风险和识别新的风险, 保证风险计划的执行, 并评价这些计划对减轻风险的有效性。风险监控记录与应急计划执行相关联的风险量度, 是项目整个生命周期中的一个持续进行的过程。随着项目的进展, 风险会不断变化, 可能会有新的风险出现, 也可能有预期的风险消失。良好的风险监控过程能为够提供信息, 帮助我们在风险发生前做出有效的决策。

现阶段软件行业主要使用的风险管理模型有以下几种:

(1) Barry Boehm模型

Boehm模型公式:RE=P (UO) *L (UO) 。其中ti E表示风险或者风险所造成的影响, P (UO) 表示令人不满意的结果所发生的概率。L (UO) 表示糟糕的结果会产生的破坏性的程度。Boehm思想的核心是十大风险因素列表, 其中包括人员短缺、不合理的进度安排和预算、不断的需求变动等。针对每个风险因素, 都给出了一系列的风险管理策略。在实际操作时, Boehm以十大风险列表为依据, 总结当前项目具体的风险因素, 评估后进行计划和实施, 在下一次定期召开的会议上再对这十大风险因素的解决情况进行总结, 产生新的十大风险因素表, 依此类推。

(2) CRM模型

SEI CRM模型的风险管理原则是:不断地评估可能造成恶劣后果的因素;决定最迫切需要处理的风险;实现控制风险的策略;评测并确保风险策略实施的有效性。CRM模型要求在项目生命期的所有阶段都关注风险识别和管理。它将风险管理划分为5个步骤:风险识别、分析、计划、跟踪、控制。

(3) RIM模型

SERIM从技术和商业2个角度对软件风险管理进行剖析, 考虑的同题涉及开销、进度、技术性能等。SERIM的理论体系主要基于如下概念:风险元素 (element) 、因素 (factor) 、指标 (metrics) 和活动 (activity) , SERIM的分析模型反应了这几个目标的修正。概念之间的相辅相成关系。Karolak认为软件风险新的目标体现在3个方面, 即技术、成本和进度。其中技术方面与性能、可用性等相关, 应该尽早识别这个方面的风险;成本则包括预算、盈利等;进度包括进度表的灵活度、现实性等。贯穿于整个开发周期。它还提供了一些指标和模型来估量和预测风险。由于这些数据来源于大量的实际经验, 因此具有很强的说服力。

3 结论

软件项目管理从某种意义上讲, 就是风险管理。我们尽量去定义明确不变的需求, 以便进行计划并高效管理, 但商业环境总是快速变化的, 甚至是无序的变化。所以, 软件企业在进行项目管理的过程中, 必须采用适合自己的风险管理方法进行风险管理, 以确保软件项目在规定的预算和期限内完成项目。

参考文献

[1]左美云, 邝孔武.信息系统的开发与管理教程[M].北京:清华大学出版社, 2003.

软件项目策划书_软件项目策划书 篇5

1引言.1 编写目的本开发计划的目的是：

a． 把在开发过程中对各项工作的人员、分工、经费、系统资源条件等问题的安排用文档形式记载下来，以便根据本计划开展和检查本项目工作，保证项目开发成功；

b． 制订项目组开发过程中的评审和审查计划，明确相应的质量管理负责人员；

规定软件配置管理的活动内容和要求，明确配置管理工作的人员。

特别要求：需求分析必须详细，并且有相关专家合作进行，.2 背景

本项目软件名称为《电能质量数据分析软件》。

任务来源于（略）公司；

交办单位：（略）公司；

承办单位：北京长峰新康科技有限责任公司。.3 参考资料

无；.4 术语和缩写词

暂无；

特别说明：有关公司内部秘密的内容用（略）代替。

2任务概要.1 工作内容

本项目开发过程中需要进行的各项主要工作为：

编制附和软件需求要求的软件功能的软件。

文档计划建立：

软件开发计划；

软件目录

软件需求规格说明

项目开发计划

可行性报告

软件标准规范

软件测试计划

软件测试办法

概要设计说明

软件可靠性和安全性设计指南

硬件总体设计报告

详细设计说明

软件详细设计报告

软件代码（略）

测试分析报告

软件可靠性和安全性设计检查单

软件评审检查单

软件使用说明.2 产品.2.1 程序

见需求。.2.2 文档

文档内容见2.1中文档建立。

文档格式要求按照软件模式化要求进行，模式按照如下名称模板要求规定：

项目开发计划；软件开发计划

软件目录；文档目录

软件需求规格说明； 需求分析报告

概要设计说明； 概要设计文档

详细设计说明；详细设计文档

软件标准规范；源代码

软件使用说明；软件使用说明书

测试分析报告；软件测试报告

软件评审检查单。软件审查报告.2.3 服务

培训：

时间：1天；

内容：软件使用及安装；

软件支持：略。.2.4 验收标准和验收计划

验收测试：

时间：1天。

内容：软件使用。

软件确认：

时间：1天；

内容：确定软件的可使用性，软件的功能完整性。

3实施总计划.1 阶段划分

需求分析：2周；

概要设计：6天；

详细设计：1.5周；

编码：3周；

测试：2周；

验收：2天。

项目启动时间：2000-11-14.2 人员组成姓名职责参加时间

廖燕宁负责软件的总体设计时段：全部，开发时段：部分

耿江涛软件设计，开发全部

高小光设计，开发全部

张欣说明书，部分文档 部分

赵健颖需求部分.3 任务的分解和人员分工

软件开发任务按软件种类采取逐层分解的办法把任务落实到实处。

管理、协调人员：廖燕宁，赵健颖；

确定质量保证人员：廖燕宁

配置管理人员：耿江涛

形式化检查人员：赵健颖

使用者：赵健颖。

软件任务：系统需求

负责人：（略）的市场部经理赵健颖

职责：提供需求。

软件任务：需求分析

负责人：廖燕宁

职责：进行需求分析，提供需求分析报告。

软件任务：概要设计

负责人：廖燕宁，耿江涛，高小光

职责：进行概要设计，概要设计框图，相应文档。

软件任务：详细设计

负责人：廖燕宁，耿江涛，高小光

职责：进行详细设计，出详细设计流图及报告。

软件任务：编码

负责人：耿江涛，高小光

职责：编码，调试及报告。

软件任务：测试

负责人：廖燕宁，耿江涛，高小光

职责：路径测试。

软件任务：更新

负责人：廖燕宁，耿江涛，高小光，赵健颖

职责：由赵健颖根据测试后的软件提出问题，变更需要更改的地方。

软件任务：文档编制

负责人：张欣

职责：软件使用说明书，部分其他文档。.4 进度和完成的最后期限

进度包括：

需求分析；

软件概要设计；

软件详细设计；

编码；

测试；的时间。

完成的最后期限（不包括测试及验收）为：2000/12/15日(中间有一周软件培训，延误一周)。3.5 经费预算

略.6 关键问题

（略）。.7 独立确认测试工作计划和安排

测试由长峰新康进行；

测试数据由长峰华辉提供；

时间：编码结束后一周内；

设备：

普通PC 机

Windows 98

（略）电能分析仪。

4支持需求

Windows 98 操作系统；

Delohi 5.0开发工具（软件开发）；

C++（VC或C-Builder 5）开发工具；

Paradex 数据库软件。.1 计算机系统支持

本软件的开发需要工作平台：PC 主机；.2 需要交办单位承担的工作

需要（略）公司提供：

需求，在本周提供；

PF 1文件格式，或读写代码；.3 需要其它单位提供的条件

测试数据项目列表。

5质量保证

质量审核：赵健颖，廖燕宁.1 评审和审查计划

见评审表；.2 标准、条例和约定

代码每日发送到小组共享区，由廖燕宁提取。.3 人员

赵健颖，廖燕宁.4 对任务间接承办单位的管理

略

6软件配置管理.1 基线

开发编码结束后一周内，交齐文档、代码。.2 配置标识规则

软件开发计划：2000-10-1-1；

文档目录：2000-10-1-0；

需求分析报告：2000-10-1-2；

概要设计文档：2000-10-1-3；

详细设计文档：2000-10-1-4；

源代码：2000-10-1-5；

软件使用说明书：2000-10-1-6；

软件测试报告：2000-10-1-7；

软件审查报告：2000-10-1-8。

其他（略）。.3 配置控制.3.1 更改控制

软件设计的更改权限为：廖燕宁；

软件需求的更改权限为：赵健颖；

需求分析的更改权限为：廖燕宁；

编码的更改权限为：耿江涛，高小光；

文档的更改权限为：廖燕宁, 张欣；.3.2 更改规程

北明软件:规避整合风险 篇6

历时两年，“北明软件2011年的合同额已经达到18亿元，2012年的合同额将超过20亿元。”北明软件董事会秘书何长青介绍说。从业务发展的角度来看，北明软件已经克服了整合当中的重重阻碍，取得了1+1+1+1+1+1>6的效果。并且，在6家公司或团队整合之后，北明软件的整合步伐并没有停止，对新的企业的收购还在进行。

灵活的整合方式

整合从来都是一把双刃剑。整合成功会如虎添翼，整合不好甚至会拖垮原有业务。为了规避整合带来的风险，北明软件采取了灵活和循序渐进的整合方式。

在整合过程里，北明软件将原来的北大青鸟、北大明天、杭州源合、武汉网软的组织结构完全打散，进行了业务和人力资源的整合。对另外两家公司上海艾融、珠海震兴则未进行彻底整合，他们还保持着相对的独立性。以往业内同类企业就曾有过收购之后整合过于激进而导致失败的教训，北明软件吸取其他公司的教训，让整合循序渐进地进行。

“将6家公司重组的难度非常大，但是北明解决得非常好，应该说运作得很成功。”何长青不无自豪地说，“原本也想过用同样的方式整合上海艾融和珠海震兴，但是发现不行，过于激进会适得其反，于是就还让这两家公司作为子公司独立运行。4家公司整合得相对容易，原因是这几家公司的业务比较接近，主要是做系统集成，业务集中在电力、金融、政府等行业。上海艾融和珠海震兴的业务相对独立，其产品形态是软件，与系统集成的销售行为、做事方法有很大不同。艾融的管理体系也已经很清晰，这时候把它整合进来，再套上北明的管理体系，就显得不伦不类，还不如让其自身先发展，只不过在市场层面，大家彼此照应。整合的进度不要过于急迫，不应该以控制为第一目的，而应该把业务发展放在第一位。合并了之后，到底采用什么样的管理体制，是彻底融合，还是独立运作，应该以市场、以业务为重，看哪种方式对业务发展更有利。”

在第一步整合了6家公司之后，北明软件后续的收购更加稳健——先联盟、后收购，这种方式看起来更像是试婚。北明软件先并购目标企业很少量的股权，使两家公司在一起磨合一段时间后，双方确定了共同的发展目标，再进行大规模的股权置换。这种“试婚制度”让北明在全国的整合布局每一步都走得很稳。

克服业务整合的难题

以软件和集成为主的企业，业务整合的难点在哪里？何长青介绍说：“我们整合的几家公司都有系统集成业务，但合作的上游厂商不同。比如，北大青鸟与思科合作，杭州源合与H3C合作，思科和H3C是竞争对手。整合之后，北明软件要同时与两家有竞争关系的上游厂商合作，这很容易产生冲突。最后的解决方式是划分地域，一部分地域做思科，一部分地域做H3C，并与上游厂商充分沟通，得到厂商的理解。”

对组织机构整合和业务整合，何长青积累了多年的经验，“业务整合最大的难题是业务线的重合，如果业务线重合，就会有怎么分、以谁为主的问题。如果原来两家公司做的产品、解决方案差不多，就有可能要放弃一个，以另一个为主。或者整合一下，吸收双方的优点，形成新的解决方案。在北明软件整合的过程里，原来几家公司都做电子政务，那就以原来一家的解决方案为主，另外的就放弃了。”

整合不是一味地做加法，在业务整合的过程里，恰到好处的减法也是必不可少的。

规避最大的风险——人才流失

“软件和集成企业的整合，最大的风险在于人。”何长青指出，“因为这个行业的收购买的不是公司，也不是业务，其实买的就是人，也就是人心。如果在人心这个环节上出了问题，就什么都谈不上了。在软件和集成企业的整合过程中，人的因素最为重要。因为，它不同于传统的制造业，有一些人带不走的东西。但在IT服务行业，人可以带走一切。”

为规避骨干员工流失的风险，北明软件建立了为大家认可的股权分配机制，没有绝对控股的大股东，而是将股权分散在管理层，同时，技术骨干和销售骨干也都持有股份。并且，北明软件还建立了持续的激励措施，这使得整合之后骨干员工相对稳定，在一定程度上保证了整合的顺利进行。

此外，为了防止企业并购之后人才流失给企业带来损失，在知识管理方面也要提前做好准备，及早建立档案管理和技术文档管理，避免出现人走了业务和核心技术也被带走的情况，做到“人走了，业务不走”，这也是非常重要的。

“整合就是要达到1+1>2的效果；但如果仅仅是1+1=2，这样的整合不做也罢。”何长青的态度清晰明确，“北明软件的整合和并购都是在全国范围内进行的，比如，过去一家企业的能力只能将产品和服务在华南销售，整合之后就可以扩大销售范围到华北和华东，这样才能做到1+1>2。但是要真正做到1+1>2，必须将整合的风险防范于未然。也恰恰是这样，北明软件的业务才得以在两年时间内快速增长。”

冠军档案

成立时间：1998年

公司定位：是一家面向多行业的全国性综合IT信息技术服务提供商。

员工人数：1000+

注册资本：6625万元

软件项目的风险管理详解 篇7

“我喜欢我的同伴们, 他们是一群很棒的人, 我们谈得来, 技术上的事儿我们总能一起找到办法。”

“但是项目是另外一回事儿, 有时候真的让人很恼火, 我们团队只有3个人, 却干着6个人的活儿!”

“我们只有1台调试机, 几个团队都要用, 每天因为争用调试机打架。”

“忙死了, 还要带一帮新人干活, 他们什么都不会, 光添乱!他们要是早一点儿来我还有时间带他们, 现在?算了, 我还是加班自己来吧。”

“早干嘛去了, 这时候才说要改架构, 我们开发都进行一半了!”

“这活儿真没法儿干, 客户干嘛总是来指手画脚啊, 打乱我们的计划了。”

“我在公司接受了3个月的培训, 现在正式加入这个项目了。项目很大, 任务很重, 据说对公司的前途至关重要, 我很兴奋。前辈们很有经验, 也很忙, 我也想做点儿什么, 但是他们好像不太欢迎我加入, 有点儿沮丧”。

如果你是一名软件开发者 (或任何需要团队合作的工作参与者) , 上面的话是不是感觉很熟悉?每个人都有干劲儿, 大家目标也一致, 但是总是有这样那样的问题使我们无法专注于自己的“本职”工作。

问题, 问题, 那么多的问题!虽然说解决难题能带来成就感, 但是相信我, 当意料之外的问题组团出现的时候, 它们带来的只能是混乱!更糟糕的是, 火气、丧气、疲惫感也一起来凑热闹。对于项目, 尤其是大项目来讲, 这可不是个好现象。

好吧, 让我们静下来, 想一想, 那些问题在成为问题之前, 我们真的一点儿都没预料过么?如果能预料的话, 是否能够提前做些什么来避免, 或者减轻问题的破坏力?退一步讲, 最起码让人喘口气, 问题别一起出现!要达到上述目的, 用一个术语化的说法, 就是进行“风险管理”。

通俗的说, 风险就是“问题发生的可能性”。所谓问题, 就是之前我们提到的各种各样的不希望发生的“闹心事儿”。

风险管理的主要任务是:在问题发生之前, 识别它、评估它、做对策, 降低其发生的可能性和发生时的危害程度;然后, 在对策的实施过程中, 进行定期跟踪、再评估、调整对策, 以确保问题是可控的, 直到安全解决。

风险管理

综上所述, 风险管理主要体现在下面几方面:

●风险识别:找到可能发生问题的地方

●风险评估:是哪类问题、发生的可能性、发生后的影响度以及危险等级

●风险对策:什么时间、做哪些工作、能降低风险发生的可能性还是发生后的影响

●风险跟踪:可能性的变化、影响度的变化、危险等级的变化、风险对策是否需要调整、是否引起新的风险等等

风险管理是软件项目整个生命周期中的常规工作。在项目策划、项目范围变更、项目计划变更、定期项目跟踪时, 都要进行风险管理。

风险识别

在软件开发项目中, 要识别风险, 一个基本方法是“模拟法”——用现有的人员、技术、资源 (设备、能够得到的支持等) , 在项目开始的时点上, 审视现有流程上的每一个步骤, 思考并预测将会遇到什么问题。这项工作将使我们得到一份风险描述的列表。

对风险列表中的风险进行“合并同类项”处理, 尤其是当一个项目涉及到多个团队、较多人, 不同的团队和个人提出与他们相关的风险的时候, 这种“合并同类项”的处理就显得尤为重要。它可以保证资源的统一调配, 最大限度复用, 避免各自为政造成的浪费。

风险评估

对风险进行深入的评价, 主要分析风险的种类、可能性和影响。

●风险的种类

一般来讲, 所有的风险都可以归结到软件项目的几个要素上去。现在, 我们首先来提取这些要素。

什么是项目?通俗的讲就是:在特定的时间内、特定的成本下、完成特定的工作, 成果物要质量达标, 令用户满意。所以说, 项目有下面几个关键的维度:

○进度:在什么时间完成

○成本:花费多少代价

○范围:做什么, 做到什么程度

○质量:成果物的质量属性 (例如千行代码bug数、安全运行天数)

○客户满意度:令客户满意

所谓风险的种类, 在软件项目中, 通常指上述维度的某一个。当然, 从市场及企业经营的级别来看, 会有另外一套关于种类的定义标准, 这里不做深入讨论。

●可能性:这个风险演变成问题的可能性有多少

●影响:这个风险演变成问题的话, 其破坏力有多大

●风险级别:根据风险演变成问题的可能性和影响度, 形成各风险评级。风险级别越高, 越应该得到管理者的重视

下表列举了风险评级的方法:

首先, 量化描述可能性及影响度, 然后把风险放到矩阵中的相应位置上, 最后根据风险所处的区域, 判断是S、A、B、C的哪一个级别。

S级:影响大、发生的可能性大。这样的风险必须进行处理, 一定要制定对策降低风险或者规避风险。

A级:影响度在中等程度以上, 发生的可能性比较大, 或者影响度虽然小, 但是发生可能性很高。这样的风险也应该进行处理, 制定相应的对策来降低或者规避风险。

B级:影响大, 但是发生概率很低。这样的风险不应该消耗太多的管理成本, 不必专门制定对策, 只需做定期跟踪。

C级:影响小且发生概率低。这样的风险可以暂时不纳入管理体系。

需要注意的是, 不同的领域、不同的项目, 对风险的影响度和发生可能性的量化标准是不一样的。对风险的容忍度, 也就是SABC的判定标准也是不一样的。例如:同样是“发生几率为万分之一的‘死机’”这样的风险。在某些日用消费品中, 是完全可以接受的, 可以列为C级风险, 不予关注。但是在航天项目中, 则是绝对不能容忍的, 必须以S级来处理。

所以说, 任何一个项目都需要为自己量身定做风险判断基准。甚至需要在项目外、组织级进行定义。在组织级定义项目风险判断基准的好处是:同一个组织内, 为风险制定统一的量化标准, 则不同项目的风险之间具有可比性, 为管理和决策提供依据。

因为风险评估对后期的决策有很重要的影响, 所以, 为慎重起见, 有些评估会经与相关人员一起进行几轮的讨论, 才能最后确定下来。

风险对策

根据风险评估中得出的风险级别, 优先处理S、A级别的风险, 并为每一个风险制定专门的对策。

在制定风险对策的时候, 我们会发现, 风险是可以“转移”的。不同的风险, 根据对策的不同可能在属性上有所转移, 可能对原有的风险造成影响, 也可能会带来新的风险。

下表是对一个风险的识别、评估和对策:

上述对策会降低原有的风险, 但是同时会增加一个新的风险, 如下所示:

上述对策就是一个典型的用“成本”换“日程”的例子。如果对策获得认可, 就会对开发计划等其他方面造成影响, 所有受到影响的部分, 在分析影响范围的时候, 也要再次回顾已经识别的风险是否会因为这个变化而变化。

在为风险制定对策的时候, 需要掌握一个原则:控制风险水平、分散重大风险。

每一个风险都是一个不确定因素, 是定时炸弹, 尽量不要把太多的炸弹尤其是大炸弹集中在一个阶段解决。分散处理的话, 万一问题爆发, 控制起来也相对容易一些。

多数情况下风险的对策都不是唯一的, 虽然对策本身可能也会带来风险, 但是要尽量均衡的考虑对策本身对项目的影响。尽量让项目总的风险水平处于平稳, 避免过大的波峰。

如图1所示, 文章开头所述的一团糟的情况, 可能就是对风险没有事先的管理和干预, 导致集中爆发或者风险过高, 从而给项目整体带来不良的影响。更糟糕的是, 打一场没有准备的仗, 我们输掉战争的同时也输掉了士气和信心。

如果有事先的管理和干预, 项目的风险将会被控制在一个相对稳定的水平, 管理起来会容易很多, 如图表2所示。即使最后问题还是发生了, 但是最起码之前大家对此有预期, 知道会发生什么, 对团队情绪方面的影响也会小很多。

风险跟踪

我们为项目识别了风险, 评估了风险的级别, 为重要风险制定了对策, 在这些工作之后, 还需要对风险进行跟踪。

一般在项目进行周报、月报的时候, 要同时进行风险的跟踪和报告。

对风险的跟踪主要集中在以下几个方面:

●对策跟踪:对策是否按照计划实施了, 实施过程中是否有新的风险出现 (这里又是一个风险识别的过程)

●可能性:随着时间的推移或对策的实施, 这个风险演变成问题的可能性有什么变化

●影响:随着时间的推移或对策的实施, 这个风险演变成问题的话, 问题的破坏力有多大

●级别:随着可能性和影响的变化, 级别也会随之变化

●风险状态:如果风险级别已经变得很低, 不需要再继续处理的话, 则关闭这个风险, 以后不再跟踪

●调整风险对策:判断是否需要调整对策方案, 如何调整——调整的过程又涉及到新的风险识别活动

在进行风险跟踪的时候, 需要注意的是:并非所有的变化都是我们的对策在起作用, 有时候可能是市场变化, 也可能是客户要求的变化, 或者是其他外部环境的变化, 让原本的可能性及影响度发生变化。

管理好风险, 把项目做出节奏感

风险管理是项目管理的重要组成部分。

作为软件开发的技术人员, 通常我们是相信技术的力量的, 我们享受解决问题所带来的成就感。对于企业或者组织来讲, 团队成员的这种成就感是最“物美价廉”的激励, 它能够让项目成功的同时, 让每个人都很快乐, 让队伍快速成长。

做好风险管理, 能够让所有的团队成员清楚的看到, 我们在什么时候会面临什么样的挑战, 为了以合理的代价达成目的, 我们需要在哪些时候、做些什么。

浅谈软件项目风险管理 篇8

软件项目开发过程中存在着大量不确定事件, 这给项目的成功带来了风险。近几年来软件开发技术、工具都有了很大的进步, 但是软件项目开发超时、超支、甚至不能满足用户需求而根本没有得到实际使用的情况仍然比比皆是。有调查显示:

1) 80~90%的信息技术投资并未达到预定目标;

2) 80%到位迟或超过预算;

3) 40%以部分失败告终或最终放弃;

4) 不足25%完全符合了企业和技术的目标;

5) 只有10-20%满足所有既定工作标准。

因此, 风险管理被认为是软件项目中减少失败的一种重要手段。当不能很确定地预测将来事情的时候, 应该采用风险管理的方法来发现软件开发计划中的缺陷, 并且采取行动来减少潜在问题发生的可能性和影响。风险管理意味着危机还没有发生之前就对它进行处理。这就提高了项目成功的机会和减少了不可避免风险所产生的后果。

2、软件项目风险

2.1 软件项目风险定义

风险英文单词是“Risk”, 它来自古希腊单词“Rhiza”, 风险最原始的概念是靠近峭壁航行危险:可能撞上礁石, 可能碰上暗流, 可能遇上从崖上掉下的石头。Webster字典将“风险”定义为“可能的损失、损伤、缺点、破坏”。SEI接受了这个说法, 并将风险定义为“可能的损失”。为了使风险的描述能够被理解, SEI规定风险的描述必须包括两个部分:1) 可能导致损失的当前状况描述;2) 损失的描述。Charette在他的《软件风险分析与管理》一书中将隶属于某一活动、事件或事物的风险进一步定义为如下三个部分:

1) 活动、事件或事物附带的损失。

2) 损失在现有条件下发生的不确定性。

3) 将影响到产出 (如损失程度等) 的一些行为选择。

虽然对于软件风险的严格定义还存在很多争议, 但在风险包含了如下两个特性这一点上已经达成共识:

不确定性——风险可能发生, 也可能不发生;也就是说, 没有100%发生的风险。

损失——如果风险变成了事实, 就会产生恶性后果或损失。

2.2 软件项目风险的影响纬度

一个软件项目实际状态的测量主要包括四个纬度:功能、质量、进度和成本, 这与软件项目的目标是一致的, 即在规定的时间和成本范围内, 提供高质量的符合客户需要的产品。

功能 (F) 可以使用一组产品特性 (pf) 及其重要程度 (fw) 来定义, 如下:

质量的一种简单化表示是由软件项目所包含的缺陷来定义的。因此, 质量 (Q) 可以使用一组缺陷 (p d) 及其严重程度 (dw) 来定义, 如下:

对于进度, 一般使用期望完成的日期来表示, 如“2008-08-30”;

对于成本, 通常使用人力成本或开发工时来表示。如“$18000”、“5000人时”。

根据风险的定义, 风险是指“可能的损失”, 因此, 风险对软件项目的影响也主要体现在这四个维度上, 这四个维度上的任何偏差或不确定性都是软件项目组要关心和控制的。特别地, 进度纬度上的偏差和不确定性是所有四个纬度中最需要重点关注的。

2.3 软件项目风险的种类

(1) .按风险内容分类

对软件项目的管理部门来说, 在做出与规定费用按规定时间交付规定产品或达到规定性能水平的决断时, 风险是永远存在的。软件项目管理部门因风险而导致工作失败有三种方式:产品达不到规定的性能水平、实际费用过高、交付过迟等。就项目而言, 其面临的风险可分为五个方面:技术、管理能水平、实际费用过高、交付过迟等。就一个项目而言, 其面临的风险可分为五个方面:技术、管理、社会环境、费用和进度。

(2) .按风险性质分类

已知风险, 是通过仔细评估项目计划、开发项目的商业及技术环境以及其它可靠的信息来源之后可以发现的那些风险;可预测风险, 能够从过去项目的经验中推测出来;不可预测风险, 它们可能、也会真的出现, 但很难事先识别出它们来。

3、软件项目风险管理的过程

软件项目风险管理实际上就是贯穿在软件项目开发过程中的一系列管理步骤, 其中包括风险识别、风险分析、风险监控和风险应对。

3.1 风险识别

风险识别就是企图采用系统化的方法, 识别某特定项目已知的和可预测的风险。

风险识别主要方法有:

头脑风暴法

头脑风暴法是团队通过本能地、不加判断地汇集一些想法, 产生新的主意, 从而找出解决某一特定问题的方案。建立一份综合风险清单的时候可能用到这一方法。

Delphi方法

Delphi方法是从一组专家中得到一致的意见, 来预测未来的发展。它是一种以互相独立的输入为基础, 对未来事件进行预测的系统化、交互式程序。Delphi方法重复使用几个回合的提问, 包括来自前几轮的反馈, 从而发挥团组输入的优点, 同时又可以避免面对面商议中可能出现的偏见效应。

访谈

访谈是通过面对面或电话讨论的方式, 收集信息、寻求事实的一种技术, 访谈也可以通过电子邮件和即时信息进行。与那些具有类似项目经历的人们进行面谈, 是识别可能风险的重要工具。

检查表

当检查表用来进行风险识别时, 将项目可能发生的许多潜在风险列于一个表上, 供识别人员进行检查核对, 用来判别某项目是否存在表中所列或类似的风险。检查表中所列的内容都是历史上类似项目曾发生过的风险, 是项目风险管理的结晶, 对软件项目有开阔思路、启发联想、抛砖引玉的作用。此外, 也可以通过使用Standish Group, SEI或其他组织开发的检查表, 来帮助识别项目的风险。

流程图

流程图是一种风险识别的常用工具。借助于流程图可以帮助项目风险识别人员去分析和了解项目风险所处的具体项目环节、项目各个环节之间存在的风险以及项目风险的起因和影响。

3.2 风险分析

风险分析是在风险识别的基础上对项目管理过程中可能出现的任何事件所带来的后果的分析, 以确定该事件发生的概率以及与可能影响项目的潜在的相关后果。风险分析的出发点是揭示所观察到的风险的原因、影响和程度并提出和考察备选方案。

风险分析的方法有:

概率/影响图

概率/影响图 (图1) 是风险定性分析的方法。概率表示风险发生的可能性大小, 而结果表示风险发生后所带来影响的程度, 使用风险暴露值=发生概率*结果影响来评价风险。

专家判断法

专家判断法是依赖专家们的直觉和以往的经验来代替或补充数学分析技术, 专家可以使用或不使用较为复杂的技术, 例如, 无须计算风险暴露值, 直接把风险定为高、中和低三种。

决策树

决策树是一种图形化的风险量化分析方法, 可以帮助在未来结果不确定的情况下, 选择最好的行动路径。

模拟

模拟是指用系统的模型或表示法来分析系统的预期行为或绩效, 也是一种量化分析方法。大多数模拟都以某种形式的蒙特卡罗 (Monte Carlo) 分析为基础。蒙特卡罗分析通过多次模拟一个模型的结果, 从而提供计算结果的统计分布。

蒙特卡罗法

假定函数Y=f (X1, X2, …, Xn) , 其中变量X1, X2, …, Xn概率分布为已知。但在实际问题中, f (X1, X2, …, Xn) 往往是未知的, 或者是一个非常复杂的函数方程式, 一般难以用解析法求解有关Y的概率分布及其数字特征。蒙特卡罗法利用一个随机数发生器, 通过直接或间接的方式抽样取出每一组随机变量 (X1, X2, …, Xn) 的值 (X1t, X2t, …, Xnt) , 然后按Y对于 (X1, X2, …, Xn) 的关系式确定函数Y的值Yt, Yt, =f (X1t, X2t, …, Xnt) , 反复独立抽样 (模拟) 多次, 便可以得到函数Y的一批抽样数据Y1, Y2, …, Yn, 当模拟次数足够多时, 便可以给出与实际情况相近的函数Y的概率分布及其数字特征。

3.3 风险监控

监视风险似乎被视为被动的活动, 但事实并非如此。风险跟踪活动包括衡量风险和观察项目中有用信息的指标, 表明何时应该执行风险行动计划。指标指代一个没有直接说明数量的值。成组的指标可使项目状态清楚可见。先行指标是有预见能力的指标。指标可告诉何时可采取行动避免风险。有效的风险控制离不开在恰当的时候采取行动。

风险跟踪过程目标: (1) 监视风险设想的事件和情况; (2) 跟踪提前示警的风险指标; (3) 为触发机制提供通知; (4) 获得风险应对努力的结果; (5) 定期报告风险度量和度量规格; (6) 使风险状态可见。

3.4 风险应对

针对风险评估的结果, 制定相应的应对措施去响应风险, 就是风险应对, 其目的是创造机会, 回避威胁。风险应对中, 需要对风险的正面效应 (即潜在的机会) 制定增强措施, 对风险的负面效应 (即可能的威胁) 制定应付方法。对于不同的风险, 需要根据其重要性、影响大小以及已经确定的处理优先次序, 采取相应的措施加以控制, 对负面风险的反应可以是尽量避免、努力减小或设法接收。

另外, 在处理风险时需要注意应对的“及时性”和“反复性”, 即在第一时间对各种突发的风险作出判断并采取措施;对已经发生或已经得到控制的风险经常进行回顾, 确保风险能够得到稳定长期的控制。

项目风险应对的措施主要有:

(1) 修正项目目标或范围。尽管有深入的项目调研和详尽的项目规划, 但软件开发项目过程中的需求改变常常难以避免, 因此为保证项目的实施效果, 对项目的目标或范围加以必要修正, 能够有效应对项目偏离需求的风险。

(2) 加强培训。加强项目培训能够提高参与项目的IT人员和业务人员甚至管理人员、决策者对信息化项目的认知, 对规避项目的实施风险有良好的效果。

(3) 准备风险保证金, 适当预留项目计划时间。在项目预算中预留一定数量的风险保证金, 时间计划中预留一定的时间, 能够有效应对由于项目需求改变或者范围增加而造成的时间和成本风险。

(4) 始终贯彻项目管理的标准流程。严格执行项目管理中的时间、成本、质量控制等标准流程, 能够有助于控制项目风险。

(5) 加长模拟阶段的周期。软件项目经常需要开发相应系统与企业业务流程相结合, 因此加长系统模拟业务流程的周期, 使之充分适应企业业务流程, 能够保证项目对企业的适应性, 从而降低项目的风险。

(6) 终止项目。这是一种极端的做法, 往往由于项目目标没有明确所致, 采用这种做法虽然会导致项目的彻底失败, 但也是万不得已, 能够避免企业更大的损失。

4、结束语

软件项目管理从某种意义上讲, 就是风险管理。风险管理在国内软件行业的应用, 远未达到预期应该达到的水平。人们往往看不到风险管理的重要性, 这种错误的认识有时会让我们付出很大的代价。软件企业应该对企业员工进行系统的软件风险管理培训, 提高对软件风险管理的重视。同时, 企业应充分运用已有的各种风险管理理论, 创造性地找出一套适合自己企业的风险管理方法进行软件项目风险管理, 并且将该方法贯穿软件项目开发的整个过程, 减小软件项目失败的可能性, 以确保软件项目在规定的预算和期限内完成项目。

摘要：软件项目开发过程中存在着大量不确定事件, 这给项目的成功带来了风险。软件风险管理是对影响软件项目、过程或产品的风险进行估计和控制的实践过程, 也是为了解决影响软件项目、过程或产品的风险而制定的准则。本文叙述了软件开发项目风险的定义、影响纬度和种类, 重点分析了软件项目风险管理的过程。

关键词：风险,风险管理,风险识别,风险分析,风险监控,风险应对

参考文献

[1][美]Schwalbe, K.著, 邓世忠等译.IT项目管理.机械工业出版社.2004年

[2][英]Hughes, B.著, 周伯生等译.软件项目管理.机械工业出版社.2004年

[3]卢有杰, 卢家仪.项目风险管理.清华大学出版社.1998年

[4][美]Glass, R.L.著, 陈河南等译.软件开发的滑铁卢——重大失控项目的经验与教训.电子工业出版社.2002年

[5]邱箢华主编.现代项目风险管理方法与实践.科学出版社.2003年

论软件系统项目风险管理 篇9

对信息系统项目进行风险管理, 可以降低信息系统项目失败和失误的可能性或概率。在该系统研制过程中, 项目组遇到了强大的风险挑战, 由于进行了有效的风险管理, 我们顺利地完成了任务, 取得了较好的经济效益。

一、风险识别

这是实行风险管理计划的第一步, 目的是查明信息系统项目实施过程中的不确定性因素、各种风险的来源以及风险之间的关系。软件项目常见风险主要有:合同风险、需求变更风险、进度风险、质量风险、系统性能风险、技术风险、团队成员能力和素质风险、人员流动风险等。识别风险的手段包括:从历史或其它相似信息系统实施中寻找线索:对照风险的分类, 找出该信息系统所具有的风险;在信息系统实施计划的基础上进行估计, 对可能阻碍实施进度或超出预算的因素进行分析, 确定风险。可采用的技术工具包括:问询法, 也称专家法 (即定期召开会议, 以讨论的形式发现信息系统的风险) ;项目分解法 (将信息系统实施中的工作不断细化, 分成较小的任务, 便于找出风险) ;此外还有核对表、试验和事故树等方法。风险识别的结果是生成风险清单, 详细记录风险来源、风险发生的可能条件、风险症状等信息。

任何项目都有其特点, 对进度、成本、质量的要求也不同。在经过一段时间调研后, 我组织项目组成员对面临的风险进行了分析, (一) 是项目的时间约束具有强制性。由于要进行景区评级, 软件系统所占分数很大, 超过评级验收时限就意味着项目的失败。 (二) 是项目存在项目范围变更的风险。起因是县委、县政府及景区管委会高层想改变现有票务管模式, 由分票制改为一票制 (通票) , 要求系统按一票制研制, 但实行一票制的运营管理模式还没有建立, 管理模式调整涉及到各方面利益的调整, 对系统而言, 不但存在需要求难把握的问题, 而且存在范围重大变更的可能性。 (三) 技术风险, 售票系统网上支付的问题, 项目组成员没有开发经验。

二、风险分析

在风险识别的基础上, 对风险存在及发生的可能性以及将会给信息系统造成的损失范围与程度进行分析, 做出估计和衡量。经分析后确定各风险的重要性, 对其排序, 从而使信息系统实施人员可以将主要精力集中于为数不多的主要风险上, 使信息系统项目的整体风险得到有效控制。风险分析分为定性分析和定量分析。

此项目我认为最主要的风险还在于项目范围的问题, 对此风险进行详细分析。

(一) 风险性质

风险可以按不同标准进行分类, 按风险后果分为纯粹风险、投机风险;按风险来源分为自然风险、人为风险;按风险是否可管理分为可管理风险、不可估量风险;按风险影响范围分为局部风险、全局风险。此项目范围重大调整属于可管理的纯粹风险, 风险一旦发生, 不可回避, 只能接受。项目风险管理的目标就是利用其可管理性, 尽量消减其影响, 把纯粹风险转化为投机风险。

(二) 发生概率估算

分票制模式门票种类有景区门票、各景点门票、各类船票, 共有十余种, 景区内各景点实行的是承包制, 景点内设施由承包商投资, 其收入主要来源于自己景点门票收入与景区管委会按一定比例分成。游船也是承包制, 船票款由船工所得, 每条船交一定的管理费。实行一票制 (通票) 后, 各景点、游船不单独售票, 各景点、船队怎样结算等来一系列问题都需要重新商讨, 实行一票制实际是管理模式的重大调整, 在承包制模式下涉及到各方利益重新分配, 推行难度很大。有可能还沿用原来的管理模式, 项目范围存在大的变更的可能性, 经和景区工作人员进一步交流探讨, 估算其发生概率超过60%。

(三) 影响范围

细化系统WBS, 对各功能模块进一步分解, 形成更详细的WBS目录, 对每条记录都进行影响评估, 经分析影响的模块主要有票务系统、财务系统、船只调度系统, 约占WBS活动条目的40%。

三、风险应对

风险应对是这样一系列过程, 它通过开发备用的方法, 制定某些措施以提高项目成功的机会, 同时降低失败的威胁。对于负面风险, 应对策略有避免、转移、减轻。正面风险, 应对策略有开拓、分享、强大。对于适用威胁和机会的风险, 应对策略是, 风险接受, 预留突发事件预备资源, 包括进度、成本或资源来处理已知的甚至是潜在的突发的未知风险。通过对风险的分析后, 我制定了具体的风险应对措施。

(一) 风险转移

在处理风险时, 必然会增加项目成本, 为了减少风险对项目经济效益的影响, 通过管理把纯粹风险转化为投机风险。在同景区管委会签订合同时, 约定此种情况一旦发生, 甲方需追加投资, 以保障我们的经济利益。

(二) 减小风险影响范围

风险影响范围越小, 在风险处理时时间、人力成本越低。为了降低风险影响范围, 我决定采用过度设计方法, 即在进行系统设计时, 数据结构设计必须通用 (如, 票据类型设计) , 在功能上尽量使更多模块适应两种管理模式, 减少变更带来的影响, 这种方法在系统分析阶段增加了一定的工作量。

(三) 优化项目网络图

在进行风险分析时, 已标示出受变更影响的模块。在约束条件允许前提下, 把不受影响的工作单元放在项目前期完成。这样一旦风险条件发生在项目开发前期, 也能减少其影响。如在那些不受影响模块开发完成前变更即发生, 开发工作不需要回退, 进度受影响最小。

(四) 加强配置管理

配置管理是通过技术及行政手段对产品及其开发过程和生命周期进行控制、规范的一系列措施和过程。信息系统开发过程的变更以及相应的返工会对产品的质量有很大的影响, 如果不从配置管理方面加以控制, 必将导致严重的后果。配置管理的一个重要内容就是对变更加以控制, 使变更对成本、工期和质量的影响降到最小。在此项目管理过程中, 除按系统功能设立基线外, 针对风险还专门设置了内部里程碑, 把不受变更影响的模块开发完成作为一个重要里程碑 (变更控制里程碑) 。

(五) 其他风险的应对

软件项目常见风险还有技术风险、质量风险等。对于技术风险, 应选用合适、成熟的技术, 在技术应用之前, 针对相关人员开展好技术培训工作。旅游管理项目网上售票支付环节对于项目组来说是一个新技术, 经过评估, 我们采用了第三方支付平台, 而不是自己开发。对于质量风险, 预防风险的办法是经常和用户交流工作成果、采用符合要求的开发流程、认真组织对产出物的检查和评审、计划和组织严格的独立测试等。

四、风险监控

对于项目已识别的风险, 必须监控跟踪, 一是跟踪其发生条件, 一旦风险发生, 马上根据风险计划进行应急反应;二是对于有预防措施的风险预案, 检查其风险管理计划是否执行, 预防措施是否到位、有效。2010年2月, 景区管委会通知我, 项目要做大的调整, 根据新票务管理模式推行情况, 县委、县政府决定还沿用分票制管理模式, 要求管理系统做相应的调整, 根据此情况项目组迅速启动风险应对预案。主要措施有:

(1) 合同管理。和甲方协商, 签订合同补充协议, 主要内容为变更项目范围, 增加项目投资。由于原合同中已有对项目范围变更的约定, 很容易就说服了甲方增加开发资金。

(2) 产品基线控制。风险发生时, 项目进度已超过我们设定的变更控制里程碑, 所有配置项都回退到变更控制里程碑, 以满足系统调整的需要。

(3) 调整项目管理计划。把变更控制里程碑后续工作作为一个完整项目段进行管理, 制定项目管理计划, 对系统进行分析设计, 使项目可以迅速有效向下进行。

(4) 人力资源配置。由于后续系统开发时间只有两个多月, 系统正式上线前, 还要留出10天的系统试运行修改时间, 任务非常紧迫, 项目组增加了2名程序员进行系统开发。

经过以上风险处理, 项目顺利进行并按时完成, 景区管委会对系统比较满意, 系统顺利通过了验收。

五、总结

对于软件项目, 风险管理非常重要, 哪怕只对一两个主要风险进行管理, 对项目的影响都是巨大的。风险识别、有效应对措施做出的越早, 损失越小。在此项目中, 项目组进行了有效的风险管理, 把纯粹风险转化为投机风险, 不但使项目按期完成, 也取得了更大的经济效益。而对于甲方, 按一票制 (通票) 管理体制设计的景区门票在1月上旬就印制完成, 采用分票制模式, 门票需重新印制, 只票务印制费就损失了16万元。

项目后期由于系统研制时间紧, 测试工作做的不细, 在系统运行时出现了一些小问题, 系统正式运行后, 项目组投入了一定人力进行维护修改。如把项目分段, 先完成基本功能完成并验收, 把统计报表监控等不直接影响系统运行的功能延期完成, 这样时间充裕、人员容易调配, 也能更好地保证软件质量。

摘要：2009年9月, 我作为项目经理开始某景区旅游管理系统的研制, 作为一个新的管理信息系统的开发, 在进度、质量、成本等方面面临着很多风险的挑战。本文结合作者实践, 以该项目为例, 讨论了信息系统建设风险管理的风险识别、风险分析、风险应对几方面的问题。

参考文献

软件项目风险管理方法研究 篇10

在软件项目开发过程中,一般都要进行风险分析。目前,对于风险的严格定义还存在很多争议,Robert Charete认为风险关注未来要发生的事情[1],风险涉及改变以及选择本身所包含的不确定性。虽然对于软件风险的定义还存在很多争议,但在风险中包含了两个基本特征,这一点上已达成了共识[2,3,4,5]:

(1)不确定性:风险的事件可能发生也可能不发生;即,没有100%发生的风险(100%发生的风险是加在项目上的约束条件)。

(2)损失:如果风险变成了现实,就会产生恶性后果或损失。

通常情况,软件项目风险管理主要包括风险的识别、评估、应对和控制四项主要活动,首先要识别出项目的风险,评估风险之间的关系及风险发生的可能性、严重性及优先级,根据评估的结果制定风险管理计划,并根据风险管理计划对风险进行跟踪和控制。即风险管理的任务是:识别和量化项目开发活动中可能碰到的各类风险,估计风险的可能性和对项目开发的影响程度,制定控制、削弱、消除风险的措施,并根据所制定的措施在项目实施过程中对风险进行监控。软件项目风险管理活动是估计和监控活动的一部分,是与估计及监控活动紧密联系在一起的。

传统的项目管理方法虽然能够实现对于项目风险的管理,但其并未对软件项目的风险进行特定的研究,或给出特定的方法。现代软件工程认识到了软件项目风险的重要性,并做了很多的研究,但并按概率法进行统计,也并未给一个完整的软件项目风险管理的管理模型和实例。为了克服上述缺点,本文针对中国软件项目所固有的特点,对软件项目风险的全过程管理进行了研究,并给出了一些参考模板和参考指标。

2 软件项目风险的识别

软件项目风险的识别有很多的技术和方法可以使用,如头脑风暴法、DELPHI法、风险检查表法及调查、评审法等,其中汇集了频繁发生的风险的检查表是用于识别风险的最通用的技术,也是最适用和可行的技术。在用风险检查表法进行风险识别时,最重要的一个工作是积累、汇总组织历史项目风险方面的数据和经验,以收集组织最普遍发生的风险,从而生成风险检查表,这个表有助于项目经理识别当前项目的风险。另外,通过历史项目风险“数据”的收集,也有利于以后项目在进行风险识别时,参照类似项目的风险识别及发生情况进行风险的确定。当风险检查表建立起来以后,在以后每个项目结束时,都要将该项目的风险状况纳入到风险检查表中,并根据该项目所累积的经验来对风险检查表进行改进。同时,为供以后类似项目在进行风险管理时类比使用,在项目结项的时候还需将该项目本身的风险情况单独保留下来,具体内容包括:项目的概况,项目最初预计的风险及风险缓解步骤,实际的几个最大风险,有哪些经验、教训?风险所造成的影响情况如何等?但需要注意的是风险一般较少发生,因此关于风险后果方面的历史数据很难获得,确定风险发生所造成的影响后果也较困难。另外,随着项目历史数据的积累,除可不断地对风险列表进行完善外,还可在风险列表中制定一个与之对应的建议的风险缓解步骤,以将风险带来的后果降到最低。

风险检查表建立起来以后,在进行项目策划时,负责进行风险估计的人员就可以参考风险检查表,对照项目实际情况,逐项检查,识别出项目的潜在风险;如果有类似项目的资料,则可以参考这些资料并考虑到本项目的实际情况,来确定本项目的风险。除根据检查表进行检查外,还必须要考虑到项目本身的情况及其他可能的风险来源,识别风险列表中所没有列出的风险,这些风险来源可能包括项目的计划信息、项目风险的种类信息等,通常项目的估计假设也被作为项目风险的来源,并有助于管理风险。

项目风险的分类可根据组织的实际情况来确定,通常可分为项目管理风险和技术风险两大类,管理风险一般包括计划风险、项目团队及相关部门等,表1以管理风险中的计划风险为例,列出了1个可供参考的风险检查单。

3 软件项目风险的评估

软件项目风险识别出来以后,对于风险的评估就显得至关重要,软件项目风险评估的主要目的是评估和量化识别出来的各类风险,估计风险的可能性和严重性,划分风险的优先级,为制定控制、削弱、消除风险的项目风险管理计划及对风险进行监控提供依据和参考。一般来说,对于风险的分析是一项既重要,但又比较难的工作。对于一个刚刚开始进行这项工作的组织来说,必须要本着先易后难,逐步推进的思路先做起来,然后再逐步地完善、细化及改进的过程来进行。随着组织数据及经验的累积,可逐渐改进风险的评估方法,逐步增进定量评估的程度,对于一个刚刚开始进行项目管理和风险管理的组织来说具体可按如下思路和过程来逐步进行和完善其风险评估体系:

(1)完全凭经验,将识别出来的风险的优先级

定为高、中、低,并据此来制定应对计划,风险优先级是指根据风险对项目造成的影响所划分的一个风险等级,一般可定义为风险严重性(指风险对项目造成的危害程度)和风险可能性(指风险可能发生的程度)的一个综合值。优先级低的风险是指不影响组织对内对外承诺的风险,优先级中的风险是指可被项目经理处理的风险,优先级高的风险是指需高级管理者处理的风险。

注:项目承诺指的是项目的交付日期,项目的需求实现及项目的费用及工作量等方面的对内对外承诺。

(2)在第一种方法的基础上,可根据经验

将风险的可能性及严重性只定义为高、中、低即可,然后将风险的可能性和严重性相乘获得风险的优先级,也可只以高、中、低来表示。(见表2)

(3)只定义风险的可能性和严重性,但对其可能性和严重性需赋予一定的定量数值,并据此来采取措施。(见表3)

(4)将风险的可能性和严重性各按定量的标准定义为5个级别,两者相乘可得到风险优先级的25个级别,并据此来采取措施,但在此方法中需对风险的严重性定义正确的衡量标准,如可以工作量的增减,进度延误程度,成本等参数来表示等。

(5)将风险的可能性和严重性各按定量的标准定义为10个级别,两者相乘可得到风险优先级的100个级别,并据此来采取措施。

(6)用完全定量的分析方法,如决策树分析、盈亏平衡分析、模糊树故障树法及模拟法等。

在进行风险评估时,如能根据组织项目风险的历史数据或相类似历史项目的数据来确定风险发生的可能性和严重性,将使风险分析具有更大的意义和可行性,从而产生更大的效益。另外,在进行定量风险评估时,可使用概率论和数理统计的方法来进行,如PERT法等。

下面以第二种和第三种方法的应用为例,来进行使用方法的说明。

3.1 风险评估方法2使用说明

在方法2中,风险的可能性、严重性及管理风险的优先级都只定义为高、中、低,具体使用如表2所示。

项目根据上述确定的风险优先级,来确定相应的风险管理措施,及不同措施所对应的措施负责人,并据此对风险进行管理和监督。

3.2 风险评估方法3使用说明

在方法3中,对风险的处理参照则必须参照一定的标准执行,如表3所示。

一旦风险的处理标准得到确定,则在进行风险策划及监控的时候,必须严格按上述标准执行。但管理层有特权关注那些低于极限值,但是他们因为别的原因而仍然感到很重要的风险,例如一个对组织来说非常重要的客户的满意度等。

4 软件项目风险的应对及监控

广义地说,所有项目管理行为都属于风险控制行动,但是这里的风险控制是明确地、显著地针对可能出现的问题所采取的应对思想和措施[6]。

4.1 风险监控的重要性

因考虑到投入产出比,我们在制定风险应对措施的时候,总是决定对风险系数低的风险不响应。但是我们在风险监控过程中,必须对风险进行动态的监控,随时监控风险的可能性,严重性等指标的变化情况,以及新出现风险的情况,因为在实际做项目过程中,我们发现,真正发生的风险往往并不是我们一直在监控的大风险,而是一些突然发生的,我们以前认为很小的风险。为什么会这样呢?我们通过一个项目的实际案例来了解一下,发生这种情况的原因。

我们设一个大的软件项目有50项小风险存在,其中每项风险发生的概率都为10%,根据我们的监控原则,因为这50项风险的风险系数都很低,因此我们不监控,但这50项风险会不会发生呢?

根据题意,这50项风险一项都不发生的概率

P(x=0)=C5050(1-10%)50=0.005=0.5%

也就是说50项风险中至少有一项以上会发生的概率为99.5%,几乎是肯定的。

P(x=1)=C4950(1-10%)4910%=2.8%

这些风险中会发生两项以上的概率为:

1-0.5%-2.8%=96.7%

也几乎为肯定事件。

又因为n=50比较大,np=50*0.1=5比较小,因此也可用泊松定理来求解

即:${\rm P}\{x=k\}=\left(\begin{array}{l}n\\ k\end{array}\right)p{}^k(1-p){}^{n-k}\approx \frac{\lambda {}^k}{k！}‚\lambda =np$

上面的两个概率都接近于1,这说明虽然每项风险发生的概率都很小,但如果这种小概率风险的数量比较多的话,则几乎肯定会发生的,这也告诉我们绝不能轻视小概率事件,并且对小概率的风险也要适当地予以动态的关注。

4.2 建立风险管理及应对计划

根据风险识别和评估的结果对于风险的管理一般分为四个层次:危机管理(风险已经造成麻烦后才着手处理它们)、风险缓解(事先制定好风险发生后的补救措施,但不制定任何的防范措施)、着力预防(将风险识别和风险防范作为软件项目的一部分加以规划和执行)、消灭根源(识别和消灭可能产生风险的根源)。根据这四个层次的划分,我们应该根据风险评估的结果对风险进行预防,但同时我们也必须认识到不是所有的风险都能够预防的,所以还必须建立一个应付意外事件的计划。

另外,只有当缓解风险的费用低于风险发生所造成的损失,才认为风险缓解是有效的。风险的缓解需要花费工作量和成本,并可能会影响到进度,因此在软件项目策划阶段,应考虑到风险的缓解所需的工作量和成本,及对进度所造成的影响,并据此对计划进行完善。

在建立风险的应对措施时,应根据以前类似项目的风险应对情况“数据”来进行确定。例如:一个重要的风险缓解步骤是培训,而对于软件组织来说,开发一个原型是一种抑制新技术风险的有效手段等。

将以上所有的因素都考虑到,就可以据此形成一个统一的风险管理计划。

4.3 根据风险管理计划对风险进行监控

风险管理计划制定出来以后,在项目开发过程中,我们就必须根据风险管理计划对项目的执行情况进行监控,并动态监控风险的变化情况及缓解措施的执行情况。因为控制风险是有成本的[7],在根据评估结果对风险进行跟踪的时候,只有缓解风险的费用低于风险发生所造成的损失,才认为风险缓解是有效的,因此刚开始的时候可只对较高层的风险进行跟踪。具体可按如下方法进行监控。

项目经理或其指派人员每周五、每月及每个里程碑前查看风险管理计划,根据从项目成员所提交的个人周报、项目总体的状态报告及其他途径获得的信息,并对照风险检查表,对项目风险情况进行分析,看有无新风险出现,原有的风险可能性、严重性及优先级等有无变化,到目前为止就风险所采取的纠正措施及缓解措施是否有效等,根据分析情况对风险管理计划进行更新,并确定下一阶段需采取纠正或缓解措施的风险,做出相应安排。

另外还需要根据项目风险监控的结果,分析当前项目的风险状况,分析会不会因项目的风险变化(包括新增的风险及以前没有考虑到的风险),而对项目承诺造成影响,从而影响承诺的实现,即有无影响需求的风险,有无影响项目工作量及人力资源投入的风险,及有无可能影响项目进度和交付日期的风险。并根据承诺之间的关系,看风险对质量、成本、进度三大承诺的影响,有没有因影响到其中一承诺,从而影响到其他承诺等[8,9]。

5 结语

总之,软件项目风险管理是软件项目管理中一项非常重要的工作,风险管理做好了,项目就肯定不会失败。一般来说,对于风险的管理是一项既重要,但又比较难的工作。对于一个刚刚开始进行这项工作的组织来说,必须要分阶段、分步骤,本着先易后难,先简单后逐渐复杂的过程来进行。刚开始的时候可以在总结组织经验的基础上,进行定性的风险管理,并只对较高层的风险进行跟踪,即只关注风险影响程度高的风险。随着组织经验和数据的积累,可逐步进行定量风险管理。从而实现对风险的全面且富有成效的管理,并确保项目的成功。

本文所研究的风险管理方法体系,是建立在理论和实践双重研究基础上所得出来的一套技术参考模型,因此适用于绝大多数企业的绝大多数软件项目,特别是对于刚开始进行风险管理工作的企业。但各个企业必须根据本企业的特点及风险管理的不同的发展阶段选择不同的方法。

参考文献

[1]Software Engineering Institute.Capability Maturity Model?Integration(CMMISM)[R],Version 1.1,CMU/SEI-2002-TR-002,2001:113-145

[2]HILLSON D.Extending the risk process to manage opportunities[J],International Journal of Project Management 20(2002)235–240

[3]BACCARINI D,ARCHER R.The risk ranking of projects:a thodolo-gy[J].International Journal of Project Management,2001,19:139-145

[4]WARD S,CHAPMAN C.Transforming project risk management intoproject uncertainty management[J].International Journal of ProjectManagement,2003,21:97-105

[5]RAZ T,MICHAEL E.Use and benefits of tools for project risk man-agement[J].International Journal of Project Management,2001,19:9-7

[6]WALLACE L,KEIL M.How Software Project Risk Affects ProjectPerformance:An Investigation of the Dimensions of Risk and an Ex-ploratory Model[J].Decision Sciences,2004,35(2):289-321

[7]JALOTE P.软件项目管理实践[M].施平安,译.北京:清华大学出版社,2003.

[8]王长峰.重大研发(R&D)项目过程管理综合集成与过程风险管理模式研究[D].中国科学院科技政策与管理科学研究所,2004