软件项目风险管理全面视角.docx

《软件项目风险管理全面视角.docx》由会员分享，可在线阅读，更多相关《软件项目风险管理全面视角.docx（23页珍藏版）》请在课桌文档上搜索。

1、软件项目风险管理一、风险管理概述软件风险是指软件开发过程中及软件产品自身也许导致的伤害或损失。风险关注未来的事情，这意味着，风险波及选择及选择自身包括的不确定性，在软件开发过程及软件产品都要面临多种决策0选择。风险是介于确定性和不确定性之间B状态，是处在无知和完整知识之间B状态。另首先，风险将波及思想、观念、行为、地点等原因B变化。当在软件工程领域考虑风险时，我们要关注如下的问题：什么样的风险会导致软件项目的彻底失败？顾客需求、开发技术、目0计算机、以及所有其他与项目有关的原因B变化将会对准时交付和总体成功产生什么影响？对于采用什么措施和工具，需要多少人员参与工作0问题，我们怎样选择和决策？对

2、软件质量要抵达什么程度才是“足够的”？当没有措施消除风险，甚至连试图减少该风险也存在疑问时，这些风险就是真正B风险了。在我们可以标识出软件项目中B真正风险之前，识别出所有对管理者和开发者而言均为明显得风险是很重要的。二、被动和积极的风险方略被动风险方略是针对也许发生的风险来监督项目，直到它们变成真正B问题时，才会拨出资源来处理它们，更普遍的是，软件项目组对风险不闻不问，直到发生了错误才赶紧采用行动，试图迅速地纠正错误。这种管理模式常常被称为“救火模式”。当补救的努力失败后，项目就处在真正的危机之中了。对于风险管理0一种更聪颖0方略是积极式的。积极方略早在技术工作开始之前就已经启动了一一标识出潜

3、在地风险，评估它们出现的概率及产生的影响，对风险按重要性进行排序，然后，软件项目组建立一种计划来管理风险。积极方略风险管理0重要目0是防止风险。不过，由于不是所有的风险都可以防止,因此，项目组必须建立一种应付意外事件B计划，使其在必要时可以以可控的及有效的方式作出反应。三、软件风险1、软件风险包括两个特性：不确定性一刻划风险0事件也许发生也也许不发生，没有100%发生H风险。损失假如风险变成了现实，就会产生恶性后果或损失。2、进行风险分析时，重要的是量化不确定的程度和与每个风险有关的损失的程度。为了实现这点，必须考虑如下几种不同样类型的风险：项目风险：项目风险是指潜在的预算、进度、人力（工作人

4、员和组织）、资源、客户、需求等方面的问题以及它们对软件项目的影响。项目风险威胁项目计划,假如风险变成现实，有也许会迟延项目日勺进度，增长项目B成本。项目风险0原因还包括项目B复杂性、规模、构造B不确定性。技术风险：是指潜在地设计、实现、接口、验证和维护等方面B问题。此外规约的二义性、技术的不确定性、陈旧的J技术、以及“过于先进号、J技术也是风险原因。技术风险威胁要开发0软件0质量及交付时间。假如技术风险变成现实，则开发工作也许变得很困难或者不也许。商业风险：商业风险威胁到要开发软件的生存能力。商业风险常常会危害项目或产品。五个重要的商业风险是：（1）开发一种没有人真正需要B优秀产品或系统（市场

5、风险）；（2）开发的产品不再符合企业的整体商业方略（方略风险）；（3）建造了一种销售部门不懂得怎样去卖的产品；（4）由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）；（5）没有得到预算或人力上的保证（预算风险）。3、风险分为如下方式：（1）已知风险,是通过仔细评估项目计划、开发项目的商业及技术环境、以及其他可靠的信息来源（如：不现实的交付时间，没有需求或软件范围的文档、恶劣0开发环境）之后可以发现的那些风险。（2）可预测风险，可以从过去项目B经验中推测出来（如：人员调整，与客户之间无法沟通，由于需要进行维护而使开发人员精力分散）。（3）不可预测风险，它们也许、也会真的出现，但很难

