软件项目风险管理计划(共22页).doc

《软件项目风险管理计划(共22页).doc》由会员分享，可在线阅读，更多相关《软件项目风险管理计划(共22页).doc（22页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精选优质文档-倾情为你奉上韩万江 姜立新，软件项目管理案例教程，机械工业出版社 ，2005-02 【丛书名】 国家示范性软件学院系列教材 10 软件项目风险管埋计划任何项目都有一定的不确定性，如果没有很好的风险管理，项目就可能遇到麻烦。所以，在软件项目管理过程中，风险计划也是一个重要的计划，只有进行合理的风险管理，制定及时的风险计划，才能防崽于未然，做到主动控制风险，而不是被动地被风险所控制。本章我们进人路线图的第9站：风险计划，如图101所示。图10-1路线图第9站：风险计划10.1 软件项目风险管理概述在软件项目的开发过程中，必然要使用一些新技术、新产品，同时由于软件系统本身的结枸和技术复

2、杂性的原因，需要投人大量人力、物力和财力，这就造成开发过程中存在某些“未知量”或“不确定因素”，这必然给项目的开发带来一定程度的风险，也可能会使项目计划失败或不能完全达到预期目标。因此，对项目风险进行科学、准确的判别，为项目决策层和管理人员提供科学的评估方法，是十分必要的。项目中的风险有很多种，没有风险的项目几乎是不存在的，只是风险的多少、严重程度不同而已。10.1.1 风险概念风险是损失发生的不确定性，是对潜在的、未来可能发生损害的一种度量。如果风险确实发生了，则它的发生会对项目产生有害的或者负面的影响。例如，在软件测试期间经常会发现故障，因此一个合理的项目必须做好发现故障时对它们进行修复的

3、计划。同样，项目开发过程中几乎总悬会出现某些变更申请，因此项目管理必须相应地准备好变更计划，以处理这些事件。另一方面，风险是一种概率事件它可能发生也可能不发生。因此，我们通常会表现出很乐观，不是看不到风险就是希望它们不会发生。如果风险真出现了，这种态度会使项目陷入困境，这是一个大型项目中很可能发生的事情。因此，风险管理被认为是管理大型软件项目的最佳实践。风险管理旨在识别出风险，然后采取措施使它们对项目的影响最小。风险管理是软件管理中相对较新的领域，它首次出现于贝姆（Bochm）关子风险管理的指商中。自那以后，软件的风险管理逐渐被人们所认识。软件风险是指软件开发过程中及软件产品本身可能造成的伤害

4、或损失。一个项目的损失可能有不同的后果形式，例如软件质量的下降、成本费用的超出、项目进度的推迟等。风险关注未来的事情，这意味着，风险涉及选择本身包含的不确定性，软件开发过程及软件产品都要面临各种决策的选择。风险发生的过程如图10度量2所示，首先有风险因素的存在，风险因素导致风险事件的发生，从而造成损失，而损失又引起了实际与计划之间的差异，从而得到风险的结果。风险事件是指那些人们不愿意它发生的或者没有规划的事件。这些风险事件可能导致无法实现项目目标。风险因素是指能够引起风险事件发生或者增加风险事件发生机会或影响损失严重程度的因素，是造成损失的内在或者处在的原因。需求的变化，设计镨误、疏漏和理解镨

5、误，狭隘定义或理解镨误，不充分估计，不胜任的拈犬人呙等等、都旱风除冈葚。图l0弓2风险发生过程一般说，项目风险应具有三要素：首先风险是一个事件，其次风险应具有事件发生的概率，最后风险事件可能造成一定的影响。如图103所示，风险发生的概率越高，造成的影响越大，就越是高风险，否则就是中等风险或者低风险。风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。当没有办法消除风险甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了。在我们能够标识出软件项目中的真正风险之前，识别出所有对管理耆和开发者而言均为明显的风险是很重要的。图10亏3风险图示10.1.2 风险类型从范围角度上看

6、，风险主要分为下述三种类型：项目风险、技术风险和商业风险。1）项目风险项目风险是指潜在的预算、进度、个人（包括人员和组织）、资源、用户和需求方面的问题，例如时词和资源分配的不合理、项目计划质量的不足、项目管理原理使用不良所导致的风险、资金不足、缺乏必要的项目优先级等。项目的复杂性、规模的不确定性和结构的不确定性也是构成项目风险的因奏。2）技术风险技术风险是指潜在的设计、实现、接口、检验和维护方面的问题。规格说明的多义性、技术上的不确定性、技术陈旧也是技术风险因素。复杂的技术、项目执行过程中使用技术或者行业标准发生变化所导致的风险也是技术风险。3）商业风险商业风险主要包括：市场风险、策略风险、管

