软件工程的风险管理.docx

《软件工程的风险管理.docx》由会员分享，可在线阅读，更多相关《软件工程的风险管理.docx（25页珍藏版）》请在第一文库网上搜索。

1、风险管理引言风险是关注未来将要发生的事情。今天和昨天己不再被关怀，如同我们已经在收获由我们过去的行为所播下的种子。问题是：我们与否可以通过变化我们今天的行为，而为一种不同样於J、充斥但愿的I、更美好的明天发明机会。另首先，这意味着，风险波及变化，如思想、观念、行为、或地点的变化第三，风险波及选择及选择自身所包括的不确定性。因此，就象死亡和税收同样，风险是生活中最不确定的元素之一。当在软件工程领域考虑风险时，Charette的三个概念定义是显而易见的。未来是我们所关怀的一一什么样的风险会导致软件项目彻底失败呢？变化也是我们所关怀的一一顾客需求、开发技术、目In计算机、以及所有其他与项目有关的原因

2、的变化将会对准时交付和总体成功产生什么影响呢？最终,我们必须抓住选择机会一一我们应当采用什么措施及工具？需要多少人员参与工作？对质量的规定要抵达什么程度才是“足够的”？PeterDruckerDRU75曾经说过：“当没有措施消除风险，甚至连试图减少该风险也存在疑问时，这些风险就是真正的风险了。在我们可以标识出软件项目中的“真正风险”之前，识别出所有对管理者及开发者而言均为明显的风险是很重要的。1. 1被动和积极H勺风险方略被动风险方略被戏称为“印地安那琼斯学派的风险管理”TH092o印地安那琼斯在以其名字为影片名的电影中，每当面临无法克服的困难时，总是一成不变地说：“不要紧张，我会想出措施来的

3、！。印地安那琼斯从不紧张任何问题，直到它们发生，再做出英雄式FrJ反应。遗憾的是，一般的软件项目管理者并不是印地安那琼斯，且软件项目组的组员也不是他的可信赖的伙伴。大多数软件项目组还是仅仅依赖于被动风险方略。被动方略最多不过是针对也许发生的风险来监督项目，直到它们变成真正的问题时,才会拨出资源来处理它们。更普遍的状况是，软件项目组对于风险不闻不问，直到发生了错误，这时，项目组才赶紧采用行动，试图迅速地纠正错误。这常常被称为“救火模式”。当这样的努力失败后，“危机管理”CHA92接管一切，这时项目已经处在真正的危机中了。对于风险管理的一种更聪颖的方略是积极式的。积极方略早在技术工作开始之前就已经

4、启动了。标识出潜在於I风险，评估它们出现的I概率及产生的影响，且按重要性加以排序，然后，软件项目组建立一种计划来管理风险。重要的目的是防止风险，但由于不是所有的!风险都可以防止，因此，项目组必须建立一种意外事件口勺计划，使其在必要时可以以可控的及有效的方式作出反应。在本章其他部分，我们将讨论风险管理的积极方略。1.2软件风险虽然对于软件风险的严格定义还存在诸多争议，但在风险中包括了两个特性这点上是已抵达了共识的HIG95：不确定性一一刻划风险的事件也许发生也也许不发生；即，没有100%发生的风险（100%发生口勺风险是加在项目上的约束）。损失一一假如风险变成了现实，就会产生恶性后果或损失。进行

5、风险分析时，重要的是量化不确定性的程度及与每个风险有关的损失的程度。为了实现这点，必须考虑不同样类型的风险。项目风险威胁到项目计划。也就是说，假如项目风险变成现实，有也许会迟延项目的进度，且增长项目的成本。项目风险是指潜在的预算、进度、人力（工作人员及组织）、资源、客户、及需求等方面的问题以及它们对软件项目的影响。在第5章中，项目复杂性、规模、及构造不确定性也被定义为项目（估算）风险原因。技术风险威胁到要开发软件的质量及交付时间。假如技术风险变成现实，则开发工作也许变得很困难或主线不也许。技术风险是指潜在的设计、实现、接口、验证、和维护等方面的问题。此外，规约的二义性、技术的不确定性、陈旧的技