6、事先识别出它们来。四、识别风险识别风险是试图系统化地确定对项目计划（估算、进度、资源分派）的威胁。通过识别已知和可预测日勺风险，项目管理者就有也许防止这些风险，且当必要时控制这些风险。每一类风险可以分为两种不同样的类型：一般性风险和特定产品的风险。一般性风险对每一种软件项目而言都是一种潜在地威胁。特定产品时风险只有那些对目前项目0技术、人员、及环境非常理解B人才能识别出来。为了识别特定产品B风险，必须检查项目计划及软件范围阐明，从而理解本项目中有什么特殊B特性也许会威胁到项目计划。一般性风险和特定产品0风险都应当被系统化地标识出来。识别风险0一种措施是建立风险条目检查表。该检查表可以用来识别风

7、险，并可以集中来识别下列常见子类型中已知的及可预测B风险：产品规模与要建造或要修改的软件的总体规模有关时风险。商业影响一与管理或市场所加诸0约束有关0风险。.客户特性一与客户0素质以及开发者和客户定期通信0能力有关0风险。 过程定义与软件过程被定义日勺程度以及它们被开发组织所遵守日勺程度有关B风险。 开发环境一与用以建造产品的工具的可用性及质量有关0风险。 建造的技术与待开发软件的复杂性以及系统所包括技术时新奇性”有关0风险。 人员数目及经验与参与工作的J软件工程师的J总体技术水平及项目经验有关的）风险。风险条目检查表可以以不同样的方式来组织。与上述话题有关的问题可以由每一种软件项目来回答。这

8、些问题的答案使得计划者可以估算风险产生的影响。1、产品规模风险项目风险是直接与产品规模成正比的。下面的风险检查表中的条目0识了产品（软件）规模有关时常见风险： 与否以LoC或FP估算产品B规模； 对于估算出0产品规模0信任程度怎样； 与否以程序、文献或事务处理的数目来估算产品规模； 产品规模与此前产品的规模的平均值的偏差比例是多少； 产品创立或使用的数据库大小怎样; 产品0顾客数有多少； 产品0需求变化多少？交付之前有多少？交付之后有多少？ 复用B软件有多少？2、商业影响风险销售部门是受商业驱动的，而商业考虑有时会直接与技术实现发生冲突。下面的风险检查表中的条目的识了与商业影响有关的常见风险：

9、 本产品对企业0收入有何影响； 我司与否得到企业高级管理层0重视； 交付期限B合理性怎样； 将会使用本产品的顾客数及本产品与否与顾客的需要相符合； 本产品必须能与之互操作的其他产品/系统卧J数目； 最终顾客的水平怎样； 政府对本产品开发0约束； 延迟交付所导致B成本消耗是多少； 产品缺陷所导致B成本消耗是多少；对于待开发产品的每一种回答都必须与过去的经验加以比较。假如出现了较大的比例偏差或者假如数字靠近过去很不令人满意0成果，则风险较高。3、客户有关风险客户有不同样0需要。某些人只懂得他们需要什么；而另某些人懂得他们不需要什么。某些客户但愿进行详细B讨论，而另客户则满足于模糊B承诺。客户有不同

10、样的个性。某些人喜欢享有客户的身份，而另某些人则主线不喜欢做为客户。某些人会快乐地接受几乎任何交付的产品，并能充足运用一种不好0产品；而另某些人则会对质量差0产品剧烈抨击。某些人会对质量好B产品体现赞赏；而另某些人则不管怎样都埋怨不休。客户和供应商之间也有多种不同样的通信方式。某些人非常熟悉产品及生产厂商；而另某些人则也许素未谋面，仅仅通过信件来往和与生产厂商沟通。一种“不好时客户也许会对一种软件项目组能否在预算内完毕项目产生很大的影响。对于项目管理者而言，不好的客户是对项目计划0巨大威胁和实际的风险。下面的风险检查表中欧J条目的识了与客户特性有关的常见风险： 你此前与否曾与这个客户合作过；

