软件工程的风险管理.docx

风险管理引言风险是关注未来将要发生的事情。今天和昨天己不再被关怀，如同我们已经在收获由我们过去的行为所播下的种子。问题是：我们与否可以通过变化我们今天的行为，而为一种不同样於J、充斥但愿的I、更美好的明天发明机会。另首先，这意味着，风险波及变化，如思想、观念、行为、或地点的变化第三，风险波及选择及选择自身所包括的不确定性。因此，就象死亡和税收同样，风险是生活中最不确定的元素之一。当在软件工程领域考虑风险时，Charette的三个概念定义是显而易见的。未来是我们所关怀的一一什么样的风险会导致软件项目彻底失败呢？变化也是我们所关怀的一一顾客需求、开发技术、目In计算机、以及所有其他与项目有关的原因的变化将会对准时交付和总体成功产生什么影响呢？最终,我们必须抓住选择机会一一我们应当采用什么措施及工具？需要多少人员参与工作？对质量的规定要抵达什么程度才是“足够的”？PeterDruckerDRU75曾经说过：“当没有措施消除风险，甚至连试图减少该风险也存在疑问时，这些风险就是真正的风险了"。在我们可以标识出软件项目中的“真正风险”之前，识别出所有对管理者及开发者而言均为明显的风险是很重要的。1. 1被动和积极H勺风险方略被动风险方略被戏称为“印地安那琼斯学派的风险管理”TH092o印地安那琼斯在以其名字为影片名的电影中，每当面临无法克服的困难时，总是一成不变地说：“不要紧张，我会想出措施来的！"。印地安那琼斯从不紧张任何问题，直到它们发生，再做出英雄式FrJ反应。遗憾的是，一般的软件项目管理者并不是印地安那琼斯，且软件项目组的组员也不是他的可信赖的伙伴。大多数软件项目组还是仅仅依赖于被动风险方略。被动方略最多不过是针对也许发生的风险来监督项目，直到它们变成真正的问题时,才会拨出资源来处理它们。更普遍的状况是，软件项目组对于风险不闻不问，直到发生了错误，这时，项目组才赶紧采用行动，试图迅速地纠正错误。这常常被称为“救火模式”。当这样的努力失败后，“危机管理”CHA92接管一切，这时项目已经处在真正的危机中了。对于风险管理的一种更聪颖的方略是积极式的。积极方略早在技术工作开始之前就已经启动了。标识出潜在於I风险，评估它们出现的I概率及产生的影响，且按重要性加以排序，然后，软件项目组建立一种计划来管理风险。重要的目的是防止风险，但由于不是所有的!风险都可以防止，因此，项目组必须建立一种意外事件口勺计划，使其在必要时可以以可控的及有效的方式作出反应。在本章其他部分，我们将讨论风险管理的积极方略。1.2软件风险虽然对于软件风险的严格定义还存在诸多争议，但在风险中包括了两个特性这点上是已抵达了共识的HIG95：不确定性一一刻划风险的事件也许发生也也许不发生；即，没有100%发生的风险（100%发生口勺风险是加在项目上的约束）。损失一一假如风险变成了现实，就会产生恶性后果或损失。进行风险分析时，重要的是量化不确定性的程度及与每个风险有关的损失的程度。为了实现这点，必须考虑不同样类型的风险。项目风险威胁到项目计划。也就是说，假如项目风险变成现实，有也许会迟延项目的进度，且增长项目的成本。项目风险是指潜在的预算、进度、人力（工作人员及组织）、资源、客户、及需求等方面的问题以及它们对软件项目的影响。在第5章中，项目复杂性、规模、及构造不确定性也被定义为项目（估算）风险原因。技术风险威胁到要开发软件的质量及交付时间。假如技术风险变成现实，则开发工作也许变得很困难或主线不也许。技术风险是指潜在的设计、实现、接口、验证、和维护等方面的问题。此外，规约的二义性、技术的不确定性、陈旧的技术、及“先进时”技术也是风险原因。技术风险的发生是由于问题比我们所设想的愈加难以处理。商业风险威胁到要开发软件的生存能力。商业风险常常会危害项目或产品。五个重要的商业风险是：（1）开发了一种没有人真正需要的优秀产品或系统（市场风险）；（2）开发的产品不再符合企业的整体商业方略（方略风险）：（3）建造了一种销售部门不懂得怎样去卖的产品；（4）由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）；以及（5）没有得到预算或人力上的保证（预算风险）。应当注意到的很重要的一点是：简朴的分类并不总是行得通。某些风险主线无法事先预测。另一种常用的分类方式是由CharetteCHA89提出的。已知风险是通过仔细评估项目计划、开发项目的!商业及技术环境、以及其他可靠的信息来源（如，不现实的交付时间，没有需求或软件范围的文档、恶劣的开发环境）之后可以发现的那些风险。可预测风险可以从过去项目的经验中推断出来（如，人员调整、与客户之间无法沟通、由于需要进行维护而使开发人员精力分散）。不可预测风险就象纸牌中的大王，它们也许、也会真FI勺出现，但很难事先识别出它们来。1.3识别风险识别风险是试图系统化地确定对项目计划（估算、进度、资源分派）的威胁。通过识别已知的和可预测的风险，项目管理者已经迈出了第一步一一在也许时防止这些风险，且当必要时控制这些风险。在L2节中提出的每一类风险又分为两个不同样的类型：一般性风险和特定产品H勺风险。一般性风险对每一种软件项目而言都是一种潜在的威胁。特定产品的风险只有那些对目前项目的技术、人员、及环境非常理解的人才能识别出来。为了识别特定产品H勺风险，必须检查项目计划及软件范围阐明，并给出如下问题的答案：“本项目中有什么特殊的特性也许会威胁到我们的项目计划？”一般性风险和特定产品的风险都应当被系统化地标识出来。TomGilbG1L88很贴切地体现了这点：“假如你不积极袭击风险，风险就会积极袭击你”。识别风险的一种措施是建立风险条目检查表。该检查表可以用于识别风险，并使得人们集中来识别下列常见子类型中欧!已知的及可预测的风险：产品规模一一与要建造或要修改的软件的总体规模有关的风险。商业影响-一与管理或市场所加诸的约束有关的风险。 客户特性一一与客户的素质以及开发者和客户定期通信的能力有关的I风险。 过程定义一与软件过程被定义的程度以及它们被开发组织所遵守的程度有关的风险。 开发环境一一与用以建造产品的工具的可用性及质量有关的风险。 建造的技术一一与待开发软件的复杂性及系统所包括技术的I“新奇性”有关的风险。 人员数目及经验一一与参与工作的软件工程师的总体技术水平及项目经验有关的风险。风险条目检查表可以以不同样的方式来组织。与上述每个话题有关的问题可以由每一种软件项目来回答。这些问题的答案使得计划者可以估算风险产生的影响。我们也可以采用另种不同样的!风险条目检查表，它仅仅列出与每种常见子类型有关的特性。最终，列出一组“风险元素和驱动因子”AFC88以及它们发生的J概率。有关性能、支持、成本、及进度的驱动因子将在后来讨论。1.3.1产品规模风险有经验H勺管理者几乎都对下面的陈说没有异议：项目风险是直接与产品规模成正比的。下面的风险检查表中的条目的识了与产品（软件）规模有关的常见风险: 与否以LOC或FP估算产品的规模？ 对于估算出的产品规模的信任程度怎样？ 与否以程序、文献或事务处理的数目来估算产品规模？ 产品规模与此前产品的规模平均值的偏差比例是多少？ 产品创立或使用的数据库大小怎样？ 产品的顾客数有多少？ 产品的需求变化多少？交付之前有多少？交付之后有多少？ 复用的软件有多少？在每一种状况下，待开发产品的信息必须与过去的经验加以比较。假如出现了较大的比例偏差，或者假如数字相近但过去的成果很不令人满意，则风险较高。1.3.2商业影响风险有一种大型软件企业的工程经理在他的墙上挂了一种镜框，上面写着：“上帝给了我头脑使我成为一种优秀的项目管理者，同步每当销售部门设定项目的最终期限时，也让我经历了地狱般的煎熬”。销售部门是受商业驱动时，而商业考虑有时会直接与技术现实发生冲突。下面的风险检查表中的条目的识了与商业影响有关的常见风险：本产品对企业的收入有何影响？本产品与否得到企业高级管理层的重视? 交付期限的合理性怎样？ 将会使用本产品的顾客数及本产品与否与顾客的需要相符合？ 本产品必须能与之互操作的其他产品/系统口勺数目？ 最终顾客的水平怎样？ 必须产生并交付给顾客的产品文档的量与质怎样？ 政府对本产品开发的约束？ 延迟交付所导致的!成本消耗是多少？ 产品缺陷所导致的成本消耗是多少？对于待开发产品的每一种回答都必须与过去的经验加以比较。假如出现了较大的比例偏差，或者假如数字相近但过去的成果很不令人满意，则风险较高。 .3.3客户有关的风险并非所有客户都是同样的。PreSSmarl和HerrOnPRE91在讨论这个话题时曾经说过:客户有不同样的需要。某些人懂得他们需要什么；而另某些人懂得他们不需要什么。某些客户但愿进行详细讨论，而另某些客户则满足于模糊的承诺。客户有不同样的个性。某些人喜欢享有客户的身份一一紧张、谈判、一种好产品带来的心理满足;而另某些人则主线不喜欢作为客户。某些人会快乐地接受几乎任何交付的产品，并能充足运用一种不好的产品；而另某些人则会对质量差的产品剧烈抨击。某些人会对质量好的产品体现他们的赞赏：而另某些人则不管怎样都会埋怨不休。客户和他们的供应商之间也有多种不同样的通信方式。某些人非常熟悉产品及生产厂商；而另某些人则也许素未谋面，仅仅通过信件往来和几种匆忙的与生产厂商沟通。客户常常是矛盾的。他们但愿昨天的一切工作都是免费的。生产厂商常常陷入客户自己的矛盾之中。一种“不好的”客户也许会对一种软件项目组能否在预算内准时完毕项目产生很大的影响。对于项目管理者而言，不好口勺客户是对项目计划的巨大威胁和实际的风险。下面口勺风险检查表中的条目的识了与客户特性有关的常见风险： 你此前与否曾与这个客户合作过？ 该客户与否很清晰需要什么？他能否花时间把需求写出来？ 该客户与否同意花时间召开正式的需求搜集会议（第11章），以确定项目范围？ 该客户与否乐意建立与开发者之间的迅速通信渠道？ 该客户与否乐意参与复审工作？ 该客户与否具有该产品领域的技术素养?该客户与否乐意让你的人来做他们的工作，即，当你的人在做详细的技术工作时，该客户与否会坚持在旁边监视？该客户与否理解软件过程？假如对于这些问题中的任何一种欧I答案与否认的J,则需要进行深入的调研，以评估潜在的风险。1. 3.4过程风险假如软件过程（第2章）定义得不清晰；假如分析、设计、及测试以无序的方式进行;假如质量是每个人都认为很重要的概念，但没有人切实地采用行动来保证它，那么，这个项目就处在风险之中。如下问题摘自一次由R.S.Pressman&Associates,Inc.PRE95建立时对软件工程实践活动进行评估的研讨会。这些问题已经在软件工程研究所（SEl）日勺过程评估调查表中进行了改编。过程问题你的高级管理层与否支持一份已经写好的政策综述，该综述中强调了软件开发原则过程的重要性吗？你的组织与否已经建立了份已经成文的、用于本项目的软件过程的阐明？开发人员与否“签约”同意按照文档所写的软件过程进行开发工作，并自愿使用它？该软件过程与否可以用于其他项目？ 你的组织与否已经为管理者及技术人员开设了一系列的软件工程培训课程？与否为每种软件开发者和管理者都提供了印好的软件工程原则？.与否为作为软件过程一部分而定义的所有交付物建立了文档概要及示例？ 与否认期地对需求规约、设计和编码进行正式的技术复审？ 与否认期地对测试过程和测试状况进行复审？ 与否对每一次正式技术复审的成果要建立了文档，其中包括发现的错误及使用的资源？ 与否有什么机制来保证软件工程标精确认的方案指导的工作开展正常？与否使用配置管理来维护系统/软件需求、设计、编码及测试用例之间的一致性？ 与否使用一种机制来控制顾客需求的变化及其对软件的影响？ 对于每一种承包出去的子协议，与否有一份文档化的工作阐明、一份软件需求规约及一份软件开发计划？与否有一种可遵照的规程，来跟踪及复审子协议承包商FrJ工作？技术问题与否使用以便易用的规格阐明技术来辅助客户与开发者之间的通信？与否使用特定的措施进行软件分析？ 与否使用特定的措施进行数据和体系构造的设计？ 与否百分之90以上的代码都是采用高级语言编写的？ 与否认义及使用特定的I规则进行代码编写？ 与否使用特定的措施进行测试用例设计？ 与否使用软件工具来支持计划和跟踪活动？ 与否使用配置管理软件工具来控制和跟踪软件过程中的变化活动？ 与否使用软件工具来支持软件分析和设计过程？ 与否使用工具来创立软件原型？ 与否使用软件工具来支持测试过程？ 与否使用软件工具来支持文档的生成和管理？ 与否搜集所有软件项目的质量度量值？ 与否搜集所有软件项目的生产率度量值？假如对于上述问题中大多数的答案与否认的，则软件过程是微弱的，且风险很高。1.3.5技术风险突破技术的限制是极具挑战性且令人兴奋的，这是几乎每一种技术人员的梦想，由于这迫使开发人员使出他的或她的浑身解数，但这也是很有风险的。MUrPhy定律似乎对开发工作中H勺这一部分有了控制，使得我们难以预测风险，更不用说对它们进行计划了。下面的风险检查表中的条目的识了与建造的技术有关的常见风险： 该技术对于你的组织而言是新的吗？ 客户的需求与否需要创立新的算法或输入、输出技术？ 软件与否需要使用新的或未经证明的硬件接口？ 待开发软件与否需要与开发商提供的未经证明的软件产品接口？ 待开发软件与否需要与其功能及性能均未在本领域中得到证明的数据库系统接口？ 产品的需求中与否规定采用特定的顾客界面？ 产品的需求中与否规定开发某些程序构件，这些构件与你的组织此前所开发过的构件完全不同样？ 需求中与否规定使用新的分析、设计、或测试措施？ 需求中与否规定使用非老式的软件开发措施，如形式化措施、基于Al的措施、以及人工神经网络？ 需求中与否有过份的对产品的性能约束？ 客户能确定所规定的功能是“可行的T吗？假如对于这些问题中的任何一种的回答是肯定的，则需要进行深入的调研，来评估潜在的风险。1.3.1 开发环境风险假如一种木匠被规定用弯曲的、钝的手锯制作一件好家俱，则最终产品的质量肯定是令人怀疑的。虽然是纯熟的开发者，不合适的或没有效率的工具也会阻碍工作的进行。软件工程环境支持项目组、过程及产品。不过，假如环境有缺陷，它就也许成为重要的风险源。下面的风险检查表中的条目的识了与开发环境有关的常见风险（第29章讨论了本检查表中所列的工具种类）： 与否有可用的软件项目管理工具？ 与否有可用的软件过程管理工具？ 与否有可用的!分析及设计工具？ 分析及设计工具与否支持合用于待建造产品的措施？.与否有可用的编译器或代码生成器，且合用于待建造产品？.与否有可用的测试工具，且合用于待建造产品？ 与否有可用的软件配置管理工具？ 环境与否运用了数据库或仓库？ 与否所有软件工具都是彼此集成的?项目组的组员与否己经接受过关干每个工具的培训I? 与否有有关的专家可以回答有关工具的问题？ 工具的联机协助及文档与否合适？假如对于上述问题中大多数的回答与否认的，则软件开发环境是微弱的，且风险很高。1.3.7 与人员数目及经验有关的风险BoehmBOE89提议了如下问题可用于评估与人员数目及经验有关的风险： 与否有最优秀的人员可用？ 人员在技术上与否配套？ 与否有足够的人员可用？ 开发人员与否可以自始自终地参与整个项目的工作？ 项目中与否有某些人员只能部分时间工作？ 开发人员对自己的工作与否有对时的期望？ 开发人员与否接受过必要的培训？ 开发人员的流动与否仍能保证工作的持续性？假如对于这些问题中的任何一种的回答与否认的，则需要进行深入的调研，以评估潜在的风险。1.3.8 风险原因和驱动因子美国空军AFC88写了一本小册子，其中包括了怎样很好地识别和消除软件风险的指南。他们所用的措施规定项目管理者标识影响软件风险原因的风险驱动因子，这些原因包括性能、成本、支持和进度。在本讨论中，风险原因是以如下的方式定义的： 性能风险一一产品可以满足需求且符合于其使用目的的不确定的程度。 成本风险一一项目预算可以被维持的不确定的程度。 支持风险一一软件易于纠错、适应及增强的不确定的程度。 进度风险一一项目进度可以被维持且产品能准时交付的不确定的程度。每一种风险驱动因子对风险原因的影响均可分为四个影响类别一一可忽视的、轻微的I、严重的及劫难性的。表11B0E89指出了由于错误而产生的潜在影响（标为1的行）或没有抵达预期的成果所产生的潜在影响（标为2的行）。影响类别的选择是以最符合表中描述的特性为基础的.1.4风险预测风险预测，又称风险估算，试图从两个方面评估每一种风险一一风险发生的也许性或概率，以及假如风险发生了，所产生的后果。项目计划者，以及其他管理人员和技术人员，一起执行四个风险预测活动：（1）建立一种尺度，以反应风险发生的也许性；（2）描述风险的后果；（3）估算风险对项目及产品的I影响；（4）标注风险预测口勺整体精确度，以免产生误解。1.4.1建立风险表风险表给项目管理者提供了一种简朴的风险预测技术（风险表应当采用电子表格来实现，这样使得表中的内轻易于操纵及排序）。风险表的样本如图12所示。项目组一开始要在表中的第一列列出所有风险（不管多么细微）。这可以运用L3节所述的）风险检查表条目来完毕。每一种风险在第二列上加以分类（如，PS指产品规模风险,BU指商业风险）。每个风险发生的概率则输入到第三列中。每个风险的概率值可以由项目组组员个别估算，然后将这些单个值求平均，得到种有代表性的概率值。下一步是评估每个风险所产生的影响。使用表所述的特性评估每个风险原因，并确定其影响H勺类别。对四个风险原因一一性能、支持、成本、及进度一一的影响类别求平均可得到一种整体Fl勺影响值（假如其中一种风险原因对项目尤其重要，也可以使用加权求平均值）。一旦完毕了风险表的前四列内容，就要根据概率及影响来进行排序。高发生概率、高影响的风险放在表的上方，而低概率风险则移到表的下方。这样就完毕了第一次风险排序。项目管理者研究已排序的表，并定义一条中断线。该中断线（表中某一点上的一条水平线）体现：只有那些在线之上的风险才会得到深入的关注。而在线之下的风险则需要再评估以完毕第二次排序。风险影响及概率从管理的角度来考虑，是起着不同样的作用的I（见图1-1）。一种具有高影响但发生概率很低的风险原因不应当花费太多的管理时间。而高影响且发生概率为中到高的风险、以及低影响且高概率的风险，应当首先列入管理考虑之中。所有在中断线之上欧I风险都必须进行管理。标有RMMMrJ列中包括了一种指示器，指向为所有中断线之上的风险所建立的风险缓和、监控、及管理计划（RiSkMitigation,MonitoringandManagementPlan）。RMMM计划将在L5节讨论。风险概率确实定可以通过先做个别估算而后求出一种有代表性的值来完毕。虽然该措施是可行的I,不过仍存在诸多其他确定风险概率的愈加复杂的技术AFC88可供使用。风险驱动因子的评估是以一种定性的概率尺度：不也许、不一定、也许和极也许为基础，然后,根据每一种定性值有关的数学概率值（如，概率为0.7到L0体现极也许发生的风险）来计算班1.4.2评估风险影响假如风险真的发生了所产生的后果有三个原因也许会受影响：风险的性质，范围，及时间。风险的性质是指当风险发生时也许产生口勺问题。例如，一种定义得很差的与客户硬件於J外部接口（技术风险）会阻碍初期的设计及测试，也有也许导致项目后期阶段的系统集成问题。风险的范围结合了严重性（即风险有多严重？）及其整体分布状况（项目中有多少部分受到影响或有多少顾客受到损害？）。最终，风险的时间重要考虑何时可以感到风险及持续多长时间。在大多数状况下，项目管理者但愿“坏消息”越早出现越好，但在某些状况下,越迟越好。让我们再回到美国空军提出的风险分析措施上来AFC88o如下的环节被提议用来确定风险的整体影响：1 .确定每个风险元素发生的平均概率。2 .使用表11,基于其中列出的原则来确定每个原因的影响。3 .按照前面几节给出的措施完毕风险表，并分析其成果。1. 4,1节和1.4.2节所述H勺风险预测和分析技术可以在软件项目进展过程中迭代使用。项目组应当定期更查风险表，再评估每一种风险，以确定新的状况与否引起其概率及影响发生变化。这个活动的成果也许需要在表中添加某些新风险，删除某些不再有影响的风险，并变化风险欧!相对位置。1.4.3风险评估在风险管理中的这一步，我们建立了如下形式的一系列三元组CHA89：ri,litxi其中ri体现风险，Ii体现风险发生的概率，Xi则体现风险产生的影响。在风险评估过程中，我们深入审查在风险预测阶段所做的估算的!精确度，试图为所发现的风险排出优先次序，并开始考虑怎样控制和/或防止也许发生的风险。要使评估发生作用，必须定义一种风险参照水平值CHA89O对于大多数软件项目而言，前面所讨论的风险原因一一性能、成本、支持、及进度一一也代体现了风险参照水平值。即，对于性能下降、成本超支、支持困难、或进度延迟（或者这四种的组合），均有一种水平值的规定，超过它就会导致项目被迫终止。假如风险的组合所产生的问题引起一种或多种参照水平值被超过，则工作将会停止。在软件风险分析中，风险参照水平值存在一种点，称为参照点或临界点，在这个点上决定继续进行该项目或终止它（问题太大了）都是可以接受的。图1-2以图形方式体现了这种状况。假如风险的组合产生问题而导致成本超支及进度延迟，则会有一种水平值，即图中所示的曲线，当超过它时会引起项目终止（阴影区域）。在临界点上，决定继续进行或终止项目都是可以的。实际上，参照水平很少能表抵达如图所示的一条光滑曲线。在大多数状况下，它是一种区域，其中存在诸多不确定性（即，基于参照值的组合进行管理决策常常是不也许的）。因此，在风险评估过程中，我们执行如下环节：1 .定义项目的风险参照水平值。2 .建立每一组ri,li,xi与每一种参照水平值之间的关系。3 .预测一组临界点以定义项目终止区域，该区域由一条曲线或不确定区域所界定。4 .预测什么样的风险组合会影响参照水平值。更详细的讨论参见专门探讨风险分析的论著（如文献CHA89、R0W88）。5 .5风险缓和、监控和管理这一步的所有风险分析活动都只有一种目的一一辅助项目组建立处理风险的方略。一种有效的方略必须考虑三个问题： 风险防止。 风险监控。 风险管理及意外事件计划。假如软件项目组对于风险采用积极的措施，则防止永远是最佳的方略。这可以通过建立一种风险缓和计划来抵达。例如，假设频繁的人员流动被标注为种项目风险，r0o基于以往的历史及管理经验，人员频繁流动的概率10被估算为0.7（70%,相称高），而影响x被预测为对于项目成本及进度有严重的影响（见图11）。为了缓和这个风险，项目管理必须建立种方略来减少人员流动。也许采用的方略如下： 与既有人员一起探讨一下人员流动的原因（如，恶劣的）工作条件，低酬劳，竞争剧烈的劳动力市场）。 在项目开始之前，采用行动以缓和那些在管理控制之下的原因。 一旦项目启动，假设会发生人员流动并采用某些技术以保证当人员离开时时工作持续性。对项目组进行良好组织，使得每一种开发活动的信息能被广泛传播和交流。 定义文档的原则，并建立对应的机制，以保证文档能被及时建立。 对所有工作进行详细复审，使得不止一种人熟悉该项工作。 对于每一种关键的!技术人员都指定一种后备人员。伴随项目的进展，风险监控活动开始进行了。项目管理者监控某些原因，这些原因可以提供风险与否正在变高或变低的指示。在人员频繁流动的例子中，应当监控下列原因： 项目组组员对于项目压力的一般态度。 项目组的凝聚力。 项目组组员彼此之间的关系。 与酬劳和利益有关的潜在问题。 在企业内及企业外工作的也许性。除了监控上述原因之外，项目管理者还应当监控风险缓和环节的效力。例如，前述的一种风险缓和环节中规定定义“文档的原则，并建立对应的机制，以保证文档能被及时建立“。假如有关键的人员离开了项目组，这是一种保证工作持续性的机制。项目管理者应当仔细地监控这些文档，以保证每种文档内容对的，且当新员工加入该项目时，能为他们提供必要的信息。风险管理及意外事件计划假设缓和工作已经失败，且风险变成了现实。继续前面的例子，假定项目正在进行之中，有某些人宣布将要离开。假如按照缓和方略行事，则有后备人员可用，由于信息已经文档化，有关知识已经在项目组中广泛进行了交流。此外，项目管理者还可以临时重新将资源调整到那些人员充足的功能上去（并调整项目进度），从而使得新加入人员可以“赶上进度”。同步，应当规定那些要离开的人员停止工作，并在最终几星期进入“知识交接模式”。这也许包括：基于视频的知识捕捉，“注释文档”的建立和/或与仍留在项目组中的组员进行交流。值得注意的是，RMMM环节将导致额外的项目开销。例如，花费时间去“备份”每一种关键的技术人员是需要花钱的。因此，风险管理的部分任务是评估何时由RMMU环节所产生的I效益低于实现它们所花费的成本。本质上是讲，项目计划者执行一种经典的成本一效益分析来估算项目的开销变化状况。假如对于频繁人员流动风险的缓和环节将会增长15%的项目成本及持续时间，而重要Fl勺成本原因是“备份后备人员”，则管理者也许决定不执行这一环节。另首先，假如风险缓和环节仅增长5%的成本及3%的持续时间，则管理者极有也许将这一环节付诸实现。对于一种大型项目，也许标出30或40种风险。假如为每种风险定义三至七个风险管理环节，则风险管理自身就也许变成一种“项目”！因此，我们将Paret。的8020规则用于软件风险上。经验表明：整个软件风险的80%（即，也许导致项目失败的80%日勺潜在原因）可以由仅仅20%的已标出风险来阐明。初期风险分析环节中所实现的工作可以协助计划者确定哪些风险在所说的这20%中。因此，某些已经标出、评估过及预测过的风险也许并不纳入RMMU计划之中一一它们不属于那关键的20%（具有最高项目优先级的风险）。1 .1安全性风险和危险风险并不仅限于软件项目自身。在软件已经被成功开发并交付给客户之后，仍有也许发生风险。这些风险一般与领域中的软件失败有关。虽然一种良好的系统发生错误H勺概率很小，但在基于计算机的控制及监督系统中未被发现的错误也许会导致巨大的经济损失，或者愈加严重，导致人员伤害或丧失生命。不过，基于计算机的控制及监督系统所产生的成本和功能效益常常超过这种风险。今天，计算机硬件及软件已经大量用于有规律地控制安全性很重要的系统。当软件被用做控制系统的一部分时，复杂性会以数量级增长。由于人的错误所引起的微小的）设计缺陷（这在基于硬件口勺老式控制系统中可以被发现并消除）当使用软件时会变得难以发现。软件安全和危险分析是属于软件质量保证活动（第8章），它重要是来标识和评估也许对软件产生负面影响并使整个系统失败欧!潜在危险。假如可以在软件工程的初期阶段标出危险，则可以指定软件设计特性来消除或控制潜在的危险。1.7RMMM计划风险管理方略可以包括在软件项目计划中，或者风险管理环节也可以组织成一种独立的风险缓和、监控和管理计划（RMMM计划）。RMMM计划将所有风险分析工作文档化，并由项目管理者作为整个项目计划中的一部分来使用。RUMM计划的大纲如下：I.引言1.文档的范围和目日勺2 .重要风险综述3 .责任a.管理者b.技术人员II.项目风险表1 .中断线之上的所有风险的描述2 .影响概率及影响的原因111 .风险缓和、监控和管理n.风险#na.缓和i .一般方略ii .缓和风险的特定环节b.监控i.被监控的原因ii.监控措施C.管理i .意外事件计划ii .特殊的考虑IV .RMMM计划的迭代时间安排表V .总结一旦建立了RMMM计划，且项目开始启动，则风险缓和及监控环节也开始了。正如我们前面讨论过的，风险缓和是一种问题防止活动。风险监控则是一种项目跟踪活动，它有三个重要目的：（1）评估一种被预测的风险与否真正发生了；（2）保证为风险而定义的缓和环节被对的地实行：以及（3）搜集可以用于未来风险分析的信息。在诸多状况下，项目中发生的问题可以追溯到不止种风险,风险监控的另种任务就是试图在整个项目中确定“来源”（什么风险引起了什么问题）。1.8小结当对软件项目期望很高时，一般都会进行风险分析。不过，虽然他们进行这项工作，大多数软件项目管理者都是非正式地和表面上地完毕它。花在标识、分析、和管理风险上的时间可以从多种方面得到回报：愈加平稳的项目进展过程；较高的跟踪和控制项目的能力；由于在问题发生之前已经做了周密计划而产生的I信心。风险分析需要占用大量项目计划的工作量。标识、预测、评估、管理、及监控都要花费时间。但这是值得的!。引用中国2500数年前的兵法家孙子的话：“知己知彼，百战不殆”。对于软件项目管理者而言，这个“彼”指的就是风险。思索题1.1 举出五个其他领域的例子来阐明与被动风险方略有关的I问题。1.2 描述“已知风险”和“可预测风险”之间的差异。1. 3在本章给出H勺所有风险检查表中的条目中增长三个额外的问题或主题。1.4 你被规定建造种软件以支持种低成本的视频编辑系统。该系统将录像带作为输入设备，将视频信息存在磁盘上，并容许顾客对已经数字化的视频信息进行多种编辑。对此类系统做某些调研，然后列出当你开始启动该项目以建造视频编辑系统时，你将面临的技术风险是什么。1.5 你是一家大型软件企业的项目管理者。你被规定领导一种小组开发“下一代”字处理软件（见节的简朴描述）。为该项目建立一种风险表。1. 1描述风险原因和风险驱动因子之间的不同样。1.1 7为项目风险驱动因子建立一种加权方案。1.8 为图1一2中的三个风险建立风险缓和方略及特定的风险缓和活动。1.9 为图1一2中日勺三个风险建立风险监控方略及特定日勺风险监控活动。确认你已经标识出了你需要监控的原因，并确定风险发生的也许性与否在变高或变低。1. 10为图12中的三个风险建立风险管理方略及特定的风险管理活动。1.11 你能否想到一种状况：一种高概率、高影响的风险并不纳入RMMM计划的考虑之中？参照图14所示的风险参照水平值，该曲线与否总是如图显示的那么匀称光滑,或者与否会有该曲线扭曲变形的状况存在？假如有，请举出一种例子。1.13做某些有关软件安全面的研究，并写一份简朴的汇报。可以参照LEV95做为起点。1.14 描述五个软件安全和危险分析是重要关怀对象的软件应用领域。