6、术、及“先进时”技术也是风险原因。技术风险的发生是由于问题比我们所设想的愈加难以处理。商业风险威胁到要开发软件的生存能力。商业风险常常会危害项目或产品。五个重要的商业风险是：（1）开发了一种没有人真正需要的优秀产品或系统（市场风险）；（2）开发的产品不再符合企业的整体商业方略（方略风险）：（3）建造了一种销售部门不懂得怎样去卖的产品；（4）由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）；以及（5）没有得到预算或人力上的保证（预算风险）。应当注意到的很重要的一点是：简朴的分类并不总是行得通。某些风险主线无法事先预测。另一种常用的分类方式是由CharetteCHA89提出的。已知风

7、险是通过仔细评估项目计划、开发项目的!商业及技术环境、以及其他可靠的信息来源（如，不现实的交付时间，没有需求或软件范围的文档、恶劣的开发环境）之后可以发现的那些风险。可预测风险可以从过去项目的经验中推断出来（如，人员调整、与客户之间无法沟通、由于需要进行维护而使开发人员精力分散）。不可预测风险就象纸牌中的大王，它们也许、也会真FI勺出现，但很难事先识别出它们来。1.3识别风险识别风险是试图系统化地确定对项目计划（估算、进度、资源分派）的威胁。通过识别已知的和可预测的风险，项目管理者已经迈出了第一步一一在也许时防止这些风险，且当必要时控制这些风险。在12节中提出的每一类风险又分为两个不同样的类型

8、：一般性风险和特定产品H勺风险。一般性风险对每一种软件项目而言都是一种潜在的威胁。特定产品的风险只有那些对目前项目的技术、人员、及环境非常理解的人才能识别出来。为了识别特定产品H勺风险，必须检查项目计划及软件范围阐明，并给出如下问题的答案：“本项目中有什么特殊的特性也许会威胁到我们的项目计划？”一般性风险和特定产品的风险都应当被系统化地标识出来。TomGi1bG1188很贴切地体现了这点：“假如你不积极袭击风险，风险就会积极袭击你”。识别风险的一种措施是建立风险条目检查表。该检查表可以用于识别风险，并使得人们集中来识别下列常见子类型中欧!已知的及可预测的风险：产品规模一一与要建造或要修改的软件

9、的总体规模有关的风险。商业影响-一与管理或市场所加诸的约束有关的风险。 客户特性一一与客户的素质以及开发者和客户定期通信的能力有关的I风险。 过程定义一与软件过程被定义的程度以及它们被开发组织所遵守的程度有关的风险。 开发环境一一与用以建造产品的工具的可用性及质量有关的风险。 建造的技术一一与待开发软件的复杂性及系统所包括技术的I“新奇性”有关的风险。 人员数目及经验一一与参与工作的软件工程师的总体技术水平及项目经验有关的风险。风险条目检查表可以以不同样的方式来组织。与上述每个话题有关的问题可以由每一种软件项目来回答。这些问题的答案使得计划者可以估算风险产生的影响。我们也可以采用另种不同样的!

10、风险条目检查表，它仅仅列出与每种常见子类型有关的特性。最终，列出一组“风险元素和驱动因子”AFC88以及它们发生的J概率。有关性能、支持、成本、及进度的驱动因子将在后来讨论。1.3.1产品规模风险有经验H勺管理者几乎都对下面的陈说没有异议：项目风险是直接与产品规模成正比的。下面的风险检查表中的条目的识了与产品（软件）规模有关的常见风险: 与否以1OC或FP估算产品的规模？ 对于估算出的产品规模的信任程度怎样？ 与否以程序、文献或事务处理的数目来估算产品规模？ 产品规模与此前产品的规模平均值的偏差比例是多少？ 产品创立或使用的数据库大小怎样？ 产品的顾客数有多少？ 产品的需求变化多少？交付之前有

11、多少？交付之后有多少？ 复用的软件有多少？在每一种状况下，待开发产品的信息必须与过去的经验加以比较。假如出现了较大的比例偏差，或者假如数字相近但过去的成果很不令人满意，则风险较高。1.3.2商业影响风险有一种大型软件企业的工程经理在他的墙上挂了一种镜框，上面写着：“上帝给了我头脑使我成为一种优秀的项目管理者，同步每当销售部门设定项目的最终期限时，也让我经历了地狱般的煎熬”。销售部门是受商业驱动时，而商业考虑有时会直接与技术现实发生冲突。下面的风险检查表中的条目的识了与商业影响有关的常见风险：本产品对企业的收入有何影响？本产品与否得到企业高级管理层的重视? 交付期限的合理性怎样？ 将会使用本产品