11、该客户与否很清晰需要什么；他能否化时间把需求写出来； 该客户与否同意花时间召开正式的需求搜集会议，以确定项目范围； 该客户与否乐意建立与开发者之间的迅速通信渠道； 该客户与否乐意参与复审工作； 该客户与否具有改产品领域的技术素养； 该客户与否乐意你0人来做他们B工作； 该客户与否理解软件过程;假如对于这些问题中B任何一种答案与否认0,则需要深入0调研，以评估潜在地风险。4、过程风险假如软件过程定义得不清晰；假如分析、设计、测试以无序的方式进行；假如质量是每个人都认为很重要的概念，但没有人切实采用行动来保证它，那么这个项目就处在风险之中。过程问题： 高级管理层与否有一份已经写好的政策陈说，该陈说

12、中强调了软件开发原则过程的重要性； 开发组织与否已经确定了一份已经成文的、用于本项目开发的软件过程的阐明； 开发人员与否同意按照文档所写0软件过程进行开发工作，并自愿使用它； 该软件过程与否可以用于其他项目； 管理者和开发人员与否接受过一系列的软件工程培训； 与否为每一种软件开发者和管理者提供了印好的软件工程原则； 与否为作为软件过程一部分而定义的所有交付物建立了文档概要及示例；.与否认期对需求规约、设计和编码进行正式B技术复审； 与否认期对测试过程和测试状况进行复审; 与否对每一次正式技术复审0成果建立了文档，其中包括发现0错误及使用B资源； 有什么机制来保证按照软件工程原则来指导工作； 与

13、否使用配置管理来维护系统/软件需求、设计、编码、测试用例之间的一致性； 与否使用一种机制来控制顾客需求的变化及其对软件的影响； 对于每一种承包出去0子协议，与否有一份文档化0工作阐明、一份软件需求规约和一份软件开发计划； 与否有一种可遵照0规程，来跟踪及复审子协议承包商B工作；技术问题 与否使用以便易用B规格阐明技术来辅助客户与开发者之间的通信； 与否使用特定的措施进行软件分析； 与否使用特定的措施进行数据和体系构造的设计； 与否90%以上的代码都是使用高级语言编写时； 与否认义及使用特定0规则进行代码编写； 与否使用特定0措施进行测试用例B设计； 与否使用配置管理软件工具控制和跟踪软件过程中

14、B变化活动； 与否使用工具来发明软件原型； 与否使用软件工具来支持测试过程； 与否使用软件工具来支持文档的生成和管理;与否搜集所有软件项目0质量度量值；与否搜集所有软件项目的生产率度量值；假如对于上述问题的答案多数与否认的，则软件过程是微弱的，且风险很高5、技术风险突破技术的极限极具挑战性和令人兴奋，但这也是有风险的。下面的风险检查表中0条目0识了与建造0技术有关0常见风险： 该技术对于你的企业而言是新的吗； 客户的需求与否需要创立新的算法或输入、输出技术； 待开发的软件与否需要使用新的或未经证明的J硬件接口； 待开发0软件与否需要与开发商提供0未经证明0软件产品接口； 待开发B软件与否需要与

15、功能和性能均未在本领域得到证明B数据库系统接口； 产品的需求与否规定采用特定的顾客界面； 产品的需求中与否规定开发某些程序构件，这些构件与你的企业此前开发的构件完全不同样； 需求中与否规定采用新0分析、设计、测试措施； 需求中与否规定使用非老式0软件开发措施； 需求中与否有过度的对产品的性能约束；客户能确定所规定的功能是可行的吗？假如对于这些问题中B任何一种答案是肯定0,则需要深入0调研，以评估潜在地风险。6、开发环境风险软件工程环境支持项目组、过程及产品，不过，假如环境有缺陷，它就有也许成为重要的风险源。下面的风险检查表中的条码标识了与开发环境有关的风险： 与否有可用0软件项目管理工具； 与