7、理风险和预算风险等。例如：如果开发的软件不是市场真正所想要的，就发生了市场风险。如果开发的软件不再符合公司的软件产品策略，就发生了策略风险。由于重点转移或者人员变动而失去上级管理部门的支持，就发生了管理风险。如果没有得到预算或者人员的保证，就发生了预算风险。从预测角度看，风险可以分为下面三种类型：已知风险、可预测风险、不可预测风险。1）已知风险已知风险是通过仔细评佑项目计划、开发项目的商业和技术环境以及其他可靠的信息来源之后可以发现的那些风险（如：不现实的交付时间，没有需求或软件范围的文档，恶劣的开发环境）。2）可预测风险可预测风险是指能够从过去项目的经验中推测出来的风险（如：人员调整，与客户

8、之间无法沟通，由于需要进行维护而使开发人员精力分散等）。3）不可预测风险不可预测风险是可能、也会真的出现、但很难事先识别出来的风险。项目管理者只能对已知风险和可预测风险进行规划，不可预测的风险只能靠企业的能力来承担了。10.1.3 风险的基本性质风险具有如下的基本性质：1）客观性风险客观性首先表现在它的存在是不以人的意志为转移的，因为决定风险的各种因素对风险主体是独立存在的，不管风险主体是否意识到风险的存在，在一定的条件下风险就可能变为现实。其次，风险客观性还表现在风险元时不有，无所不在，它潜在各种活动之中。2）不确定性风险发生的不确定性表现为风险的程度有多大以及风险何时何地有可能变为现实，这

9、些都是不肯定的。由于人们对客观世界的认识受到各种条件的限制，不可能准确地预测风险的发生，不确定性要求我们运用各种方法进行测度。3）不利性风险一旦产生时，就会使风险主体产生挫折、失败甚至损失，对风险主体不利。因此我们应该在承认风险、认识风险的基础上，做好决策，尽可能避免风险，将风险的不利性降到最低。4）可变性 度量风险的可变性表现在一定条件下可以转化，风险事件可以转化为非风险的事件，非风险的事件可以转化为风险事件。5）相对性风险的相对性是针对风险的主体而言的，在相同的风险情况下，不同的风险主体对风险的承受能力不同，不同的组织和个人往往对风险有着不同的容忍限度。例如，一个高利润高收益的公司也许愿意

10、为一个10亿美元的合同花费50万美元制作一份计划书，而亠个收支相抵的公司则不会。一个组织也许认为15的误差几率是高风险的，而其他组织却认为这个几率风险很低。6）风险和利益的对称性风险和利益是同时存在的，风险是利益的代价，利益是风险的报酬。没有利益只有风险，没人会做；实现利益必须承担一定的风险。10.1.4 风险管理概述风险管理是指在项目进行过程中不断对风险进行识别、评估，制定策略，监控风险的过程。通过风险识别、风险分析和风险评价去认识项目的风险，并以此为基础合理地使用各种风险应对措施、管理方法、技术和手段对项目的风险进行有效的控制，妥善处理风险事件造成的不利后果，以最小的成本保证项目总体目标的

11、实现。风险管理是一系列对未来的预测，伴随着一系列的活动和处理过程以便控制风险，减少其对项目的影响。风险管理是项目管理的一个重要组成部分，贯穿于项目生存期的始终。1）从项目进度、质量和成本目标看，项目管理与风险管理的目标是一致的。通过风险管理来降低项目进度、质量、成本方面的风险，实现项目目标。2）从计划的职能看，项目计划考虑的是未来，而未来存在不确定因蓁，风险管理的职能之一是减少项目整个过程中的不确定性，有利子计划的准确性。3）从项目实施过程看，不少风险是在项目实施过程中由潜在变成现实的，风险管理就是在风险分析的基础上拟定具体措施来消除、缓和及转移风险，并避兔产生新的风险。10.1.5 风险管理

