软件工程-风险管理(共20页).doc

精选优质文档-----倾情为你奉上风险管理引言风险是关注未来将要发生的事情今天和昨天已不再被关心，如同我们已经在收获由我们过去的行为所播下的种子问题是：我们是否能够通过改变我们今天的行为，而为一个不同的、充满希望的、更美好的明天创造机会其次，这意味着，风险涉及改变，如思想、观念、行为、或地点的改变……第三，风险涉及选择及选择本身所包含的不确定性因此，就象死亡和税收一样，风险是生活中最不确定的元素之一当在软件工程领域考虑风险时，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）的过程评估调查表中进行了改编过程问题你的高级管理层是否支持一份已经写好的政策综述，该综述中强调了标准过程的重要性吗？你的组织是否已经建立了一份已经成文的、用于本项目的软件过程的说明？开发人员是否“签约”同意按照文档所写的软件过程进行开发工作，并自愿使用它？该软件过程是否可以用于其他项目？你的组织是否已经为管理者及技术人员开设了一系列的软件工程培训课程？是否为每一个者和管理者都提供了印好的软件工程标准？是否为作为软件过程一部分而定义的所有交付物建立了文档概要及示例？是否定期地对需求规约、设计和编码进行正式的技术复审？是否定期地对测试过程和测试情况进行复审？是否对每一次正式技术复审的结果要建立了文档，其中包括发现的错误及使用的资源？是否有什么机制来保证软件工程标准确认的方案指导的工作开展正常？是否使用配置管理来维护系统/软件需求、设计、编码及测。