12、的顾客数及本产品与否与顾客的需要相符合？ 本产品必须能与之互操作的其他产品/系统口勺数目？ 最终顾客的水平怎样？ 必须产生并交付给顾客的产品文档的量与质怎样？ 政府对本产品开发的约束？ 延迟交付所导致的!成本消耗是多少？ 产品缺陷所导致的成本消耗是多少？对于待开发产品的每一种回答都必须与过去的经验加以比较。假如出现了较大的比例偏差，或者假如数字相近但过去的成果很不令人满意，则风险较高。 .3.3客户有关的风险并非所有客户都是同样的。PreSSmar1和HerrOnPRE91在讨论这个话题时曾经说过:客户有不同样的需要。某些人懂得他们需要什么；而另某些人懂得他们不需要什么。某些客户但愿进行详细讨

13、论，而另某些客户则满足于模糊的承诺。客户有不同样的个性。某些人喜欢享有客户的身份一一紧张、谈判、一种好产品带来的心理满足;而另某些人则主线不喜欢作为客户。某些人会快乐地接受几乎任何交付的产品，并能充足运用一种不好的产品；而另某些人则会对质量差的产品剧烈抨击。某些人会对质量好的产品体现他们的赞赏：而另某些人则不管怎样都会埋怨不休。客户和他们的供应商之间也有多种不同样的通信方式。某些人非常熟悉产品及生产厂商；而另某些人则也许素未谋面，仅仅通过信件往来和几种匆忙的与生产厂商沟通。客户常常是矛盾的。他们但愿昨天的一切工作都是免费的。生产厂商常常陷入客户自己的矛盾之中。一种“不好的”客户也许会对一种软件

14、项目组能否在预算内准时完毕项目产生很大的影响。对于项目管理者而言，不好口勺客户是对项目计划的巨大威胁和实际的风险。下面口勺风险检查表中的条目的识了与客户特性有关的常见风险： 你此前与否曾与这个客户合作过？ 该客户与否很清晰需要什么？他能否花时间把需求写出来？ 该客户与否同意花时间召开正式的需求搜集会议（第11章），以确定项目范围？ 该客户与否乐意建立与开发者之间的迅速通信渠道？ 该客户与否乐意参与复审工作？ 该客户与否具有该产品领域的技术素养?该客户与否乐意让你的人来做他们的工作，即，当你的人在做详细的技术工作时，该客户与否会坚持在旁边监视？该客户与否理解软件过程？假如对于这些问题中的任何一种

15、欧I答案与否认的J,则需要进行深入的调研，以评估潜在的风险。1. 3.4过程风险假如软件过程（第2章）定义得不清晰；假如分析、设计、及测试以无序的方式进行;假如质量是每个人都认为很重要的概念，但没有人切实地采用行动来保证它，那么，这个项目就处在风险之中。如下问题摘自一次由R.S.Pressman&Associates,Inc.PRE95建立时对软件工程实践活动进行评估的研讨会。这些问题已经在软件工程研究所（SE1）日勺过程评估调查表中进行了改编。过程问题你的高级管理层与否支持一份已经写好的政策综述，该综述中强调了软件开发原则过程的重要性吗？你的组织与否已经建立了份已经成文的、用于本项目的软件过程的阐明？开发人员与否“签约”同意按照文档所写的软件过程进行开发工作，并自愿使用它？该软件过程与否可以用于其他项目？ 你的组织与否已经为管理者及技术人员开设了一系列的软件工程培训课程？与否为每种软件开发者和管理者都提供了印好的软件工程原则？.与否为作为软件过程一部分而定义的所有交付物建立了文档概要及示例？ 与否认期地对需求规约、设计和编码进行正式的技术复审？ 与否认期地对测试过程和测试状况进行复审？ 与否对每一次正式技术复审的成果要建立了文档，其中包括发现的错误及使用的资源？ 与否有什么机制来保证