12、的意义目前，风险管理被认为是软件项目中减少失败的一种重要手段。当不能很确定地预测将来事情的时候，可以采用结构化风险管理来发现计划中的缺陷，并且采取行动来减少潜在问题发生的可能性和影响。风险管理意味着危机还没有发生之前就对它进行处理，这就提高了项目成功的机会并减少了不可避免风险所产生的后果。只有进行很好的风险管理才能有效地控制项目的成本、进度、产品需求，同时可以阻止意外的发生。这样，项目经理可以将精力更多地放到项目的及时提交上，不用像救火队员一样，处于被动状态。同时，风险管理可以防止问题的出现，即使出现问题，也可以降低其危害程度。可以说你不跟踪风险，风险就跟踪你。正如Tom Gilb所说，“女口

13、果你不主动攻击风险，风险就会主动攻击你”。风险管理可以分为四个层次：危机管理：是在风险已经造成麻烦后才着手处理它们。风险缓解：事先制定好风险发生后的补救措施，但不制定任何的防范措施。着力预防：将风险识别与风险防范作为软件项目的一部分加以规划和执行。消灭根源：识别和消灭可能产生风险的根源。作为一个优秀的风险管理者，应该采取主动的风险管理策略，即着力预防和消灭根源的管理策略，而不应该采取被动的方式，被动风险策略是直到风险变成真正的问题时才会拨出资源来处理它们。更普遍的是，软件项目组对风险不闻不阆，直到发生了错误才赶紧采取行动，试图迅速地纠正镨误，这种管理模式常常被称为“救火模式”。当补救的努力失败

14、后，项目就会处在真正的危机之中。风险管理的一个聪明的策略是主动策略。主动策略早在技术工作开始之前就已经启动了：标识出潜在的风险，评估它们出现的概率及产生的影响，对风险按重要性进行排序，然后软件项目组建立一个计划来管理风险。主动风险管理策略的目标是预防风险。但是，因为不是所有的风险都能够预防，所以项目组必须建立一个应付意外事件的计划，使其在必要时能够以可控的及有效的方式做出反应。软件风险管理要求在风险成为影响项目成功的因素之前识别、着手处理卉消除风险的源头，所有的项目都有风险，如果忽视风险，就可能增加项目失败的可能性，或者导致项目不成功。虽然如此，但风险的大小是可以评价度量的，确定可接受风险和不

15、可接受风险，对不可接受风险做进一步分析，制定补偿措施，将风险减至最小或可以接受的水平。软件风险管理过程主要包括风险识别、风险评估、风险规划、风险控制四个步骤。了解和掌握项目风险的来源、性质和发生规律，强化风险意识，进行有效的风险管理，这些对项目的成功具有很重要的意义。10.2 风险识别风险识别是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁，识别已知和可预测的风险，只有识别出这些风险，项目管理者才有可能避免这些风险，且在必要时控制这些风险。每一类风险可以分为两种不同的情况：一般性风险和特定性风险。一般性风险对每一个软件项目而言都是一个潜在的威胁。特定性风险只有那些对当前项目的技术、人

16、员及环境非常了解的人才能识别出来。为了识别特定性风险，必须检查项目计划及软件范围说明，从而了解本项目中有什么特性可能会威胁到项目计划。一般性风险和特定性风险都应该被系统化地标识出来。风险识别要识别内在风险及外在风险。内在风险是指项目工作组能加以控制和影响的风险，如人事任免和成本估计等。外在风险是指超出项目工作组控制能力和影响力之外的风险，如市场转向或政府行为等。严格来说，风险仅仅指道受创伤和损失的可能性，但对项目而言，风险识别还窑涉机会选择（积极成本）和不利因素威胁（消极结果）。项目风险识别应凭借对“因”和“果”（将会发生什么和导致什么）的认定来实现，或通过对“果”和“因”（什么样的结果需要予

17、以避免或促使其发生以及怎样发生）的认定来完成。风险识别不是一次性行为，而应有规律地贯穿整个项目中。10.2.1 概念风险识别过程见图10-4，其中，风险识别的输入可能是项目的WBS、SOW、项目相关信息、项目计划假设、历史项目数据，其他项目经验文件、评审报告、公司目标等。风险识别常用方法是建立风险条目检查表”，利用用一组提问来帮助项目风险管理者了解在项目和技术方面有哪些风险。此外，还有德尔菲方法、头脑风暴法、情景分析法、面谈法等。风险识别的输出是风险列表。图10度量4风险识别过程10.2.2 德尔菲方法德尔菲方法又称专家调查法，它起源于20世纪40年代耒期，最初由美国兰德公司首先使用，很快就在

