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