软件工程-风险管理.docxVIP

风险管理 引言 风险是关注未来将要发生的事情。今天和昨天已不再被关心，如同我们已经在收获由 我们过去的行为所播下的种子。问题是：我们是否能够通过改变我们今天的行为，而为一个 不同的、充满希望的、更美好的明天创造机会。其次，这意味着，风险涉及改变，如思想、观念、行为、或地点的改变……第三，风险涉及选择及选择本身所包含的不确定性。因此， 就象死亡和税收一样，风险是生活中最不确定的元素之一。 当在软件工程领域考虑风险时，Charette 的三个概念定义是显而易见的。未来是我们所关心的——什么样的风险会导致软件项目彻底失败呢？改变也是我们所关心的——用户 需求、开发技术、目标计算机、以及所有其他与项目相关的因素的改变将会对按时交付和总体成功产生什么影响呢？最后，我们必须抓住选择机会——我们应该采用什么方法及工具？ 需要多少人员参与工作？对质量的要求要达到什么程度才是“足够的”？ Peter Drucker［DRU75］曾经说过：“当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了”。在我们能够标识出软件项目中的“真正风 险”之前，识别出所有对管理者及开发者而言均为明显的风险是很重要的。 被动和主动的风险策略 被动风险策略被戏称为“印地安那·琼斯学派的风险管理”［THO92］。印地安那·琼 斯在以其名字为影片名的电影中，每当面临无法克服的困难时，总是一成不变地说：“不要 担心，我会想出办法来的！”。印地安那·琼斯从不担心任何问题，直到它们发生，再做出英雄式的反应。 遗憾的是，一般的软件项目管理者并不是印地安那·琼斯，且软件项目组的成员也不 是他的可信赖的伙伴。大多数软件项目组还是仅仅依赖于被动风险策略。被动策略最多不过 是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理它们。更普遍的情况是，软件项目组对于风险不闻不问，直到发生了错误，这时，项目组才赶紧采 取行动，试图迅速地纠正错误。这常常被称为“救火模式”。当这样的努力失败后，“危机 管理”［CHA92］接管一切，这时项目已经处于真正的危机中了。 对于风险管理的一个更聪明的策略是主动式的。主动策略早在技术工作开始之前就已 经启动了。标识出潜在的风险，评估它们出现的概率及产生的影响，且按重要性加以排序， 然后，软件项目组建立一个计划来管理风险。主要的目标是预防风险，但因为不是所有的风 险都能够预防，所以，项目组必须建立一个意外事件的计划，使其在必要时能够以可控的及 有效的方式作出反应。在本章其余部分，我们将讨论风险管理的主动策略。 软件风险 虽然对于软件风险的严格定义还存在很多争议，但在风险中包含了两个特性这一点上是已达成了共识的［HIG95］： ·不确定性——刻划风险的事件可能发生也可能不发生；即，没有100％发生的风险 （100％发生的风险是加在项目上的约束）。 ·损失——如果风险变成了现实，就会产生恶性后果或损失。 进行风险分析时，重要的是量化不确定性的程度及与每个风险相关的损失的程度。为了实现这点，必须考虑不同类型的风险。 项目风险威胁到项目计划。也就是说，如果项目风险变成现实，有可能会拖延项目的 进度，且增加项目的成本。项目风险是指潜在的预算、进度、人力（工作人员及组织）、资源、客户、及需求等方面的问题以及它们对软件项目的影响。在第5 章中，项目复杂性、规模、及结构不确定性也被定义为项目（估算）风险因素。 技术风险威胁到要开发软件的质量及交付时间。如果技术风险变成现实，则开发工作 可能变得很困难或根本不可能。技术风险是指潜在的设计、实现、接口、验证、和维护等方面的问题。此外，规约的二义性、技术的不确定性、陈旧的技术、及“先进的”技术也是风险因素。技术风险的发生是因为问题比我们所设想的更加难以解决。 商业风险威胁到要开发软件的生存能力。商业风险常常会危害项目或产品。五个主要的商业风险是：（1）开发了一个没有人真正需要的优秀产品或系统（市场风险）；（2）开发的产品不再符合公司的整体商业策略（策略风险）；（3）建造了一个销售部门不知道如何去卖的产品；（4）由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）； 以及（5）没有得到预算或人力上的保证（预算风险）。应该注意到的很重要的一点是：简单的分类并不总是行得通。某些风险根本无法事先预测。 另一种常用的分类方式是由Charette［CHA89］提出的。已知风险是通过仔细评估项目 计划、开发项目的商业及技术环境、以及其他可靠的信息来源（如，不现实的交付时间，没有需求或软件范围的文档、恶劣的开发环境）之后可以发现的那些风险。可预测风险能够从 过去项目的经验中推断出来（如，人员调整、与客户之间无法沟通、由于需要进行维护而使 开发人员精力分散）。不可预测风险就