18、世界上盛行起来，目前此法的应用已遍及经济、社会、工程技术等各领域。我们在进行成本估算的时候也用到这种方法。用德尔菲方法进行项目风险识别的过程，是由项目风险小组选定与该项目有关的领域专家，并与这些适当数量的专家建立直接的函询联系，通过函询收集专家意见，然后加以缤合整理，再匿名反馈给各位专家，再次征询意见。这样反复经过四至五轮，逐步使专家的意见趋向一致，作为最后预测和识别的根据。10.2.3 头脑风暴法所谓头脑风暴法，就是以专家的创造性思维来获取未来信，a的一种直观预测和识别方法。此法是由美国人奥斯本于1939年首创，它从20世纪50年代起就得到了广泛应用。头脑风暴法一般是在一个专家小组内进行，通

19、过专家会议，激发专家的创造性思维来获取耒来信息。这就要求主持专家会议的人在会议开始时的发言应能激起专家们的思维“灵感”，促使专家们感到急需回答会议提出的问题，通过专家之间的信息交流和相互启发，从而诱发专家们产生“思维共振”，以达到互相补充并产生“组合效应”，获取更多的未来信，a，使预测和识别的结果更准确。10.2.4 情景分析法情景分析法是根据项目发展趋势的多样性，通过对系统内外相关问题的系统分析，设计出多种可能的未来前景，然后用类似于撰写电影剧本的手法，对系统发展态势做出白始至终的情景和画面的描述。当一个项目持续的时间较长时，往往要考虑各种技术、经济和社会因素的影响，对这种项目进行风险预测和

20、识别，就可用情景分析法来预测和识别其关键风险因素及其影响程度。情景分析法对以下情况是特别有用的：提醒决策者注意某种措施或政策可能引起的风险或危机性的后果；建议需要进行监视的风险范围；研究某些关键性因素对未来过程的影响；提醒人们注意某种技术的发展会给人们带来哪些风险。情景分析法是一种适用于对可变因奏较多的项目进行风险预测和识别的系统技术，它在假定关键影响因素有可能发生的塞础上，构造多重情景，提出多种未来的可能结果，以便采取适当措施防息于未然。10.2.5 风险条目检查表“风险条目检查表”是最常用也是比较简单的风险识别方法，它是利用一组提问来帮助管理者了解项目在各个方面有哪些风险。在“风险条目检查

21、表”中，列出了所有可能的与每一个风险因素有关的提问，使得风险管理者集中来识别常见的、已知的和可预测的风险（如产品规模风险、依赖性风险、需求风险、管理风险及技术风险等）。“风险条目检查表”可以以不同的方式组织，通过判定分析或假设分析，给出这些提问的回答，就可以帮助管理或计划人员估算风险的影响。风险条目检查表一般根据风险要素进行编写，包括项目的环境、管理层的重视度、技术情况以及内部因素（如团队成员的技能或技能缺陷等）。风险识别中的风险条目是项目经验的积累，风险条目检查表可以以不同的方式组织。一般说，作为项目经理可以将主要的精力放在以下几方面：产品规模商业影响项目需求客户特性过程定义技术情况开发环境

22、人员数目及其经验其中每一方面包含很多的风险检查条目，通过对每个条目的回答，可以识别项目可能存在的风险。1）产品规模风险检查表项目风险是直接与产品规模戌正比的。下面的风险检查表中的条目标识了与软件规模相关的常见风险：是否以LOC或FP估算产品的规模？对于估算出的产品规模的信任程度如何？是否以程序、文件或事务处理的数目来估算产品规模？产品规模与以前产品的规模的平均值的偏差百分比是多少？产品创建或使用的数据库大小如何？产品的用户数有多少？产品的需求改变多少？交付之前有多少？交付之后有多少？复用的软件有多少？2）商业影响风险检查表下面的风险检查表中的条目标识了与商业影响相关的常见风险：本产品对公司的收