16、否有可用B软件过程管理工具； 与否有可用的分析及设计工具； 分析和设计工具与否合用于待建造产品； 与否有可用的J编译器或代码生成器； 与否有可用的测试工具； 与否有可用0软件配置管理工具； 环境与否运用了数据库或数据仓库； 项目组的组员与否接受过每个所使用工具0培训； 与否有专家可以回答有关工具的问题； 工具的联机协助及文档与否合适；假如对于上述问题时答案多数与否认的，则软件开发环境是微弱的，且风7、与人员数目及经验有关的风险 与否有最优秀的人员可用； 人员在技术上与否配套； 与否有足够的人员可用； 开发人员与否可以自始至终地参与整个项目0工作； 项目中与否有某些人员只能部分时间工作； 开发人

17、员对自己0工作与否有对BB期望； 开发人员与否接受过必要的培训； 开发人员的流动与否仍能保证工作的持续性；假如对于这些问题中的任何一种答案与否认的，则需要深入的调研，以评估潜在地风险。8、风险原因和驱动因子为了很好地识别和消除软件风险，项目管理者需要标识影响软件风险原因的风险驱动因子，这些原因包括性能、成本、支持和进度。风险原因是以如下的方式定义0: 性能风险产品可以满足需求且符合于其使用目的的不确定的程度。 成本风险项目预算可以被维持的不确定的程度。 支持风险软件易于纠错、适应及增强的不确定0程度。进度风险项目进度可以被维持且产品能准时交付0不确定的程度。每一种风险驱动因子对风险原因的影响均

18、可分为四个影响类别可忽视的、轻微的、严重的、劫难性的。下表指出了由于错误而产生的潜在影响或没有抵达预期的成果所产生的潜在影响。影响类别时选择是以最符合表中描述的特性为基础的。影响评估类别原因性能支持成本进度劫难的1无法满足需求而导致任务失败错误将导致进度延迟和成本增长2严重退化使得主线无法抵达规定的J技术性能无法作出响应或无法支持B软件严重的J资金短缺，很也许超过预算无法在交付日期内完毕严重的1无法满足需求而导致系统性能下降，使得任务能否成功受到置疑错误将导致操作日勺延迟，并使成本增长2技术性能有所下降在软件修改中有少许的延迟资金局限性，也许会超支交付日期也许延迟轻微的1无法满足规定而导致次要

19、任务的退化成本、影响和即可恢复的进度上日勺小问题2技术性能有较小/、J减少很好的软件支持有充足的资金来源实际的J、可完毕的J进度计划可忽视的1无法满足规定而导致使用不以便或不易操作错误对进度及成本的影响很小2技术性能不会易于进行软件支持也许低于预算交付日期将会减少提前注：1、未测试出的!软件错误或缺陷所产生0潜在影响。2、假如没有抵达预期的成果所产生的潜在影响。五、风险预测风险预测，又称风险估算，试图从两个方面评估每一种风险风险发生欧J也许性或概率，以及风险发生了，所产生0后果。项目计划者、其他管理人员和技术人员一起执行四个风险预测活动：（1）建立一种尺度，以反应风险发生时也许性；（2）描述风

20、险的后果；（3）估算风险对项目及产品的影响；（4）标注风险预测0整体精确度，以免产生误解。1、建立风险表风险表给项目管理者提供了一种简朴0风险预测技术。（样本如下表）项目组一开始要在表中的第一列列出所有风险也许，这些可以运用前面所述的风险检查条目来完毕。在第二列队风险进行分类,风险发生概率放在第三列。每个风险的概率值可以由项目组组员个别估算，然后将这些值平均，得到一种有代表性0概率值。分类前的风险表样本风险类别概率影响RMMM规模估算也许非常低PS6O%2顾客数量大大超过计划PS3O%3复用程度低于计划PS70%2最终顾客抵制该计划BU4O%3交付期限将被紧缩BU5O%2资金将回流失CU4O%

