风险管理
引言
风险是关注未来将要发生的事情。今天和昨天已不再被关心，如同我们已经在收获由我们过去的行为所播下的种子。问题是：我们是否能够通过改变我们今天的行为，而为一个不同的、充满希望的、更美好的明天创造机会。其次，这意味着，风险涉及改变，如思想、观念、行为、或地点的改变……第三，风险涉及选择及选择本身所包含的不确定性。因此，就象死亡和税收一样，风险是生活中最不确定的元素之一。
当在软件工程领域考虑风险时，Charette的三个概念定义是显而易见的。未来是我们所关心的——什么样的风险会导致软件项目彻底失败呢？改变也是我们所关心的——用户需求、开发技术、目标计算机、以及所有其他与项目相关的因素的改变将会对按时交付和总体成功产生什么影响呢？最后，我们必须抓住选择机会——我们应该采用什么方法及工具？需要多少人员参与工作？对质量的要求要达到什么程度才是“足够的”？
Peter Drucker［DRU75］曾经说过：“当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了”。在我们能够标识出软件项目中的“真正风险”之前，识别出所有对管理者及开发者而言均为明显的风险是很重要的。
1.1 被动和主动的风险策略
被动风险策略被戏称为“印地安那·琼斯学派的风险管理”［THO92］。印地安那·琼斯在以其名字为影片名的电影中，每当面临无法克服的困难时，总是一成不变地说：“不要担心，我会想出办法来的！”。印地安那·琼斯从不担心任何问题，直到它们发生，再做出英雄式的反应。
遗憾的是，一般的软件项目管理者并不是印地安那·琼斯，且软件项目组的成员也不是他的可信赖的伙伴。大多数软件项目组还是仅仅依赖于被动风险策略。被动策略最多不过是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理它们。更普遍的情况是，软件项目组对于风险不闻不问，直到发生了错误，这时，项目组才赶紧采取行动，试图迅速地纠正错误。这常常被称为“救火模式”。当这样的努力失败后，“危机管理”［CHA92］接管一切，这时项目已经处于真正的危机中了。
对于风险管理的一个更聪明的策略是主动式的。主动策略早在技术工作开始之前就已经启动了。标识出潜在的风险，评估它们出现的概率及产生的影响，且按重要性加以排序，然后，软件项目组建立一个计划来管理风险。主要的目标是预防风险，但因为不是所有的风险都能够预防，所以，项目组必须建立一个意外事件的计划，使其在必要时能够以可控的及有效的方式作出反应。在本章其余部分，我们将讨论风险管理的主动策略。
1.2 软件风险
虽然对于软件风险的严格定义还存在很多争议，但在风险中包含了两个特性这一点上是已达成了共识的［HIG95］：
·不确定性——刻划风险的事件可能发生也可能不发生；即，没有100％发生的风险（100％发生的风险是加在项目上的约束）。
·损失——如果风险变成了现实，就会产生恶性后果或损失。
进行风险分析时，重要的是量化不确定性的程度及与每个风险相关的损失的程度。为了实现这点，必须考虑不同类型的风险。
项目风险威胁到项目计划。也就是说，如果项目风险变成现实，有可能会拖延项目的进度，且增加项目的成本。项目风险是指潜在的预算、进度、人力（工作人员及组织）、资源、客户、及需求等方面的问题以及它们对软件项目的影响。在第5章中，项目复杂性、规模、及结构不确定性也被定义为项目（估算）风险因素。
技术风险威胁到要开发软件的质量及交付时间。如果技术风险变成现实，则开发工作可能变得很困难或根本不可能。技术风险是指潜在的设计、实现、接口、验证、和维护等方面的问题。此外，规约的二义性、技术的不确定性、陈旧的技术、及“先进的”技术也是风险因素。技术风险的发生是因为问题比我们所设想的更加难以解决。
商业风险威胁到要开发软件的生存能力。商业风险常常会危害项目或产品。五个主要的商业风险是：（1）开发了一个没有人真正需要的优秀产品或系统（市场风险）；（2）开发的产品不再符合公司的整体商业策略（策略风险）；（3）建造了一个销售部门不知道如何去卖的产品；（4）由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）；
以及（5）没有得到预算或人力上的保证（预算风险）。应该注意到的很重要的一点是：简单的分类并不总是行得通。某些风险根本无法事先预测。
另一种常用的分类方式是由Charette［CHA89］提出的。已知风险是通过仔细评估项目计划、开发项目的商业及技术环境、以及其他可靠的信息来源（如，不现实的交付时间，没有需求或软件范围的文档、恶劣的开发环境）之后可以发现的那些风险。可预测风险能够从过去项目的经验中推断出来（如，人员调整、与客户之间无法沟通、由于需要进行维护而使开发人员精力分散）。不可预测风险就象纸牌中的大王，它们可能、也会真的出现，但很难事先识别出它们来。
1.3 识别风险
识别风险是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。通过识别已知的和可预测的风险，项目管理者已经迈出了第一步——在可能时避免这些风险，且当必要时控制这些风险。
在1.2节中提出的每一类风险又分为两个不同的类型：一般性风险和特定产品的风险。一般性风险对每一个软件项目而言都是一个潜在的威胁。特定产品的风险只有那些对当前项目的技术、人员、及环境非常了解的人才能识别出来。为了识别特定产品的风险，必须检查项目计划及软件范围说明，并给出以下问题的答案：“本项目中有什么特殊的特性可能会威胁到我们的项目计划？”
一般性风险和特定产品的风险都应该被系统化地标识出来。 Tom Gilb［GIL88］很贴切地表达了这点：“如果你不主动攻击风险，风险就会主动攻击你”。
识别风险的一个方法是建立风险条目检查表。该检查表可以用于识别风险，并使得人们集中来识别下列常见子类型中的已知的及可预测的风险：
·产品规模——与要建造或要修改的软件的总体规模相关的风险。
·商业影响——与管理或市场所加诸的约束相关的风险。
·客户特性——与客户的素质以及开发者和客户定期通信的能力相关的风险。
·过程定义——与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。
·开发环境——与用以建造产品的工具的可用性及质量相关的风险。
·建造的技术——与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险。
·人员数目及经验——与参与工作的软件工程师的总体技术水平及项目经验相关的风险。
风险条目检查表能够以不同的方式来组织。与上述每个话题相关的问题可以由每一个软件项目来回答。这些问题的答案使得计划者能够估算风险产生的影响。我们也可以采用另一个不同的风险条目检查表，它仅仅列出与每一个常见子类型有关的特性。最后，列出一组“风险元素和驱动因子”［AFC88］以及它们发生的概率。关于性能、支持、成本、及进度的驱动因子将在以后讨论。
1.3.1 产品规模风险
有经验的管理者几乎都对下面的陈述没有异议：项目风险是直接与产品规模成正比的。下面的风险检查表中的条目标识了与产品（软件）规模相关的常见风险：
·是否以LOC或FP估算产品的规模？
·对于估算出的产品规模的信任程度如何？
·是否以程序、文件或事务处理的数目来估算产品规模？
·产品规模与以前产品的规模平均值的偏差百分比是多少？
·产品创建或使用的数据库大小如何？
·产品的用户数有多少？
·产品的需求改变多少？交付之前有多少？交付之后有多少？
·复用的软件有多少？
在每一种情况下，待开发产品的信息必须与过去的经验加以比较。如果出现了较大的百分比偏差，或者如果数字相近但过去的结果很不令人满意，则风险较高。
1.3.2商业影响风险
有一个大型软件公司的工程经理在他的墙上挂了一个镜框，上面写着：“上帝给了我头脑使我成为一个优秀的项目管理者，同时每当销售部门设定项目的最后期限时，也让我经历了地狱般的煎熬”。销售部门是受商业驱动的，而商业考虑有时会直接与技术现实发生冲突。下面的风险检查表中的条目标识了与商业影响相关的常见风险：
·本产品对公司的收入有何影响？
·本产品是否得到公司高级管理层的重视？
·交付期限的合理性如何？
·将会使用本产品的用户数及本产品是否与用户的需要相符合？
·本产品必须能与之互操作的其他产品/系统的数目？
·最终用户的水平如何？
·必须产生并交付给用户的产品文档的量与质如何？
·政府对本产品开发的约束？
·延迟交付所造成的成本消耗是多少？
·产品缺陷所造成的成本消耗是多少？
对于待开发产品的每一个回答都必须与过去的经验加以比较。如果出现了较大的百分比偏差，或者如果数字相近但过去的结果很不令人满意，则风险较高。
1.3.3 客户相关的风险
并非所有客户都是一样的。Pressman和Herron［PRE91］在讨论这个话题时曾经说过：
客户有不同的需要。一些人知道他们需要什么；而另一些人知道他们不需要什么。一些客户希望进行详细讨论，而另一些客户则满足于模糊的承诺。
客户有不同的个性。一些人喜欢享受客户的身份——紧张、谈判、一个好产品带来的心理满足；而另一些人则根本不喜欢作为客户。一些人会高兴地接受几乎任何交付的产品，并能充分利用一个不好的产品；而另一些人则会对质量差的产品猛烈抨击。一些人会对质量好的产品表示他们的赞赏；而另一些人则不管怎样都会抱怨不休。
客户和他们的供应商之间也有各种不同的通信方式。一些人非常熟悉产品及生产厂商；而另一些人则可能素未谋面，仅仅通过信件往来和几个匆忙的电话与生产厂商沟通。
客户常常是矛盾的。他们希望昨天的一切工作都是免费的。生产厂商经常陷入客户自己的矛盾之中。
一个“不好的”客户可能会对一个软件项目组能否在预算内按时完成项目产生很大的影响。对于项目管理者而言，不好的客户是对项目计划的巨大威胁和实际的风险。下面的风险检查表中的条目标识了与客户特征相关的常见风险：
·你以前是否曾与这个客户合作过？
·该客户是否很清楚需要什么？他能否花时间把需求写出来？
·该客户是否同意花时间召开正式的需求收集会议（第11章），以确定项目范围？
·该客户是否愿意建立与开发者之间的快速通信渠道？
·该客户是否愿意参加复审工作？
·该客户是否具有该产品领域的技术素养？
·该客户是否愿意让你的人来做他们的工作，即，当你的人在做具体的技术工作时，该客户是否会坚持在旁边监视？
·该客户是否了解软件过程？
如果对于这些问题中的任何一个的答案是否定的，则需要进行进一步的调研，以评估潜在的风险。
1.3.4 过程风险
如果软件过程（第2章）定义得不清楚；如果分析、设计、及测试以无序的方式进行；如果质量是每个人都认为很重要的概念，但没有人切实地采取行动来保证它，那么，这个项目就处于风险之中。以下问题摘自一次由R.S.Pressman ＆ Associates，Inc.［PRE95］建立的对软件工程实践活动进行评估的研讨会。这些问题已经在软件工程研究所（SEI）的过程评估调查表中进行了改编。
过程问题
·你的高级管理层是否支持一份已经写好的政策综述，该综述中强调了软件开发标准过程的重要性吗？
·你的组织是否已经建立了一份已经成文的、用于本项目的软件过程的说明？
·开发人员是否“签约”同意按照文档所写的软件过程进行开发工作，并自愿使用它？
·该软件过程是否可以用于其他项目？
·你的组织是否已经为管理者及技术人员开设了一系列的软件工程培训课程？·是否为每一个软件开发者和管理者都提供了印好的软件工程标准？
·是否为作为软件过程一部分而定义的所有交付物建立了文档概要及示例？
·是否定期地对需求规约、设计和编码进行正式的技术复审？
·是否定期地对测试过程和测试情况进行复审？
·是否对每一次正式技术复审的结果要建立了文档，其中包括发现的错误及使用的资源？
·是否有什么机制来保证软件工程标准确认的方案指导的工作开展正常？·是否使用配置管理来维护系统/软件需求、设计、编码及测试用例之间的一致性？
·是否使用一个机制来控制用户需求的变化及其对软件的影响？
·对于每一个承包出去的子合同，是否有一份文档化的工作说明、一份软件需求规约及一份软件开发计划？
·是否有一个可遵循的规程，来跟踪及复审子合同承包商的工作？
技术问题
·是否使用方便易用的规格说明技术来辅助客户与开发者之间的通信？
·是否使用特定的方法进行软件分析？
·是否使用特定的方法进行数据和体系结构的设计？
·是否百分之90以上的代码都是采用高级语言编写的？
·是否定义及使用特定的规则进行代码编写？
·是否使用特定的方法进行测试用例设计？
·是否使用软件工具来支持计划和跟踪活动？
·是否使用配置管理软件工具来控制和跟踪软件过程中的变化活动？
·是否使用软件工具来支持软件分析和设计过程？
·是否使用工具来创建软件原型？
·是否使用软件工具来支持测试过程？
·是否使用软件工具来支持文档的生成和管理？
·是否收集所有软件项目的质量度量值？
·是否收集所有软件项目的生产率度量值？
如果对于上述问题中大多数的答案是否定的，则软件过程是薄弱的，且风险很高。
1.3.5 技术风险
突破技术的限制是极具挑战性且令人兴奋的，这是几乎每一个技术人员的梦想，因为这迫使开发人员使出他的或她的浑身解数，但这也是很有风险的。Murphy定律似乎对开发工作中的这一部分有了控制，使得我们难以预测风险，更不用说对它们进行计划了。下面的风险检查表中的条目标识了与建造的技术相关的常见风险：
·该技术对于你的组织而言是新的吗？
·客户的需求是否需要创建新的算法或输入、输出技术？
·软件是否需要使用新的或未经证实的硬件接口？
·待开发软件是否需要与开发商提供的未经证实的软件产品接口？
·待开发软件是否需要与其功能及性能均未在本领域中得到证实的数据库系统接口？
·产品的需求中是否要求采用特定的用户界面？
·产品的需求中是否要求开发某些程序构件，这些构件与你的组织以前所开发过的构件完全不同？
·需求中是否要求使用新的分析、设计、或测试方法？
·需求中是否要求使用非传统的软件开发方法，如形式化方法、基于AI的方法、以及人工神经网络？
·需求中是否有过份的对产品的性能约束？
·客户能确定所要求的功能是“可行的”吗？
如果对于这些问题中的任何一个的回答是肯定的，则需要进行进一步的调研，来评估潜在的风险。
1.3.1 开发环境风险
如果一个木匠被要求用弯曲的、钝的手锯制作一件好家具，则最终产品的质量肯定是令人怀疑的。即使是熟练的开发者，不适当的或没有效率的工具也会阻碍工作的进行。软件工程环境支持项目组、过程及产品。但是，如果环境有缺陷，它就可能成为重要的风险源。下面的风险检查表中的条目标识了与开发环境相关的常见风险（第29章讨论了本检查表中所列的工具种类）：
·是否有可用的软件项目管理工具？
·是否有可用的软件过程管理工具？
·是否有可用的分析及设计工具？
·分析及设计工具是否支持适用于待建造产品的方法？
·是否有可用的编译器或代码生成器，且适用于待建造产品？
·是否有可用的测试工具，且适用于待建造产品？
·是否有可用的软件配置管理工具？
·环境是否利用了数据库或仓库？
·是否所有软件工具都是彼此集成的？
·项目组的成员是否已经接受过关干每个工具的培训？
·是否有相关的专家能够回答关于工具的问题？
·工具的联机帮助及文档是否适当？
如果对于上述问题中大多数的回答是否定的，则软件开发环境是薄弱的，且风险很高。
1.3.7 与人员数目及经验相关的风险
Boehm［BOE89］建议了以下问题可用于评估与人员数目及经验相关的风险：
·是否有最优秀的人员可用？
·人员在技术上是否配套？
·是否有足够的人员可用？
·开发人员是否能够自始自终地参加整个项目的工作？
·项目中是否有一些人员只能部分时间工作？
·开发人员对自己的工作是否有正确的期望？
·开发人员是否接受过必要的培训？
·开发人员的流动是否仍能保证工作的连续性？
如果对于这些问题中的任何一个的回答是否定的，则需要进行进一步的调研，以评估潜在的风险。
1.3.8 风险因素和驱动因子
美国空军［AFC88］写了一本小册子，其中包含了如何很好地识别和消除软件风险的指南。
他们所用的方法要求项目管理者标识影响软件风险因素的风险驱动因子，这些因素包括性能、成本、支持和进度。在本讨论中，风险因素是以如下的方式定义的：
·性能风险——产品能够满足需求且符合于其使用目的的不确定的程度。
·成本风险——项目预算能够被维持的不确定的程度。
·支持风险——软件易于纠错、适应及增强的不确定的程度。
·进度风险——项目进度能够被维持且产品能按时交付的不确定的程度。
每一个风险驱动因子对风险因素的影响均可分为四个影响类别——可忽略的、轻微的、严重的及灾难性的。表1－1［BOE89］指出了由于错误而产生的潜在影响（标为1的行）或
没有达到预期的结果所产生的潜在影响（标为2的行）。影响类别的选择是以最符合表中描述的特性为基础的。
1.4 风险预测
风险预测，又称风险估算，试图从两个方面评估每一个风险——风险发生的可能性或概率，以及如果风险发生了，所产生的后果。项目计划者，以及其他管理人员和技术人员，一起执行四个风险预测活动：（1）建立一个尺度，以反映风险发生的可能性；（2）描述风险的后果；（3）估算风险对项目及产品的影响；（4）标注风险预测的整体精确度，以免产生误解。
1.4.1 建立风险表
风险表给项目管理者提供了一种简单的风险预测技术（风险表应该采用电子表格来实现，这样使得表中的内容易于操纵及排序）。风险表的样本如图1－2所示。
项目组一开始要在表中的第一列列出所有风险（不管多么细微）。这可以利用1.3节所述的风险检查表条目来完成。每一个风险在第二列上加以分类（如，PS指产品规模风险，BU指商业风险）。每个风险发生的概率则输入到第三列中。每个风险的概率值可以由项目组成员个别估算，然后将这些单个值求平均，得到一个有代表性的概率值。下一步是评估每个风险所产生的影响。使用表1－1所述的特性评估每个风险因素，并确定其影响的类别。对四个风险因素——性能、支持、成本、及进度——的影响类别求平均可得到一个整体的影响值（如果其中一个风险因素对项目特别重要，也可以使用加权求平均值）。
一旦完成了风险表的前四列内容，就要根据概率及影响来进行排序。高发生概率、高影响的风险放在表的上方，而低概率风险则移到表的下方。这样就完成了第一次风险排序。
项目管理者研究已排序的表，并定义一条中止线。该中止线（表中某一点上的一条水平线）表示：只有那些在线之上的风险才会得到进一步的关注。
而在线之下的风险则需要再评估以完成第二次排序。
风险影响及概率从管理的角度来考虑，是起着不同的作用的（见图1－1）。一个具有高影响但发生概率很低的风险因素不应该花费太多的管理时间。而高影响且发生概率为中到高的风险、以及低影响且高概率的风险，应该首先列入管理考虑之中。
所有在中止线之上的风险都必须进行管理。标有RMMM的列中包含了一个指示器，指向为所有中止线之上的风险所建立的风险缓解、监控、及管理计划（Risk Mitigation，Monitoringand Management Plan）。RMMM计划将在1.5节讨论。
风险概率的确定可以通过先做个别估算而后求出一个有代表性的值来完成。虽然该方法是可行的，不过仍存在很多其他确定风险概率的更加复杂的技术［AFC88］可供使用。风险驱动因子的评估是以一个定性的概率尺度：不可能、不一定、可能和极可能为基础，然后，根据每一个定性值相关的数学概率值（如，概率为0.7到1.0表示极可能发生的风险）来计算的。
1.4.2评估风险影响
如果风险真的发生了所产生的后果有三个因素可能会受影响：风险的性质，范围，及时间。风险的性质是指当风险发生时可能产生的问题。例如，一个定义得很差的与客户硬件的外部接口（技术风险）会妨碍早期的设计及测试，也有可能导致项目后期阶段的系统集成问题。风险的范围结合了严重性（即风险有多严重？）及其整体分布情况（项目中有多少部分受到影响或有多少用户受到损害？）。最后，风险的时间主要考虑何时能够感到风险及持续多长时间。在大多数情况下，项目管理者希望“坏消息”越早出现越好，但在某些情况下，越迟越好。
让我们再回到美国空军提出的风险分析方法上来［AFC88］。以下的步骤被建议用来确定风险的整体影响：
1.确定每个风险元素发生的平均概率。
2.使用表1－1，基于其中列出的标准来确定每个因素的影响。
3.按照前面几节给出的方法完成风险表，并分析其结果。
1.4.1节和1.4.2节所述的风险预测和分析技术可以在软件项目进展过程中迭代使用。项目组应该定期复查风险表，再评估每一个风险，以确定新的情况是否引起其概率及影响发
生改变。这个活动的结果可能需要在表中添加一些新风险，删除一些不再有影响的风险，并改变风险的相对位置。
1.4.3风险评估
在风险管理中的这一步，我们建立了如下形式的一系列三元组［CHA89］：
［ri，li，xi］
其中ri表示风险，li表示风险发生的概率，xi则表示风险产生的影响。在风险评估过程中，我们进一步审查在风险预测阶段所做的估算的精确度，试图为所发现的风险排出优先次序，并开始考虑如何控制和/或避免可能发生的风险。
要使评估发生作用，必须定义一个风险参考水平值［CHA89］。对于大多数软件项目而言，前面所讨论的风险因素——性能、成本、支持、及进度——也代表示了风险参考水平值。即，对于性能下降、成本超支、支持困难、或进度延迟（或者这四种的组合），都有一个水平值的要求，超过它就会导致项目被迫终止。如果风险的组合所产生的问题引起一个或多个参考水平值被超过，则工作将会停止。在软件风险分析中，风险参考水平值存在一个点，称为参考点或临界点，在这个点上决定继续进行该项目或终止它（问题太大了）都是可以接受的。
图1－2以图形方式表示了这种情况。如果风险的组合产生问题而导致成本超支及进度延迟，则会有一个水平值，即图中所示的曲线，当超过它时会引起项目终止（阴影区域）。在临界点上，决定继续进行或终止项目都是可以的。
实际上，参考水平很少能表示成如图所示的一条光滑曲线。在大多数情况下，它是一个区域，其中存在很多不确定性（即，基于参考值的组合进行管理决策常常是不可能的）。
因此，在风险评估过程中，我们执行以下步骤：
1.定义项目的风险参考水平值。
2.建立每一组［ri，li，xi］与每一个参考水平值之间的关系。
3.预测一组临界点以定义项目终止区域，该区域由一条曲线或不确定区域所界定。
4.预测什么样的风险组合会影响参考水平值。
更详细的讨论参见专门探讨风险分析的论著（如文献［CHA89、ROW88］）。
1.5风险缓解、监控和管理
这一步的所有风险分析活动都只有一个目的——辅助项目组建立处理风险的策略。一个有效的策略必须考虑三个问题：
·风险避免。
·风险监控。
·风险管理及意外事件计划。
如果软件项目组对于风险采用主动的方法，则避免永远是最好的策略。这可以通过建立一个风险缓解计划来达到。例如，假设频繁的人员流动被标注为一个项目风险，r0。基于以往的历史及管理经验，人员频繁流动的概率l0被估算为0.7（70％，相当高），而影响x0被预测为对于项目成本及进度有严重的影响（见图1－1）。
为了缓解这个风险，项目管理必须建立一个策略来降低人员流动。可能采取的策略如下：
·与现有人员一起探讨一下人员流动的原因（如，恶劣的工作条件，低报酬，竞争激烈的劳动力市场）。
·在项目开始之前，采取行动以缓解那些在管理控制之下的原因。
·一旦项目启动，假设会发生人员流动并采取一些技术以保证当人员离开时的工作连续性。
·对项目组进行良好组织，使得每一个开发活动的信息能被广泛传播和交流。
·定义文档的标准，并建立相应的机制，以确保文档能被及时建立。
·对所有工作进行详细复审，使得不止一个人熟悉该项工作。
·对于每一个关键的技术人员都指定一个后备人员。
随着项目的进展，风险监控活动开始进行了。项目管理者监控某些因素，这些因素可以提供风险是否正在变高或变低的指示。在人员频繁流动的例子中，应该监控下列因素：
·项目组成员对于项目压力的一般态度。
·项目组的凝聚力。
·项目组成员彼此之间的关系。
·与报酬和利益相关的潜在问题。
·在公司内及公司外工作的可能性。
除了监控上述因素之外，项目管理者还应该监控风险缓解步骤的效力。例如，前述的一个风险缓解步骤中要求定义“文档的标准，并建立相应的机制，以确保文档能被及时建立”。如果有关键的人员离开了项目组，这是一个保证工作连续性的机制。项目管理者应该仔细地监控这些文档，以保证每一个文档内容正确，且当新员工加入该项目时，能为他们提供必要的信息。
风险管理及意外事件计划假设缓解工作已经失败，且风险变成了现实。继续前面的例子，假定项目正在进行之中，有一些人宣布将要离开。如果按照缓解策略行事，则有后备人员可用，因为信息已经文档化，有关知识已经在项目组中广泛进行了交流。此外，项目管理者还可以暂时重新将资源调整到那些人员充足的功能上去（并调整项目进度），从而使得新加入人员能够“赶上进度”。同时，应该要求那些要离开的人员停止工作，并在最后几星期进入“知识交接模式”。这可能包括：基于视频的知识捕获，“注释文档”的建立和/或与仍留在项目组中的成员进行交流。
值得注意的是，RMMM步骤将导致额外的项目开销。例如，花费时间去“备份”每一个关键的技术人员是需要花钱的。因此，风险管理的部分任务是评估何时由RMMM步骤所产生的效益低于实现它们所花费的成本。本质上是讲，项目计划者执行一个典型的成本－效益分析来估算项目的开销变化情况。如果对于频繁人员流动风险的缓解步骤将会增加15％的项目成本及持续时间，而主要的成本因素是“备份后备人员”，则管理者可能决定不执行这一
步骤。另一方面，如果风险缓解步骤仅增加5％的成本及3％的持续时间，则管理者极有可能将这一步骤付诸实现。
对于一个大型项目，可能标出30或40种风险。如果为每种风险定义三至七个风险管理步骤，则风险管理本身就可能变成一个“项目”！因此，我们将Pareto的80—20规则用于软件风险上。经验表明：整个软件风险的80％（即，可能导致项目失败的80％的潜在因素）能够由仅仅20％的已标出风险来说明。早期风险分析步骤中所实现的工作能够帮助计划者确定哪些风险在所说的这20％中。因此，一些已经标出、评估过及预测过的风险可能并不纳入RMMM计划之中——它们不属于那关键的20％（具有最高项目优先级的风险）。
1.1安全性风险和危险
风险并不仅限于软件项目本身。在软件已经被成功开发并交付给客户之后，仍有可能发生风险。这些风险一般与领域中的软件失败相关。
虽然一个良好的系统发生错误的概率很小，但在基于计算机的控制及监督系统中未被发现的错误可能会导致巨大的经济损失，或者更加严重，造成人员伤害或丧失生命。不过，基于计算机的控制及监督系统所产生的成本和功能效益常常超过这种风险。今天，计算机硬件及软件已经大量用于有规律地控制安全性很重要的系统。
当软件被用做控制系统的一部分时，复杂性会以数量级增加。由于人的错误所引起的微小的设计缺陷（这在基于硬件的传统控制系统中能够被发现并消除）当使用软件时会变得难以发现。
软件安全和危险分析是属于软件质量保证活动（第8章），它主要是来标识和评估可能对软件产生负面影响并使整个系统失败的潜在危险。如果能够在软件工程的早期阶段标出危险，则可以指定软件设计特征来消除或控制潜在的危险。
1.7 RMMM计划
风险管理策略可以包含在软件项目计划中，或者风险管理步骤也可以组织成一个独立的风险缓解、监控和管理计划（RMMM计划）。RMMM计划将所有风险分析工作文档化，并由项目管理者作为整个项目计划中的一部分来使用。RMMM计划的大纲如下：
Ⅰ.引言
1.文档的范围和目的
2.主要风险综述
3.责任
a.管理者
b.技术人员
Ⅱ.项目风险表
1.中止线之上的所有风险的描述
2.影响概率及影响的因素
Ⅲ.风险缓解、监控和管理
n.风险＃n
a.缓解
i.一般策略
ii.缓解风险的特定步骤
b.监控
i.被监控的因素
ii.监控方法
c.管理
i.意外事件计划
ii.特殊的考虑
Ⅳ.RMMM计划的迭代时间安排表
Ⅴ.总结
一旦建立了RMMM计划，且项目开始启动，则风险缓解及监控步骤也开始了。正如我们前面讨论过的，风险缓解是一种问题避免活动。风险监控则是一种项目跟踪活动，它有三个主要目的：（1）评估一个被预测的风险是否真正发生了；（2）保证为风险而定义的缓解步骤被正确地实施；以及（3）收集能够用于未来风险分析的信息。在很多情况下，项目中发生的问题可以追溯到不止一个风险，风险监控的另一个任务就是试图在整个项目中确定“起源”（什么风险引起了什么问题）。
1.8小结
当对软件项目期望很高时，一般都会进行风险分析。不过，即使他们进行这项工作，大多数软件项目管理者都是非正式地和表面上地完成它。花在标识、分析、和管理风险上的时间可以从多个方面得到回报：更加平稳的项目进展过程；较高的跟踪和控制项目的能力；由于在问题发生之前已经做了周密计划而产生的信心。
风险分析需要占用大量项目计划的工作量。标识、预测、评估、管理、及监控都要花费时间。但这是值得的。引用中国2500多年前的兵法家孙子的话：“知己知彼，百战不殆”。对于软件项目管理者而言，这个“彼”指的就是风险。
思考题
1.1举出五个其他领域的例子来说明与被动风险策略相关的问题。
1.2描述“已知风险”和“可预测风险”之间的差别。
1.3在本章给出的所有风险检查表中的条目中增加三个额外的问题或主题。
1.4你被要求建造一个软件以支持一个低成本的视频编辑系统。该系统将录像带作为输入设备，将视频信息存在磁盘上，并允许用户对已经数字化的视频信息进行各种编辑。对这类系统做一些调研，然后列出当你开始启动该项目以建造视频编辑系统时，你将面临的技术风险是什么。
1.5你是一家大型软件公司的项目管理者。你被要求领导一个小组开发“下一代”字处理软件（见3.3.2节的简单描述）。为该项目建立一个风险表。
1.1描述风险因素和风险驱动因子之间的不同。
1.7为项目风险驱动因子建立一个加权方案。
1.8为图1－2中的三个风险建立风险缓解策略及特定的风险缓解活动。
1.9为图1－2中的三个风险建立风险监控策略及特定的风险监控活动。确认你已经标识出了你需要监控的因素，并确定风险发生的可能性是否在变高或变低。
1.10为图1—2中的三个风险建立风险管理策略及特定的风险管理活动。
1.11你能否想到一种情况：一个高概率、高影响的风险并不纳入RMMM计划的考虑之中？
1.12参照图1－4所示的风险参考水平值，该曲线是否总是如图显示的那么匀称光滑，或者是否会有该曲线扭曲变形的情况存在？如果有，请举出一个例子。
1.13做一些关于软件安全方面的研究，并写一份简单的报告。可以参考［LEV95］做为起点。
1.14描述五个软件安全和危险分析是主要关心对象的软件应用领域。
_软件开发项目的风险管理 我讲的主题是：软件开发项目的风险治理，因为我认为风险治理在软件项目中专门重要，又不容易做好，因此期望通过和大伙儿讨论能够有一些思路和启发。 期望在那个地点在如下几方面展开讨论： 1．在软件项目治理中如何做好风险防范 2．软件项目中的典型风险事件是哪些 软件开发项目的风险治理 众所周知，软件开发过程可分为：需求分析、设计、编码、测试、安装及爱护等几个过程（在RUP方法中：业务建模、需求、分析设计、实施、测试、部署），实际上一个完整的软件项目前后还有其它过程，在那个地点列出的只是和软件开发有关的核心过程。 软件项目的生命周期能够分为四个时期（不同行业的项目生命周期不同），即初始时期、设计时期、实施时期、收尾时期。软件开发过程在软件项目的这四个时期中的分布情形如下（括弧里面表示RUP方法中的过程）： 初始时期：大部分需求分析，少部分设计（大部分业务建模和需求，少部分分析设计）
设计时期：大部分设计，少部分编码（大部分分析设计，部分实施及测试，开始考虑部署） 实施时期：大部分编码和测试，少部分设计（大部分实施及测试，部分部署） 收尾时期：安装及爱护（大部分部署） 而项目治理则贯穿在整个生命周期的每个时期。 按照PMBOK，项目治理能够从范畴治理、时刻治理、费用治理、质量治理、人力资源治理、沟通治理、风险治理、采购治理和整体治理等9个方面考虑，关于软件项目治理来讲软件配置治理（属于整体治理）、软件质量治理、软件风险治理及开发人员治理（属于人力资源治理）等四个方面的治理尤为重要，软件开发的每个时期、每个过程都要重视这几方面的治理。 下面就以软件项目的风险治理为主题展开讨论。 软件项目治理的四个时期中，在初始时期项目成功的可能性最小，风险发生的概率也就最高，然而这时候一旦估量的风险发生了，缺失是最小的，例如：在那个时期如果某种缘故突然资金来源断了（这在需求时期是专门有可能的），以至于不能连续进行项目，不得不终止项目，那么这时候的缺失只是需求分析时期的投入。随着项目的进展项目成功的可能性变大，风险发生的概率逐步变小，风险对项目的缺失逐步变大，快到收尾时期的时候风
软件项目风险管理 一、风险管理概述 软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。风险关注未来的事情，这意味着，风险涉及选择及选择本身包含的不确定性，在软件开发过程及软件产品都要面临各种决策的选择。风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。另一方面，风险将涉及思想、观念、行为、地点等因素的改变。 当在软件工程领域考虑风险时，我们要关注以下的问题：什么样的风险会导致软件项目的彻底失败？用户需求、开发技术、目标计算机、以及所有其它与项目有关的因素的改变将会对按时交付和总体成功产生什么影响？对于采用什么方法和工具，需要多少人员参与工作的问题，我们如何选择和决策？对软件质量要达到什么程度才是“足够的”？ 当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了。在我们能够标识出软件项目中的真正风险之前，识别出所有对管理者和开发者而言均为明显得风险是很重要的。 二、被动和主动的风险策略 被动风险策略是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理它们，更普遍的是，软件项目组对风险不闻不问，直到发生了错误才赶紧采取行动，试图迅速地纠正错误。这种管理模式常常被称为“救火模式”。当补救的努力失败后，项目就处在真正的危机之中了。 对于风险管理的一个更聪明的策略是主动式的。主动策略早在技术工作开始之前就已经启动了――标识出潜在地风险，评估它们出现的概率及产生的影响，对风险按重要性进行排序，然后，软件项目组建立一个计划来管理风险。主动策略风险管理的主要目标是预防风险。但是，因为不是所有的风险都能够预防，所以，项目组必须建立一个应付意外事件的计划，使其在必要时能够以可控的及有效的方式作出反应。 三、软件风险 1、软件风险包含两个特征： 不确定性——刻划风险的事件可能发生也可能不发生，没有100％发生的风险。 损失——如果风险变成了现实，就会产生恶性后果或损失。 2、进行风险分析时，重要的是量化不确定的程度和与每个风险相关的损失的程度。 为了实现这点，必须考虑以下几种不同类型的风险：
软件项目的风险分析 软件工程项目的开发也存在各种各样的风险，有些风险甚至是灾难性的。R.Charette认为，风险与将要发生的事情有关，它涉及诸如思想、观念、行为、地点、时间等多种因素；风险随条件的变化而改变，人们改变、选择、控制与风险密切相关的条件可以减少风险，但改变、选择、控制条件的策略往往是不确定的。在软件开发过程中，人们关心的问题是，什么风险会导致软件项目的彻底失败？顾客需求、开发环境、目标机、时间、成本的改变对软件项目的风险会产生什么影响？人们必须抓住什么机会、采取什么措施才能有效地减少风险、顺利完成任务？所有这些问题都是软件开发过程中不可避免并需要妥善处理的。软件工程的风险分析包括：风险标识、风险估算、风险评价和风险管理四部分 1、风险标识 从宏观上看，风险可以分为项目风险、技术风险和商业风险三类。由于项目在预算、进度、人力、资源、顾客和需求等方面的原因对软件项目产生的不良影响称为项目风险。软件在设计、实现、接口、验证和维护过程中可能发生的潜在问题，如规格说明的二义性、采用陈旧或尚不成熟的技术等等，对软件项目带来的危害称技术风险。开发了一个没人需要的优质软件，或推销部门不知如何销售这一软件产品，或开发的产品不符合公司的产品销售战略，等等，称为商业
风险。这些风险有些是可以预料的，有些是很难预料的。为了帮助项目管理人员、项目规划人员全面了解软件开发过程存在的风险，Boehm建议设计并使用各类风险检测表标识各种风险。 2、风险估算 软件项目管理人员可以从影响风险的因素和风险发生后带来的损失两方面来度量风险。为了对各种风险进行估算，必须建立风险度量指标体系；必须指明各种风险带来的后果和损失；必须估算风险对软件项目及软件产品的影响；必须给出风险估算的定量结果。 3、风险评价和管理 在风险分析过程中，经常使用三元组[RI,LI,XI]描述风险。其中RI代表风险，LI表示风险发生的概率，XI是风险带来的影响，I = 1，2，…L是风险序号，表示软件项目共有L种风险。软件开发过程中，由于项目超支、进度拖延和软件性能下降都会导致软件项目的终止，因此多数软件项目的风险分析都需要给出成本、进度和性能三种典型的风险参考量。当软件项目的风险参考量达到或超过某一临界点时，软件项目将被迫终止。在软件开发过程中，成本、进度、性能是相互关联的。例如，项目投入成本的增长应与进度相匹配，当项目投入的成本与项目拖延的时间超过某一临界点时，项目也应该终止进行。通常风险估算过程可分为
软件开发项目的风险管理 我讲的主题是：软件开发项目的风险管理，因为我认为风险管理在软件项目中很重要，又不容易做好，所以希望通过和大家讨论能够有一些思路和启发。 希望在这里在如下几方面展开讨论： 1．在软件项目管理中如何做好风险防范 2．软件项目中的典型风险事件是哪些 软件开发项目的风险管理 众所周知，软件开发过程可分为：需求分析、设计、编码、测试、安装及维护等几个过程（在RUP方法中：业务建模、需求、分析设计、实施、测试、部署），实际上一个完整的软件项目前后还有其它过程，在这里列出的只是和软件开发相关的核心过程。软件项目的生命周期可以分为四个阶段（不同行业的项目生命周期不同），即初始阶段、设计阶段、实施阶段、收尾阶段。软件开发过程在软件项目的这四个阶段中的分布情况如下（括弧里面表示RUP方法中的过程）： 初始阶段：大部分需求分析，少部分设计（大部分业务建模和需求，少部分分析设计） 设计阶段：大部分设计，少部分编码（大部分分析设计，部分实
施及测试，开始考虑部署） 实施阶段：大部分编码和测试，少部分设计（大部分实施及测试，部分部署） 收尾阶段：安装及维护（大部分部署） 而项目管理则贯穿在整个生命周期的每个阶段。 根据PMBOK，项目管理可以从范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理等9个方面考虑，对于软件项目管理来讲软件配置管理（属于整体管理）、软件质量管理、软件风险管理及开发人员管理（属于人力资源管理）等四个方面的管理尤为重要，软件开发的每个阶段、每个过程都要重视这几方面的管理。 下面就以软件项目的风险管理为主题展开讨论。 软件项目管理的四个阶段中，在初始阶段项目成功的可能性最小，风险发生的概率也就最高，但是这时候一旦预计的风险发生了，损失是最小的，比如：在这个阶段如果某种原因突然资金来源断了（这在需求阶段是很有可能的），以至于不能继续进行项目，不得不终止项目，那么这时候的损失只是需求分析阶段的投入。随着项目的进展项目成功的可能性变大，风险发生的概率逐渐变小，风险对项目的损失逐渐变大，快到收尾阶段的时候风险对项目的损失最大，随着收尾阶段的进行风险又逐渐变小。
浅析软件项目管理中的风险管理 张尧 摘要：在项目的建设过程中，风险几乎无处不在。如何有效地分析、控制和管理风险，对项目的成功起着至关重要的影响。本文通过对当前软件项目的风险状况进行分析，列举软件开发项目的风险来源，并进行分析，最后给出如何合理管理软件项目风险的建议。 关键词：风险管理；Boehm模型；CMU/SEI模型 0.引言 软件行业是二十一世纪发展较快的行业，同时基于软件项目具有连续性、复杂性、少参照性和无标准规范等特点，该项目的开发过程总会遇到各种各样的风险。鉴于这种情况，我们提出软件项目的风险管理，其管理内容包括风险识别、风险量化、风险对策和风险控制等，当然，还有一系列的管理模型，比如：Boehm 模型、 CMU/SEI模型。做这些，目的只有一个，那就是：使软件项目的潜在机会或回报最大化，使其潜在风险最小化。 1.风险管理概述 每一个项目的完成，都是克服各种困难的结果，困难来于人、财、物。仔细观察不难发现，整个困难过程狭义的说就是各种风险的集合，风险无处不在，我们所要做和能做的便是采取一定的方式方法对风险进行管理，使事件能顺利朝我们的目标发展。软件中的项目风险管理是指为了最好的达到项目的目标，识别、分配、应对项目生命周期内风险的科学与艺术 1.1. 风险的来源 风险来于国家制度。一切工作都在按计划顺利的进行着，突然国家实施宏观调控，物价上涨，工人要求加工资，或者国家发布声明，这款软件不能研发，我们的软件项目要么不能按时完成，要么直接得从做，风险由此产生。 风险来于项目实施过程。软件项目具有一般项目的特点，那就是需要人力、物力的投入，还有就是自然环境的参与。整个过程，每一环境产生与目标相悖的行为，这对项目都会产生不可预知的挫折，风险由此产生。 风险来于我们的用户，工程都是按计划顺利完成的，可到和最终用户交接的时候，用户临时提出修改意见，顾客是上帝，在这个竞争尤为激励的年代，我们只能选择满足用户，风险由此产生。 1.2. 风险的分类
软件项目风险管理 1 前言 一般来说，软件工程师总是非常乐观。当他们在计划软件项目时，经常认为每件事情都会像计划那样运行，或者，又会走向另外一个极端。软件开发的创造性本质意味着我们不能完全预测会发生的事情，因此制定一个详细计划的关键点很难确定。当有预想不到的事情引起项目脱离正常轨道时，以上两种观点都会导致软件项目的失败。 目前，风险管理被认为是IT软件项目中减少失败的一种重要手段。当不能很确定地预测将来事情的时候，可以采用结构化风险管理来发现计划中的缺陷，并且采取行动来减少潜在问题发生的可能性和影响。风险管理意味着危机还没有发生之前就对它进行处理。这就提高了项目成功的机会和减少了不可避免风险所产生的后果。 2 什么是风险 所谓“风险”，归纳起来主要有两种意见，主观说认为，风险是损失的不确定性；客观学认为，风险是给定情况下一定时期可能发生的各种结果间的差异。它的两个基本特征是不确定性和损失。IT行业中的软件项目开发是一项可能损失的活动，不管开发过程如何进行都有可能超出预算或时间延迟。项目开发的方式很少能保证开发工作一定成功，都要冒一定的风险，也就需要进行项目风险分析。在进行项目风险分析时，重要的是要量化不确定的程度和每个风险相当的损失程度，为实现这一点就必须要考虑以下问题： 要考虑未来，什么样的风险会导致软件项目失败？ 要考虑变化，在用户需求、开发技术、目标、机制及其它与项目有关的因素的改变将会对按时交付和系统成功产生什么影响？ 必须解决选择问题，应采用什么方法和工具，应配备多少人力，在质量上强调到什么程度才满足要求？ 要考虑风险类型，是属于项目风险、技术风险、商业风险、管理风险还是预算风险等？ 这些潜在的问题可能会对软件项目的计划、成本、技术、产品的质量及团队的士气都有负面的影响。风险管理就是在这些潜在的问题对项目造成破坏之前识别、处理和排除。 3 风险管理 项目风险管理实际上就是贯穿在项目开发过程中的一系列管理步骤，其中包括风险识别、风险估计、风险管理策略、风险解决和风险监控。它能让风险管理者主动“攻击”风险，进行有效的风险管理。 在项目管理中，建立风险管理策略和在项目的生命周期中不断控制风险是非常重要的，风险管理包括四个相关阶段： 风险识别识别风险的方法常用的有风险识别问询法（座谈法、专家法）、财务报表法、流程图法、现场观察法、相关部门配合法和环境分析法等。
参加过项目制作的人都知道一个项目开发过程中会遇到许多困难，很多事情都会 影响一个软件开发的失败风险是在项目中发生的一系列事件或不利结果的可能性。软 件开发是一项高风险的活动，在项目开发过程的任何一个阶段都可能存在风险。采取积 极的风险管理方式，可以使项目进程更加平稳，可以获得很高的跟踪和控制项目的能力，可以规避、转移风险，或缓解风险带来的不利影响。风险管理是对项目风险进行识别、 分析、应对和监控的过程，是项目管理中很重要的管理活动，有效的实施软件风险管理 是软件项目开发工作顺利完成的保证。风险管理的达成必须包括三个要素：首先，在项 目开发计划中必须制定风险管理计划；第二，在项目预算中必须包含解决风险所需的经费；第三，评估风险时，风险的影响也必须纳入项目计划中。 下面就软件开发过程中经常发生的风险， 2.需求不明确 需求不明确是软件开发过程中经常可能遇到的问题，这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发 过程的生命周期各阶段中，需求不明确所造成的浪费是最大的，必须尽早尽可能解决。 确定用户需求是件非常困难的事情，我们常常从以下几个方面着手处理需求不明确问题：(1) 让用户参与开发 提供一个协作开发环境，让用户参与开发过程。如果条件不允许，至少应该在每次迭代 的需求分析和系统测试阶段，让客户能够参与开发。 在选择参与开发过程的用户时，一方面，要尽可能争取精通业务或计算机技术的用户参与。另一方面，如果开发的产品要在不同规模、不同类型的企业应用，应该选择具有代 表性的用户参与。 仅仅让用户参与是不够的，应该采取一定的激励措施，提高用户参与的积极性。 (2) 开发用户界面原型 用户通常不善于精确描述自己的业务需求，系统分析员需要借助白板、白纸等沟通方式，帮助用户清楚表述需求。然后，开发一个用户界面原型，以便用户确认需求。用户界面
风险管理计划 1. 引言 1.1 本文件的范围和目的 项目风险管理描述了在整个项目生命周期内项目团队如何组织和开展项目风险识别，度量，应对和监控等项目管理活动，是一份指导项目团队进行项目风险管理的纲领性文件。项目风险管理的目标在于提高项目中积极事件的概率和影响，降低项目中消极事件的概率和影响，确保项目在可控的范围内完成项目目标。 1.2 概述 1.2.1 目标 提高项目中积极事件的概率和影响，降低项目中消极事件的概率和影响，确保项目在可控的范围内完成项目目标。当不能很确定地预测将来事情的时候，可以采用结构化风险管理来发现计划中的缺陷，并且采取行动来减少潜在问题发生的可能性和影响。风险管理意味着危机还没有发生之前就对它进行处理，这就提高了项目成功的机会并减少了不可避免风险所产生的后果。 1.2.2 需要优先考虑规避的风险 （1）业务风险产品规模风险，商业风险，项目需求风险，客户特性风险，过程风险
(2)技术风险 技术情况风险，开发环境风险 (3)组织风险 人员数目及其经验风险 1.3组织 1.3.1领导成员 蒋妍，范楚楚，宋蕊蕊，谭琳琳，杨欣颖，赵术洁 1.3.2责任 1.4风险规避策略的内容说明 1.4.1进度安排 1.4.2 主要里程碑和审查行动（1）项目风险分析通过项目风险分析
对项目进行宏观控制，作出风险发生的概率及时作出规避策略，降低项目成本。 （2）项目风险应对对于出现的不确定风险应及时做出应对措施，提出风险规避备选方案及建议方案，降低项目的失败性。 1.4.3 预算 风险情况调查所需花费预算成本 风险类别风险调查预算 需求风险客户特性风险调查问卷 市场调研 1000 1000需求变动5000 过程风险软件工程培训3000评审结果后续5000 技术风险技术变动5000 开发环境风险开发工具变动1000 人员数目及经验风险人员管理5000 2 风险识别 2.1 风险情况调查，风险来源 收集资料 项目产品或服务说明书，项目的前提，假设和制约因素，本项目可与类比的项目。
软件开发项目的风险分析与控制 摘要：本文通过对当前软件行业的风险状况进行分析，列举软件开发项目的风险来源，并进行分析，总结各类风险产生的原因和对项目成败的影响，最后给出软件开发项目在风险管理和控制的建议。 关键词：软件开发风险风险分析风险管理与控制 一、软件开发项目的风险背景 信息产业的发展是目前发展最快的行业之一，也是对社会影响最大的一个行业，它不但为我们创造了巨大的财富，而且从各个方面改变着我们的生活，达到一个行业，小到一项服务。我们不得不承认软件是二十一世纪最不可思议的产品。 伴随着软件开发技术的不断更新、软件数量的增多、软件复杂程度不断加大、客户对产品的要求也在不断的提高，随之而来的是软件开发项目给软件开发企业和需求企业带来的巨大风险。软件开发项目的成功与否会直接影响到公司的生存。这对软件开发企业来讲应该是更大的难题。一方面是业务需求更加复杂。人们对软件质量和用途的期望大幅度提高，对业务系统的要求也越来越挑剔。另一方面是开发成本不断缩减。在此形势下，风险管理与控制已成为软件开发项目成败的关键。 软件开发项目由于其具有连续性、复杂性、少参照性，无标准规范等特点，其风险程度较高。目前国内的大多数软件开发企业还缺乏对软件开发项目的风险认识，缺少进行系统、有效的度量和评价的手段。据有调查数据显示，有15—35%的软件项目中途被取消，剩下的项目不是超期就是超出预算或是无法达到预期目标。另外，软件项目因风险控制和管理原因失败的约占90% ，可见，软件风险控制与管理在目前的软件开发项目中的重要性。 二、软件开发项目的风险来源及对项目成败的影响 软件开发项目风险是指在软件生命周期中所遇到的所有的预算、进度和控制等各方面的问题，以及由这些问题而产生的对软件项目的影响。软件项目风险经常会涉及许多方面，如：缺乏用户的参与，缺少高级管理层的支持，含糊的要求，没有计划和管理等，总体概括下来应该由五大方面。
-------------------------------------------------------------------------------------------------------------------------------------------- 软件开发项目的风险管理 原作者:李艺兰 1月27日参加了项目管理联盟组织的‘北京项目管理爱好者聚会’，我被易风邀请做了一个主题演讲，其实不是什么演讲，只是结合理论谈了自己的一些想法和工作中遇到过的经验教训，更主要的目的是给大家出一个讨论和交流的主题，希望能起个抛砖引玉的作用。 我讲的主题是：软件开发项目的风险管理，因为我认为风险管理在软件项目中很重要，又不容易做好，所以希望通过和大家讨论能够有一些思路和启发。 现在把我准备的内容整理帖出来，希望在这里继续讨论，大家在如下几方面多展开讨论：1．在软件项目管理中如何做好风险防范 2．软件项目中的典型风险事件是哪些 软件开发项目的风险管理 众所周知，软件开发过程可分为：需求分析、设计、编码、测试、安装及维护等几个过程（在RUP方法中：业务建模、需求、分析设计、实施、测试、部署），实际上一个完整的软件项目前后还有其它过程，在这里列出的只是和软件开发相关的核心过程。 软件项目的生命周期可以分为四个阶段（不同行业的项目生命周期不同），即初始阶段、设计阶段、实施阶段、收尾阶段。软件开发过程在软件项目的这四个阶段中的分布情况如下（括弧里面表示RUP方法中的过程）： 初始阶段：大部分需求分析，少部分设计（大部分业务建模和需求，少部分分析设计） 设计阶段：大部分设计，少部分编码（大部分分析设计，部分实施及测试，开始考虑部署）实施阶段：大部分编码和测试，少部分设计（大部分实施及测试，部分部署） 收尾阶段：安装及维护（大部分部署） 而项目管理则贯穿在整个生命周期的每个阶段。 根据PMBOK，项目管理可以从范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理等9个方面考虑，对于软件项目管理来讲软件配置管理（属于整体管理）、软件质量管理、软件风险管理及开发人员管理（属于人力资源管理）等四个方面的管理尤为重要，软件开发的每个阶段、每个过程都要重视这几方面的管理。下面就以软件项目的风险管理为主题展开讨论。 ---------------------------------------------------------精品文档---------------------------------------------------------------------
推介导读： 此论文从需求调研、开发、实施以及项目收尾四个项目阶段，列举了11种典型的常见风险，并给出了这些风险的详细和切实可行的风险规避措施。这些风险和措施实用、实在，值得做为公司项目管理财富库进行收藏，值得各项目组借鉴。 软件项目风险管控 1.什么是软件项目风险 软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对软件项目的影响。软件项目风险会影响项目计划的实现，如果项目风险变成现实，就有可能影响项目的进度，增加项目的成本，甚至使软件项目目标不能实现。如果对项目进行风险管理，就可以最大限度的减少风险的发生。 2.项目风险及应对措施 软件项目的生命周期可以分为四个阶段，即需求调研阶段、开发阶段、实施阶段、收尾阶段，软件开发过程可分为：需求分析、设计、编码、测试等几个过程，在软件项目的每个阶段、每个过程都可能存在风险。下面结合项目谈谈各阶段碰到的风险。 2.1.需求调研阶段 1．风险描述： 调研涉众没有足够的时间参与调研活动，严重影响调研进度与调研质量。 应对措施： 开始调研时，召集公司的高层领导、各部门主管及参与调研的关键涉众召开调研 启动会，让所有涉众都重视本次调研活动，努力配合调研工作。在调研启动会上 明确调研涉众的职责； 在制定调研计划时，应事前与相关涉众做好沟通工作，努力减少调研计划与日常 工作安排的冲突； 相关人员通过移交日常工作等办法，有效保证相关涉众的调研时间； 调研人员设计调研提纲时，要有针对性，尽量努力提高调研效率。 2．风险描述： 调研成果不能真实和完整地体现管理层意图与企业经营管理需要。 应对措施： 通过客户方的多方协调，让管理层要重视调研人员的访谈，客观而真实地回答访 谈问题； 管理层调研提纲在设计时，不仅要做到有针对性，而且要有全面性； 调研人员在访谈管理层，要善于挖掘与总结管理层的管理意图与经营思路； 管理层的意图应宣达到所有涉众，努力做到在繁多的需求中，把握住管理思路的 主线。
软件开发项目的风险管 理 文件编码（008-TTIG-UTITD-GKBTT-PUUTI-WYTUI-8256）
软件开发项目的风险管理 我讲的主题是：软件开发项目的风险管理，因为我认为风险管理在软件项目中很重要，又不容易做好，所以希望通过和大家讨论能够有一些思路和启发。 希望在这里在如下几方面展开讨论： 1．在软件项目管理中如何做好风险防范 2．软件项目中的典型风险事件是哪些 软件开发项目的风险管理 众所周知，软件开发过程可分为：需求分析、设计、编码、测试、安装及维护等几个过程（在RUP方法中：业务建模、需求、分析设计、实施、测试、部署），实际上一个完整的软件项目前后还有其它过程，在这里列出的只是和软件开发相关的核心过程。 软件项目的生命周期可以分为四个阶段（不同行业的项目生命周期不同），即初始阶段、设计阶段、实施阶段、收尾阶段。软件开发过程在软件项目的这四个阶段中的分布情况如下（括弧里面表示RUP方法中的过程）： 初始阶段：大部分需求分析，少部分设计（大部分业务建模和需求，少部分分析设计） 设计阶段：大部分设计，少部分编码（大部分分析设计，部分实施及测试，开始考虑部署） 实施阶段：大部分编码和测试，少部分设计（大部分实施及测试，部分部署） 收尾阶段：安装及维护（大部分部署） 而项目管理则贯穿在整个生命周期的每个阶段。 根据PMBOK，项目管理可以从范围管理、时间管理、费用管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理等9个方面考虑，对于软件项目管理来讲软件配置管理（属于整体管理）、软件质量管理、软件风险管理及开发人员管理（属于人力资源管理）等四个方面的管理尤为重要，软件开发的每个阶段、每个过程都要重视这几方面的管理。 下面就以软件项目的风险管理为主题展开讨论。 软件项目管理的四个阶段中，在初始阶段项目成功的可能性最小，风险发生的概
软件项目风险管理研究 [内容摘要]随着软件产业的迅速发展，软件的规模越来越大，复杂性也越来越高，风险变得更加难以控制，最终导致软件项目失败的结果越来越常见。如何对软件项目风险因素进行分析并有效地规避风险，从而致使项目顺利成功是进行软件风险管理的主要课题之一。只有充分地理解和学习软件风险管理的理论知识，同时在实践中不断地积累经验才能有效地进行风险防X和控制，达到减少风险的影响程度和实现利益最大化追求的目的。 本文从分析国内外软件风险管理的发展现状入手，详细地按照软件生命周期各阶段将软件项目风险进行分类，并总结对比分析了国外经典软件风险管理模型，同时介绍了软件风险管理全过程，同时基于经典软件风险管理模型，提出了改进的软件风险管理模型和方法，并根据自身经验对如今国内企业提出软件风险管理一些建议和意见。 [关键词]项目管理；软件风险；风险管理
1.研究背景 随着经济全球化的不断深入，以信息技术为依托的知识经济初见端倪，各国都在实施信息化带动工业化的发展战略，软件行业成为许多国家的支柱产业，软件业的发展程度从某种意义上体现了该国的综合国力，决定着国家未来的国际竞争地位。软件是一种特殊的逻辑产品，不具备实体的可见性，它是人经过智力劳动而产生出来、具有特殊性质的复杂事物川。一些调查表明，约的软件项目开发超出估计时间，大型项目平均超出交付时间，以上的软件项目开发费用超出预算。软件项目成功的几率要远远低于其它任何工程项目，软件行业面临着所谓的“软件危机”。在软件产品开发过程中存在着众多不确定因素，这些因素使得软件项目比其它工程项目具有更高的风险。从学科发展角度来看，软件工程的形成得益于人们用工程化思想看待软件产品的开发，软件工程的产生又使得软件项目管理学科应运而生。软件项目管理的出现使所谓的“软件危机”得到了一定程度的缓解和控制。 项目管理的目标是在有限资源标注条件下，保证项目时间进度、质量、成本达到最优化。软件项目管理的主要目标是确保软件产品能够按预期方案交付，同时还要满足用户需求。软件项目风险管理的目的是要找出导致项目需求不明晰、不能按进度计划及时交付、产品质量存在缺陷、开发费用超支等各种不良后果的风险因素，对风险因素及可能造成的后果和危害进行定性和定量分析，从而为软件项目管理人员等提供有效的风险控制方案和措施，使其对软件项目的损失或影响降到最低程度或使决策者可以接受的程度。因此，软件项目风险管
风险管理 引言 风险是关注未来将要发生的事情。今天和昨天已不再被关心，如同我们已经在收获由我们过去的行为所播下的种子。问题是：我们是否能够通过改变我们今天的行为，而为一个不同的、充满希望的、更美好的明天创造机会。其次，这意味着，风险涉及改变，如思想、观念、行为、或地点的改变……第三，风险涉及选择及选择本身所包含的不确定性。因此，就象死亡和税收一样，风险是生活中最不确定的元素之一。 当在软件工程领域考虑风险时，Charette的三个概念定义是显而易见的。未来是我们所关心的——什么样的风险会导致软件项目彻底失败呢？改变也是我们所关心的——用户需求、开发技术、目标计算机、以及所有其他与项目相关的因素的改变将会对按时交付和总体成功产生什么影响呢？最后，我们必须抓住选择机会——我们应该采用什么方法及工具？需要多少人员参与工作？对质量的要求要达到什么程度才是“足够的”？ Peter Drucker［DRU75］曾经说过：“当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了”。在我们能够标识出软件项目中的“真正风险”之前，识别出所有对管理者及开发者而言均为明显的风险是很重要的。 1.1 被动和主动的风险策略 被动风险策略被戏称为“印地安那·琼斯学派的风险管理”［THO92］。印地安那·琼斯在以其名字为影片名的电影中，每当面临无法克服的困难时，总是一成不变地说：“不要担心，我会想出办法来的！”。印地安那·琼斯从不担心任何问题，直到它们发生，再做出英雄式的反应。 遗憾的是，一般的软件项目管理者并不是印地安那·琼斯，且软件项目组的成员也不是他的可信赖的伙伴。大多数软件项目组还是仅仅依赖于被动风险策略。被动策略最多不过是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理它们。更普遍的情况是，软件项目组对于风险不闻不问，直到发生了错误，这时，项目组才赶紧采取行动，试图迅速地纠正错误。这常常被称为“救火模式”。当这样的努力失败后，“危机管理”［CHA92］接管一切，这时项目已经处于真正的危机中了。
软件项目风险管理 摘要：软件项目风险管理从原先被人忽视到目前的热捧，人们也从原来对它毫无作用到现在对软件的编译成功起着不容忽视的作用。为了防止骚扰软件项目以及调试的过程和产品制定的一系列规则，同时也是对软件项目、调试过程和产品有影响的风险进行评估和控制的过程。随着软件业的兴起，对软件项目风险管理研究的人也越来越多，因此关于这方面的理论也层出不穷，因此本文根据软件项目风险管理的相关理论，建立了本论文研究思路。 关键词：软件风险；风险管理；风险识别；风险分析；风险跟踪 1 风险管理的背景 1.1 风险的定义 风险定义有好几种，一是不希望事物发生变化，二是事物存在很多的，三是事件产生的影响。可以概括为“人们因对未来行为的决策及客观条件的不确定性而可能引起的后果与预定目标发生多种负偏离的综合。”公式表现为：风险f（事件，不确定性，后果）。用数学表达式则为：R=f（s，P，X），其中R表示风险，S表示时间，P表示不利事件发生的概率，X表示该事件发生的后果。 1.2 风险管理的背景 随着社会对软甲的需求增大，软件的开发技术不断更新，难度不断增大，但软件的数量却依然增加很多，同时随着社会节奏加快，软
件的供应商需要提供不间断的软件更新服务。但与此同时，各种难度的上升，给企业在开发软件的过程中加大了风险。软件项目能否开发成功，关系着一个企业的生死存亡。但矛盾的是，随着开发软件的业务增大，但对软件的质量和用途也随之提高，这对软件开发商造成了巨大的压力，在这种情况下，软件风险管理和控制成为软件开发成败的关键点。 根据有关资料调查显示，有百分之十五到百分之三十五的软件项目在开发的过程中被取消，剩下的软件项目有的是没有在预期内完成而夭折，或者又是软件开发的过程中超出了经费的预算。除此之外还有软件项目因为风险管理和控制失败的大约占百分之九十。目前国内的大多数软件开发企业还缺乏对软件开发项目的风险认识，缺少进行系统、有效的度量和评价的手段。所以能建立有效的风险识别、风险分析、风险计划、风险跟踪和风险对策的机制，是有效提高软件开发成功率的方法之一。 2 风险管理的内容 为了最大化的减少软件风险的发生，可对软件项目进行风险管理。而软件项目风险管理过程是指软件风险从认识到采取措施的过程包括风险识别、风险分析、风险计划、风险跟踪和风险对策等，从而将可控因素最大化，将不可控因素到最小，从而对未知的风险消灭，从而对风险进行回避或者缓解。 2.1 风险识别 风险识别的常用方法通常有现场观察法，财务报表法、环境分析
参与过大型软件项目的人都会认识到许多事情都可能出错，一但出错就可能给项目带来危害、损失或其它不利影响。风险是在项目中发生的一系列事件或不利结果的可能性。软件开发是一项高风险的活动，在项目开发过程的任何一个阶段都可能存在风险。采取积极的风险管理方式，可以使项目进程更加平稳，可以获得很高的跟踪和控制项目的能力，可以规避、转移风险，或缓解风险带来的不利影响。风险管理是对项目风险进行识别、分析、应对和监控的过程，是项目管理中很重要的管理活动，有效的实施软件风险管理是软件项目开发工作顺利完成的保证。 风险管理的达成必须包括三个要素：首先，在项目开发计划中必须制定风险管理计划；第二，在项目预算中必须包含解决风险所需的经费；第三，评估风险时，风险的影响也必须纳入项目计划中。 下面就软件开发过程中经常发生的风险，谈谈我们采取的预防措施。 2.需求不明确 需求不明确是软件开发过程中经常可能遇到的问题，这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发过程的生命周期各阶段中，需求不明确所造成的浪费是最大的，必须尽早尽可能解决。确定用户需求是件非常困难的事情，我们常常从以下几个方面着手处理需求不明确问题： (1) 让用户参与开发 提供一个协作开发环境，让用户参与开发过程。如果条件不允许，至少应该在每次迭代的需求分析和系统测试阶段，让客户能够参与开发。
在选择参与开发过程的用户时，一方面，要尽可能争取精通业务或计算机技术的用户参与。另一方面，如果开发的产品要在不同规模、不同类型的企业应用，应该选择具有代表性的用户参与。 仅仅让用户参与是不够的，应该采取一定的激励措施，提高用户参与的积极性。 (2) 开发用户界面原型 用户通常不善于精确描述自己的业务需求，系统分析员需要借助白板、白纸等沟通方式，帮助用户清楚表述需求。然后，开发一个用户界面原型，以便用户确认需求。用户界面原型的作用仅仅是收集用户需求，不应该再作它用，也不要给用户造成系统快要实现的错觉。 (3) 需求讨论会议 对于用户分布广、用户量大的项目，要全面收集用户需求，往往很困难，通常采取需求研计会议方式进行需求确认。通过在会议前几周调查各地、各部门用户需求意见，然后集中各地或各部门的用户代表，举办一次需求研讨会，通过会议方式收集需求。本方法适合于具有一定信息系统使用经验的用户。 (4) 强化需求分析与评审 首先，需求分析是项目成功的基础，需要引起足够的重视，并分配充足的时间和人力，要让有经验的系统分析员负责，切忌让项目新手或程序员负责。其次，要进行需求评审，尽可能让用户参与需求评审，不要让需求评审流于行式。第三，也是最重要的一点，通过评审的需求规格说明书，要让用户方签字，并作为项目合同的附件，对双方都具有约束力。在公司内部要将
论软件项目的风险管理 摘要 2008年2月，我作为项目经理开始参与《热轧厂MES管理系统》项目的开发工作，主要工作职责是项目的先期需求分析、系统设计和项目管理。 在本项目的成功很大程度上归功于对项目的风险管理，在该项目中成功的控制进度风险；控制人员流失风险；控制系统功能风险，为《热轧厂MES管理系统》成功上线提供了保证。目前该系统已经正式上线运行，状况良好，受到业主方一直好评。 正文 2008年2月，我作为项目经理参与《热轧厂MES管理系统》项目管理。随着信息技术、网络技术的飞速发展，现代企业管理对信息化的需求也不断地扩大，相继提出了建立企业ERP（企业资源规划）系统和MES（制造执行系统）的概念，而《热轧厂MES管理系统》建立在业主方已经存在ERP系统及产线上的多个二级系统的基础上，需要通过本系统，高效地跟踪、控制和管理全线的物流，满足全线生产组织和管理的需要，最大限度地发挥设备能力，调控好全线的生产，达到效益最佳；同时在整条产线推行一体化的生产管理和一贯制的质量控制，达到自动化的生产组织和数据采集、精细的生产控制和物料跟踪以及有序、规范的生产管理。 本系统需要与多个系统进行衔接，并且数据交换量大，生产要求及时性强，稳定性要求高。由于该产线是一条新的生产线，本系统需
要与土建、机械、电气等其他系统同时完成，在全线出钢的时投入运行。所以系统各个模块的测试及与其他系统接口测试工作需受到总工期的制约。 在系统的开发过程中我通过控制进度风险；控制人员流失风险；控制系统功能风险对项目进行管理，保证系统如期完成。 1、控制进度风险 本系统按系统结构分为：软件系统、主机系统和网络系统；按业务功能可以分为：质量管理、生产合同管理、作业计划管理、物料跟踪管理、仓库管理、发货管理、板坯库/钢卷库管理、连铸管理、行车定位跟踪系统9个子系统。以系统的范围说明、技术附件文档和需求文档为基础，建立工作分解结构（WBS），通过对WBS的分析确定每个工作包的完成工期。 由于业主方是新建立一条生产线，多个项目同时进行，所以对工期要求非常严格，我与业主方进行了反复的沟通，根据业主方已有的网路图，此项目的WBS分解包、我公司组织过程资产、以及以往的项目经验，制定了各个功能系统及主机系统的工期，增加了部分预留应急时间，制作项目的网络图和甘特图。 在进度计划里的每一项任务都规定了该任务的工作量、开始时间、结束时间，同时让每个小组都自己所承担任务的时间表，小组成员根据自己的任务制定自己的详细工作计划。 工作日志可以了解每个小组成员工作情况，我们要求小组成员每天做工作日志，对自己每天工作进行详细记录。每周对自己工作进展
风险管理计划 1.引言 1.1本文件的范围和目的 项目风险管理描述了在整个项目生命周期内项目团队如何组织和开展项目风险识别，度量，应对和监控等项目管理活动，是一份指导项目团队进行项目风险管理的纲领性文件。项目风险管理的目标在于提高项目中积极事件的概率和影响，降低项目中消极事件的概率和影响，确保项目在可控的范围内完成项目目标。 1.2概述 1.2.1目标 提高项目中积极事件的概率和影响，降低项目中消极事件的概率和影响，确保项目在可控的范围内完成项目目标。当不能很确定地预测将来事情的时候，可以采用结构化风险管理来发现计划中的缺陷，并且采取行动来减少潜在问题发生的可能性和影响。风险管理意味着危机还没有发生之前就对它进行处理，这就提高了项目成功的机会并减少了不可避免风险所产生的后果。 1.2.2 需要优先考虑规避的风险 （1）业务风险 产品规模风险，商业风险，项目需求风险，客户特性风险，过程风
险 （2）技术风险 技术情况风险，开发环境风险 （3）组织风险 人员数目及其经验风险 1.3组织 1.3.1领导成员 蒋妍，范楚楚，宋蕊蕊，谭琳琳，杨欣颖，赵术洁 1.3.2责任 1.4 风险规避策略的内容说明 1.4.1 进度安排
1.4.2 主要里程碑和审查行动 （1）项目风险分析 通过项目风险分析对项目进行宏观控制，作出风险发生的概率及时作出规避策略，降低项目成本。 （2）项目风险应对 对于出现的不确定风险应及时做出应对措施，提出风险规避备选方案及建议方案，降低项目的失败性。 1.4.3预算 风险情况调查所需花费预算成本 2 风险识别 2.1风险情况调查，风险来源 收集资料 项目产品或服务说明书，项目的前提，假设和制约因素，本项目可与类比的项目。
目 录 一、风险管理 概述 (4) 1.1软件项目风险 (4) 1.2软件项目风险管理 (4) 1.3软件项目风险管理模 型.............................................................................. (6) 1.4小结 ...................................................................................................7 二、软件项目风险管理发展历程 (7) 三、经典风险管理模型 (9) 3.1 Boehm 和Charette 的风险管理框架 (9) 3.2 CMU/SEI 的CRM 持续风险管理模型 (10) 软件项目风险管理资料 【最新资料，WORD 文档，可编辑修改】
3.3Riskit方法 (11) 3.4SoftRisk风险管理模型 (14) 3.5IEEE风险管理标准 (15) 3.6基于CMM/CMMI的软件项目风险管理框架 (15) 3.7Microsoft的MSF风险管理模型 (16) 3.8比较经典风险管理模型 (17) 四、软件项目风险管理的研究方法、技术和工具 (18) 4.1软件项目风险识别方法 (18) 4.2网络分析模型 (21) 4.3系统动力学仿真技术 (22) 4.4基于成本估算模型的风险评估方法 (23) 4.5其他方法体系 (24)
五、我国软件项目风险管理的研究 (24) 5.1研究现状 (24) 5.2思考与建议 (25) 【参考文献】……………………………………………………………………………… 错误!未定义书签。 引言 近几年来软件开发技术、工具都有了很大的进步，但是软件项目开发超时、超支、甚至不能满足用户需求而根本没有得到实际使用的情况仍然比比皆是。软件项目开发和管理中一直存在着种种不确定性，严重影响着项目的顺利完成和提交。但这些软件风险并未得到充分的重视和系统的研究。直到20世纪80年代，Boehm比较详细地对软件开发中的风险进行了论述，并提出软件风险管理的方法。Boehm认为，软件风险管理指的是“试图以一种可行的原则和实践，规范化地控制影响项目成功的风险”，其目的是“辨识、描述和消除风险因素，以免它们威胁软件的成功运作”。 在此基础上，业界对软件风险管理的研究开始慢慢丰富起来，理论上对风险进行了一些分类，提出了风险管理的思路；实践上也出现了一些定量管理风险的方法和风险管理的软件工具。虽然业界对风险管理表现了极大的兴趣，做出了不少努力，但似乎很少开发项目的组织真正积极地在软件开发过程中使用风险管理的方法。1995年IWSED （International Workshop on Software Engineering Data）会议做出的调查显示：风险管理技术没有得到广泛应用的原因并不是大家不相信这种技术的实效性，而是对风险管理的技术和实践缺乏了解。因此，我们认为很有必要对风险管理进行研究。