23、人有何影响？本产品是否得到公司高级管理层的重视9交付期限的合理性如何？将会使用本产品的用户数及本产品是否与用户的需要相符合？本产品必须能与之互操作的其他产品系统的数目？最终用户的水平如何？政府对本产品开发的约束是什么？延迟交付所造成的成本消耗是多少？产品缺陷所造成的成本消耗是多少？对于上述产品规模和商业影响的风险检查表中的每一个回答都必须与过去经验加以比较。如果出现了较大的百分比偏差或者如果数字接近过去很不令人满意的绪果，则风险较高。3）需求相关风险检查表很多项目在确定需求时都面临着一些不确定性和混乱。如果在项目早期容忍了这些不确定性，并且在项目进展过程中得不到解决，则这些问题就会对项目的成功

24、造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生锴误的产品或者拙劣地建造正确的产品。每一种情况都会使人不愉怏。例如，需求中潜在的问题包括：对产品缺少清晰的认识。对产品需求缺少认同。在确定需求时客户参与不够。没有优先需求。不确定的需要。新的市场不断变化需求。缺少有效的需求变化管理过程。对需求的变化缺少相关分析。如果对于这些问题中的任何一个问题的答案是肯定的，则需要进一步的研究，以评估潜在的风险。4）客户相关风险检查表不同的客户有不同的需要。有些人只知道他们需要什么，而有些人知道他们不需要什么。一些客户希望迹行详细的讨论，而另外的客户则满足子模糊的承诺。不同的客户有不同的个性。亠些

25、人喜欢享受客户的身份，而另一些人则根本不喜欢作为客户。一些人会高兴地接受几乎任何交付的产品饣并能充分利用一个不妤的产品；而另一些人则会对质量差的产品猛烈抨击。一些人会对质量好的产品表示赞赏，而另一些人则不管怎样都抱怨不休。客户和供应商之间也有各种不同的通信方式。一些人非常熟悉产品及生产厂商！而另一些人则可能綦未谋面，仅仅通过信件来往和电话与生产厂商沟通。一个“不好的”客户可能会对一个软件项目组能否在预算内完成项目产生很大的影响。对于项目管理者而言，“不好的”客户是对项目计划的巨大威胁和实际的风险。下面的风险裣查表中的条目标识了与客户特征相关的常见风险：你以前是否曾与这个客户合作过？该客户是否很

26、清楚薷要什么；他能否花时间把需求写出来？该客户是否同意花时间召开正式的需求收集会议，以确定项目范围？该客户是否愿意建立与开发者之间的快速通信渠道？该客户是否愿意参加复审工作？该客户是否具有该产品领域的技术奏养？该客户是否愿意让你的人来做他们的工作？该客户是否了解软件过程？如果对于这些问题中的任何一个问题的答案是否定的，则需要进一步的调研，以评估潜在的风险。5）过程风险检查表如果软件过程定义得不清楚，如果分析、设计、测试以无序的方式进行，如果质量是每个人都认为很重要的概念但没有人切实采取行动来保证它，那么这个项目就处在风险之中。过程问题包括：高级管理层是否有一份已经写好的政策陈述，该陈述中强调了

27、软件开发标准过程的重要性？开发组织是否已经拟定了一份已经成文的、用于本项目开发的软件过程的说明？开发人员是否同意按照文档所写的软件过程进行开发工作，并自愿使用它？该软件过程是否可以用子其他项目？管理者和开发人员是否接受过一系列的软件工程培训？是否为每一个软件开发者和管理者提供了印妤的软件工程标准？是否为作为软件过程一部分而定义的所有交付物建立了文档概要及示例？是否定期对需求规约、设计和编码进行正式的技术复审？是否定期对测试过程和测试情况进行复审，是否对每一次正式技术复审的结果建立了文裆，其中包括发现的错误及使用的资源？有什么机制来保证按照软件工程标准来指导工作？是否使用配置管理来维护系统软件需

28、求、设计、编码、测试用例之间的一致性？是否使用一个机制来控制用户需求的变化及其对软件的影响？对子每一个承包出去的子合同，是否有一份文档化的工作说明、一份软件需求规约和一份软件开发计划？是否有一个可遵循的规程，来跟螓及复审子合同承包商的工作？技术问题包括：是否使用方便易用的规格说明技术来辅助客户与开发者之间的通信？b是否使用特定的方法进行软件分析？是否使用特定的方法进行数据和体系结构的设计？是否90以上的代码都是使用高级语言编写的？是否定义及使用特定的规则进行代码编写？是否使用特定的方法进行测试用例的设计？是否使用配置管理软件工具控制和跟踪软件过程中的变化活动？是否使用工具来创造软件原型？是否使