21、1顾客将变化需求PS8O%2技术达不到预期的效果TE3O%1缺乏对工具的培训DE8O%3人员缺乏经验ST3O%2人员流动频繁ST6O%2注：影响类别取值：1一劫难的2严重B3一轻微的4一可忽视的一旦完毕风险表的前四列内容，就要根据概率及影响来进行排序。高概率、高影响的风险放在表的上方。这就完毕了第一次风险排序。项目管理者研究己经排序时表，并定义一条终止线。该终止线（表中某一点上的一条水平线）体现：只有在那些线上的风险才会得到深入的关注，线之下的风险则需要再评估以完毕第二次排序。风险影响及概率从管理0角度来考虑，是起着不同样作用0（见下图）。一种具有高影响但发生概率很低B风险原因不应当花费太多的

22、管理时间。而高影响且发生概率为中到高B风险以及低影响但高概率B风险，应当首先考虑。2、评估风险影响假如风险真的发生了，所产生的后果有三个原因也许会受影响：风险的性质、范围、时间。风险的性质是指当风险发生时也许产生的问题。例如，一种定义得很差时与客户硬件的接口（技术风险）会阻碍初期的设计和测试，也有也许导致项目后期阶段的系统集成问题。风险的范围结合了严重性及其整体分布状况。风险日勺时间重要考虑何时可以感到风险，风险会持续多长时间。在大多数状况下，项目管理者但愿“坏消息”越早出现越好。如下09环节用来确定风险的整体影响： 确定每个风险元素发生的平均概率。 使用前面B表格，基于其中列出B原则来确定每

23、个原因B影响。 完毕风险表，分析其成果。 风险预测和分析技术可以在软件项目进展过程中跌代使用。项目组定期复查风险表，再评估每一种风险，以确定新的状况与否引起其概率及影响的变化。3、风险评估我们建立如下形式0一系列三元组：依冈其中r体现风险，I体现风险发生的概率，X体现风险产生的影响。在风险评估过程中，我们深入审查在风险预测阶段所做的估算的精确度，试图为所发现的风险排出优先次序，并开始考虑怎样控制或防止也许发生的风险。要使评估发生作用，必须定义一种风险参照水平值。对于大多数软件项目而言，前面讨论的风险原因性能、成本、支持、进度，也代表了风险参照水平值。即，对于性能下降、成本超支、支持困难、或进度

24、延迟，均有一种水平值0规定，超过它就会导致项目被迫停止。假如风险0组合所产生0问题引起一种或多种参照水平值被超过，则工作将会停止。在软件风险分析中，风险参照水平值存在一种点，称为参照点或临界点，在这个点上，决定继续进行该项目或终止它（问题太多）都是可以接受的。下图以图形方式体现了这种状况。假如风险的组合产生问题导致成本超支及进度延迟，则会有一种水平值,即图中日勺曲线，当超过它时会引起项目终止。成本超支实际上，参照水平很少能体现成光滑曲线。在大多数状况下，它是一种区域，其中存在诸多不确定性。因此，在风险评估中，我们执行如下环节： 定义项目的风险参照水平值；.建立每一组依冈与每一种参照水平值之间的

25、关系； 预测一组临界点以定义项目终止区域，该区域由一条曲线或不确定区域界定。 预测什么样的风险组合会影响参照水平值。六、风险缓和、监控和管理深入的所有风险分析活动都只有一种目W辅助项目组建立处理风险的方略。一种有效0方略必须考虑三个问题： 风险防止 风险监控 风险管理及意外事件计划假如软件项目组对于风险采用积极的措施，则防止永远是最佳0方略。这可以通过建立一种风险缓和计划来抵达。例如，频繁日勺人员流动被标注为一种项目风险，基于以往的历史和管理经验，人员流动B概率为70%,而影响被预测卫对于项目成本及进度有严重的影响。为了缓和这个风险，项目管理者必须建立一种方略来减少人员流动。也许采用的方略如下