29、用软件工具来支持测试过程？是否使用软件工具来支持文档的生成和管理？是否收集所有软件项目的质量度量值？是否收集所有软件项目的生产率度量值？如果对于上述问题的答案多数是否定的，则软件过程是薄弱的且风险很高。6）技术风险检查表采用新技术是具有挑战性和令人兴奋的，但这也是有风险的。下面的风险检查表中的条目标识了与建造的技术相关的常见风险：该技术对于你的公司而言是新的吗？客户的需求是否需要创建新的算法？待开发的软件是否需要使用新的或未经证实的硬件接口？待开发的软件是否需要与开发商提供的未经证实的软件产品接口？待开发的软件是否需要与功能和性能均未在本领域得到证实的数据库系统接口？产品的需求是否要求采用特定

30、的用户界面？产品的需求中是否要求开发某些程序构件，这些构件与你的公司以前开发的构件完全不同？需求中是否要求采用新的分析、设计、测试方法？ 需求中是否要求使用非传统的软件开发方法？需求中是否有过分的对产品的性能约束？客户能确定所要求的功能是可行的吗？如果对于这些问题中的任何一个问题的答案是肯定的，则需要进一步的调研，以评估潜在的风险。7）开发环境风险检查表软件工程环境支持项目组、过程及产品，但是，如果环境有缺陷，它就有可能成为重要的风险源。下面的风险检查表中的条目标识了与开发环境相关的风险：是否有可用的软件项目管理工具？是否有可用的软件过程管理工具？是否有可用的分析及设计工具？分析和设计工具是否

31、适用于待建造产品？是否有可用的编译器或代码生成器？是否有可用的测试工具？是否有可用的软件配置管理工具？环境是否利用了数据库或数据仓库？项目组的成员是否接受过每个所使用工具的培训阳是否有专家能够回答有关工具的问题？工具的联机帮助及文档是否适当？如果对于上述问题的答案多数是否定的，则软件开发环境是薄弱的且风险很高。8）人员数目及经验风险检查表下面的风险检查表中的条目标识了与人员数目及经验相关的常见风险：是否有最优秀的人员可用？人员在技术上是否配套？是否有足够的人员可用？开发人员是否能够自始至终地参加整个项目的工作？项目中是否有一些人员只能部分时间工作？开发人员对自己的工作是否有正确的期望？开发人员

32、是否接受过必要的培训？开发人员的流动是否仍能保证工作的连续性？如果对于这些问题中的任何一个问题的答案是否定的，则需要进一步的调研，以评估潜在的风险。当然，检查表的类别和条目可以根据企业或者项目的具体情况来选择或者开发。例如，美国的软件工程研究所（简称SEI）的一份研究报告对于软件风险提出用Class、Elcment、Attributc三个层次描述风险列表（见图105）。对于Class（类）层分三组，即ProductEnginccring、Dcvclopment Environmcnt和Program Constraints。每个Class组下包含若干Elemcnt（元素），每个Elemcnt组

33、下又包含若干Attributc（属性）。它们共同构成了风险检查表条目，通过Attributc属性值来识别和评估风险。具体条目要素见表101。图10度量5风险三层分析结构表亻0丬 三层风险检查表类（Class）元素（ElCmcnt）属性（Attributc）产品工程（Product Enginccring）需求（RCquiremcnts）稳定性Stability）完整性（Completencss）清晰性Clarity）有效性（validity）可行性（Feasibility）前瞻性（Precedent）衡量性（ScalC）设计（DCsign）功能性（Functionality）难度（Diffic

34、u1ty）接口（Intcrfaccs）性能（PCrforman）易讽！性（Tcstability）硬件的限制（Hardwarc constraints）非开发软件（Non Devclopmcntal software）编码和单元测试（Codc and unittcst）可行性（FCasibility）可测性（Tcsting）编码（CodingImp1cmcntation）集成和测试（Integration and Tes！）环境（Environmcnt）产品（Product）系统（Systcm）工程特点（En目inecring Spccialtics）可维护性（Maintainability）

35、可靠性（Reliability）安全性（Socurity）人为因素（Human FactOrs）规m（Spocification）开发环境（DcvclopmentEnvironmcnt）开发过程（Developmcnt Process）正规性（Formality）适合性（Suitability）过程控制（Process Control）过程的熟知程度（Familiarity）产品控制（Productntrol）开发系统（Dcvc1opmcnt Systcm）容童（Capacity）适合性（Suitability）可用性（UsabiIity）了解程度（Familiarity）可靠性（Re“abi

36、lity）系统的支持性（System suppOrt）供应能力（Dcliverability）管理过程（Management Process）计划性（Planning）项目组织（Projcct Organization）管理经验（ManagCment Expcricnce）管理程序之间的接口（Program Interfaccs）管理方法（Managcmcnt Mcthods）监控（Monitoring）人员管理（Pcrsonncl Management）质量保证（Quality Assurancc）配置管理（Configuration Managcmcnt）工作环境（Work Environ

37、mcnt）质量的态度（Quality Attitudc）合乍性（CoopCrat击On）沟通（Communication）团队士气（MoralC）项目限制（Program constraints）资源（Resourccs）进度（Schcdulc）人员（Stafp预算（BudgCt）设备（Facilities）合同（Contrac！）合同类型Typc of Contract）约束条件（Rcstriction）前提（DCpcndence）项目接口丨Program Intcrfaccs）客户（Customcr）相关合同人（AssoCiate COntractOrs）弓合lPl（SubcOntract

38、ors）总承包人（PrimC COntractOr）公司管理机构（CorpOratc Managcment）供方（vcndors）合同条款（Politics）10.2.6 真他方法进行风险识别的时候，项目经理不一定能预测到所有的风险情况，而且有时当局者迷，与不同的项目相关人员进行有关风险的面谈，将有助于识别那些在常规计划中未被识别的风险。在进行可行性研究时获得的项目前期面谈记录，往往是风险识别的很好褰材。10.2.7 风险识别的结果风险识别的结果可以是一个风险清单表，如表10度量2所示，表的第一列列出识别出来的风险，笫二列是对风险进行的分类。表10- 度量2风险识别列表风险类别规模估算可能非常

39、低产品规模用户数量大大超出计划产品规模复用程度低于计划产品规模最终用户抵制该计划商业影响交付期限将被紧缩南业影响资金将会流失客户特性用户将改变需求产品规模技术达不到预期的效果技术情况缺少对工具的培训开发坏境人员缺乏经验人贞数目及其经验人员流动频繁人员数目及其经验10.3 风险评估风险评估，又称风险预测，就是对识别出的风险做进一步分析，对风险发生的概率进行估计和评价，对风险后果的严重程度进行估计和评价，对风险影响范围进行估计和评价，以及对于风险发生时间进行估计和评价。10.3.1 概念在实践中，通常把风险评估的结果用风险发生的概率以及风险发生后对项目目标的影响来表示，风险R是该风险发生的概率P和

40、影响程度I的函数：即Rf（P，I）。然后建立风险表，按风险的严重性排序，确定最需要关注的前几个（TOP 10，一般说前10个，具体多少个可以视项目的具体情况而定）风险。风险评估的方法包括定性风险评估和定量风险评估。10.3.2 定性风险评估定性风险评估主要是针对风险概率及后果进行定性的评估，例如采用历史资料法、概率分布法、风险后果估计法等。历史资料法主要是应用历史数据进行评估的方法，通过同类历史项目的风险发生情况，进行本项目的估算。概率分布法主要是按照理论或者主观调整后的概率进行评估的一种方法，例如正态分布是一种常用的概率分布。每个风险的概率值可以由项目组成员个别估算，然后将这些值平均，得到一

41、个有代表性的概率值。另外，可以对风险事件后果进行定性的评估，按其特点划分为相对的等级，形成一种风险评价矩阵，并赋一定的加权值来定性地衡量风险大小。例如，根据风险事件发生的概率度，将风险事件发生的可能性定性地分为若干等级。风险概率值是介于没有可能（0）和确定（l）之间的。风险概率度量也可以采用高、中、低或者极高、高、中、低、极低，以及不可能、不一定、可能和极可能等不同方式表达。风险后果是风险影响项目目标的严重程度，可以从无影响到无穷大影响饣风险后果的影响度量可以采用高、中、低或者极高、高、中、低、极低，以及灾难、严重、轻度、轻微等方式表达。如表10亏3所示，将风险发生的概率分为5个等级。同时可以