26、： 与既有人员一起探讨一下人员流动B原因（如恶劣0工作条件，低酬劳，竞争剧烈） 在项目开始之前，采用行动以缓和那些在管理控制之下的原因。 一旦项目启动，假设会发生人员流动并采用某些技术措施以保证当人员离开时的工作持续性。 对项目进行良好组织，使得每一种开发活动的信息能被广泛传播和交流。 定义文档B原则，并建立对应的机制，以保证文档能被及时建立。 对所有工作进行详细复审，使得不止一种人熟悉该项工作。 对于每一种关键区J技术人员都指定一种后备人员。伴随项目B进展，风险监控活动开始进行。项目管理者监控某些原因，这些原因可以提供风险与否正在变高或变低B指示。在上例中，应当监控下列原因： 项目组组员对项

27、目压力的一般态度。 项目组的凝聚力。 项目组组员彼此之间0关系。 与酬劳和利益有关0潜在问题 在企业内及企业外工作0也许性。除了监控上述原因之外，项目管理者还应当监控风险缓和环节的效力。例如：上例中，风险缓和环节规定定义“文档B原则，并建立对应H机制，以保证文档能被及时建立”。假如有关键的人物离开了项目组，这是保证工作持续性的机制。项目管理者应当仔细地监控这些文档，以保证文档内容对的，当新员工加入该项目时，能为他们提供必要的信息。风险管理及意外事件计划假设缓和工作己经失败，风险变成了现实。继续前面B例子，假定项目正在进行中，有某些人宣布将要离开。假如按照缓和方略行事，则有后备人员可用，由于信息

28、已经文档化，有关知识已经在项目组中广泛进行了交流。此外，项目管理者还可以临时重新将资源调整到那些需要人的地方去，并调整项目进度，从而使新加入的J组员可以“赶上进度:同步，规定那些要离开的人员停止工作，进入“知识交接模式，RMMM环节将导致额外B项目开销。因此，风险管理0部分任务是评估何时由RMMM环节所产生日勺效益低于实现它们所花费日勺成本。本质上是讲，项目计划者执行一种经典的成本一效益分析来估算项目开销变化状况。对于一种大型项目，也许会标识出3040种风险。假如为每种风险定义三至七个风险管理环节，则风险管理自身就也许变成一种“项目”。经验表明：整个软件风险B80%（即也许导致项目失败日勺80

29、%潜在B原因）可以由仅仅2O%0已知风险来阐明。初期风险分析环节中所实现的工作可以协助计划者确定哪些风险在所说的20%中。1、安全性风险和危险风险不仅限于软件项目自身。在软件已经可以交付客户之后，仍有也许发生风险。这些风险一般与领域中的J软件失败有关。虽然一种良好的系统发生错误的概率很小，不过基于计算机的控制及监督系统中未被发现B错误也许会导致巨大的经济损失，或者愈加严重当软件被用作控制系统0一部分时，复杂性会以数量级增长。由于人的错误所引起0微小0设计缺陷，在使用软件时会变得难以发现。软件安全和危险分析是属于软件质量保证活动，它重要是用来标识和评估也许对软件产生负面影响并使整个系统失败的潜在

30、危险。假如可以在软件工程时初期阶段标出危险，则可以指定软件设计特性来消除或控制潜在地危险。2、RMMM计划风险管理方略可以包括在软件项目计划中，或者风险管理环节也可以组织成一种独立的风险缓和、监控和管理计划（RMMM计划）。RMMM计划将所有风险分析文档化，并由项目管理者作为整个项目计划中0一部分来使用。RMMM计划0大纲如下：I.引言文档的范围和目的重要风险综述责任a.管理者b.技术人员Il.项目风险表终止线之上所有风险的描述影响概率及影响0原因III .风险缓和、监控和管理缓和一般方略缓和风险的特定环节监控被监控0原因监控措施管理意外事件计划特殊的考虑IV .RMMM计划B迭代时间安排表V总结七、软件风险的总结当对软件项目期望值很高时，一般都会进行风险分析。不过，虽然进行这项工作，大多数软件管理者都是非正式地和表面地完毕它。化在标识、分析、管理风险上的时间可以从多种方面得到回报：愈加平稳的项目进展过程；较高时跟踪和控制项目的能力；由于周密计划而产生的信心。