42、将风险的影响程度分为若干等级，如表10度量4所示，将风险后果的影响程度分为4个等级。 衰103风险发生概率的定性等级表亻4风险后果彤晌的定性等级将上述风险后果的影响和发生概率等级编制成矩阵并分别给以定性的加杈指数，可形成风险评价指数矩阵，表10度量5为一种定性风险评估指数矩阵的实例。表5风险评估指数矩阵实例矩阵中的加杈指数称为风险评估指数，指数1到20是根据风险事件可能性和严重性水平综合而确定的。通常，将最高风险指数定为1，对应于风险事件是频繁发生的并是有灾难性的后果；最低风险指数定为20，对应于风险事件几乎孔可能发生并且后果是轻微的。数字等级的划分具有随意性，但要便于区别各种风险的档次，划分

43、得过细或过粗都不便子风险的决策，因此需要根据具体对象制定。项目管理者可以根据项目的具体情况确定风险接受准则，这个准则没有统一的标准，例如可以对风险矩阵中的指数给出四种不同类别的决策结果：指数15，是不可接受的风险；指数69，是不希望有的风险，需由项目管理者们决策；指数1017，是有控制的接受的风险，需要项目管理者们评审后方可接受；指数1820，是不经评审即可接受的风险。由于这种风险评估指数通常是主观制定的，而且定性的指标有时没有实际意义，因此这是定性评估的一大缺点，因为无论是对风险后果的严重性或是风险发生的概率做出严格的定性量度都是很困难的。表：06 简易的定性风险评估表当然，定性风险评估可以

44、采用更为简单的方法。表106给出一种简易的定性评估的表格。其中，将风险发生的概率分为高、中、低三个等级，将风险后果的影响也分为高、中、低三个等级，通过表10度量6矩阵定性地确定风险的评估结果。风险后果影响和发生概率从风险管理的角度来看各自起着不同的作用。一个具有高影响但低概率的风险因素不应当占用太多的风险管理时间，而具有中到高概率、高影响的风险和具有高概率及低影响的风险就应该进行风险分析。10.3.3 定量风险评估通过定性风险评估，人们能对项目风险有一个大致了解，可以了解项目的薄弱环节。但是，有时需要了解风险发生的可能性到底有多大，后果到底有多严重等b回答这些问题，就需要对风险进行定量的评价分

45、析。定量风险评估是一种广泛使用的管理决策支持技术。一般，在定性风险分析之后就可以进行定量风险分析。定量风险分析过程的目标是量化分析每一个风险的概率及其对项目目标造成的后果，也分析项目总体风险的程度。定量风险评估可以包括访谈、盈亏平衡分析、决策树分析、模拟法等方法。访谈 访谈技术用于量化对项目目标造成影响的风险概率和后果。采用访谈方式，可以邀请以前搞过与本项目相类似项，目的专家，这些专家运用他们的经验做出风险度量，其结果将会相当准确和可靠，甚至有时比通过数学计算与模拟仿真的结果还要准确和可靠。如果风险损失后果的大小不容易直接估计出来，可以将损失分解为更小的部分，再对其进行评估，然后将各部分评估结

46、果累加，形成一个合计评估值。例如，如果使用3种新编程工具，可以单独评估每种工具未达到预期效果的损失，然后再把损矢加到一起，这要比总体评估容易多了。2。盈亏平衡分析盈亏平衡分析就是要确定项目的盈亏平衡点。在平衡点上收人等于成本，此点是用来标志项目不亏不盈的开发量，用来确定项目的最低生产量。盈亏平衡点越低，项目盈利的机会就越大饣亏损的风险就越小。因此，盈亏平衡点表达了项目生产能力的最低容许利用程度。一种对风险评估的常用技术是定义风险的参照水准，对绝大多数软件项目来讲，风险因素成本、性能、支持和进度就是典型的风险参照系，也就是说，对成本超支、性能下降、支持困难、进度延迟都有一个导致项目终止的水平值。如果风险的组合所产生的问题超出了一个或多个参照水平值，就应该终止该项目的工作。在项目分析中，风险水平参考值是由一系列的点构成的，每一个单独的点常称为参照点或临界点。如果某风险藩在临界点上，可以利用性能分析、成本分析、质量分析等来判断该项目是否继续工作。图106表示了这种情况。图106项目临界点3）策树分析决策树分析是一种形象化的图表分析方法，它提供项目所有可供选择的行动方案以及行动方案之间的关系、行动方案的后果以及发生的概率，为项目经理提供选择最佳方案的依据。决策树分析采用损益期望值（Expected Monctary Valuc，E