《软件项目风险管理》由会员分享，可在线阅读，更多相关《软件项目风险管理（14页珍藏版）》请在金锄头文库上搜索。
1、软件项目风险管理一、风险管理概述软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。风险关注未来的事情，这意味 着，风险涉及选择 及选择本身包含的不确定性，在软件开发过程及软件产品都要面临各种决策的选择。风 险是介于确定性和不确定性之间的状 态， 是处于无知和完整知识之间的状态。 另一方面， 风险将涉及思想、 观念、行为、地点等因素的改变。当在软件工程领域考虑风险时，我们要关注以下的问题：什么样的风险会导致软件项目的彻底失败？ 用户需求、开发技 术、目标计算机、以及所有其它与项目有关的因素的改变将会对按时交付和总体成功产 生什么影响？对于采用什么方法和工 具，需要多少人员参与工作的问
2、题，我们如何选择和决策？对软件质 量要达到什么程度才是 “足够的 ”？当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了。在我们能 够标识出软件项目 中的真正风险之前，识别出所有对管理者和开发者而言均为明显得风险是很重要的。二、被动和主动的风险策略被动风险策略是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理 它们，更普遍的 是，软件项目组对风险不闻不问，直到发生了错误才赶紧采取行动，试图迅速地纠正错误。 这种管理模式常常被称为 “救火模 式 ”。当补救的努力失败后，项目就处在真正的危机之中了。对于风险管理的一个更聪明的策略是主动式的。 主
3、动策略早在技术工作开始之前就已经启动了 标 识出潜在地风 险，评估它们出现的概率及产生的影响，对风险按重要性进行排序，然后，软件项目组建立 一个计划来管理风险。 主动策略风 险管理的主要目标是预防风险。 但是， 因为不是所有的风险都能够预防， 所以，项目组必须建立一个应付意外事件的计划， 使其在必要时能够以可控的及有效的方式作出反应。三、软件风险1、软件风险包含两个特征：不确定性 刻划风险的事件可能发生也可能不发生，没有 100 发生的风险。 损失 如果风险变成了现实，就会产生 恶性后果或损失。2、进行风险分析时，重要的是量化不确定的程度和与每个风险相关的损失的程度。 为了实现这点，必须考虑以
4、下几种不同类型 的风险：项目风险：项目风险是指潜在的预算、进度、人力（工作人员和组织）、资源、客户、需求等方面的问题 以及它们对软件项目 的影响。项目风险威胁项目计划，如果风险变成现实，有可能会拖延项目的进度，增 加项目的成本。项目风险的因素还包括项 目的复杂性、规模、结构的不确定性。技术风险：是指潜在地设计、实现、接口、验证和维护等方面的问题。此外规约的二义性、技术的不确定 性、陈旧的技术、以及 过于先进”的技术也是风险因素。技术风险威胁要开发的软件的质量及交付时间。 如果技术风险变成现 实，则开发工作可能变得很困难或者不可能。商业风险：商业风险威胁到要开发软件的生存能力。商业风险常常会危害
5、项目或产品。五个主要的商业风险是：（1 ）开发一个没有人真正需要的优秀产品或系统（市场风险）；（2）开发的产品不再符合公司的整体商业策略（策略风险）；（3）建造了一个销售部门不知道如何去卖的产品；（4 ）由于重点的转移或人员的变动而失去了高级管理层的支持（管理风险）；（5 ）没有得到预算或人力上的保证（预算风险）。3、风险分为以下方式：（1 ）已知风险， 是通过仔细评估项目计划、开发项目的商业及技术环境、以及其它可靠的信息来源（如： 不现实的交付时 间，没有需求或软件范围的文档、恶劣的开发环境）之后可以发现的那些风险。（2） 可预测风险，能够从过去项目的经验中推测岀来（如：人员调整，与客户之间
6、无法沟通，由于需要进 行维护而使开发人 员精力分散）。（3）不可预测风险，它们可能、也会真的岀现，但很难事先识别岀它们来。四、识别风险识别风险是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。通过识别已知和可预测 的风险，项目管理 者就有可能避免这些风险，且当必要时控制这些风险。每一类风险可以分为两种不同的类型：一般性风险和特定产品的风险。一般性风险对每一个软件项目 而言都是一个潜在地威胁。特定产品的风险只有那些对当前项目的技术、人员、及环境非常了解的人才能 识别出来。为了识别 特定产品的风险，必须检查项目计划及软件范围说明，从而了解本项目中有什么特殊 的特性可能会威胁到项目计划。一
7、般性风险和特定产品的风险都应该被系统化地标识出来。 识别风险的一个方法是建立风险条目检查 表。该检查表可以用来识别风险，并可以集中来识别下列常见子类型中已知的及可预测的风险：* 产品规模与要建造或要修改的软件的总体规模相关的风险。* 商业影响一一与管理或市场所加诸的约束相关的风险。* 客户特性一一与客户的素质以及开发者和客户定期通信的能力相关的风险。过程定义一一与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。* 开发环境一一与用以建造产品的工具的可用性及质量相关的风险。* 建造的技术一一与待开发软件的复杂性以及系统所包含技术的 新奇性”目关的风险。* 人员数目及经验 一一与参与
8、工作的软件工程师的总体技术水平及项目经验相关的风险。风险条目检查表能够以不同的方式来组织。与上述话题相关的问题可以由每一个软件项目来回答。这 些问题的答案使得 计划者能够估算风险产生的影响。1、产品规模风险项目风险是直接与产品规模成正比的。下面的风险检查表中的条目标识了产品（软件）规模相关的常 见风险 是否以 LOC 或 FP 估算产品的规模；对于估算岀的产品规模的信任程度如何；是否以程序、文件或事务处理的数目来估算产品规模；* 产品规模与以前产品的规模的平均值的偏差百分比是多少； 产品创建或使用的数据库大小如何；* 产品的用户数有多少； 产品的需求改变多少？交付之前有多少？交付之后有多少？复
9、用的软件有多少？2、商业影响风险销售部门是受商业驱动的，而商业考虑有时会直接与技术实现发生冲突。下面的风险检查表中的条目 标识了与商业影响相关的常见风险： 本产品对公司的收入有何影响；本公司是否得到公司高级管理层的重视；* 交付期限的合理性如何；* 将会使用本产品的用户数及本产品是否与用户的需要相符合；* 本产品必须能与之互操作的其它产品 / 系统的数目；* 最终用户的水平如何；* 政府对本产品开发的约束；延迟交付所造成的成本消耗是多少；* 产品缺陷所造成的成本消耗是多少；对于待开发产品的每一个回答都必须与过去的经验加以比较。 如果岀现了较大的百分比偏差或者如果 数字接近过去很不令人满意的结果
10、，则风险较高。3、客户相关风险客户有不同的需要。一些人只知道他们需要什么；而另一些人知道他们不需要什么。一些客户希望进 行详细的讨论，而 另客户则满足于模糊的承诺。客户有不同的个性。一些人喜欢享受客户的身份，而另一些人则根本不喜欢做为客户。一些人会高兴 地接受几乎任何交 付的产品，并能充分利用一个不好的产品；而另一些人则会对质量差的产品猛烈抨击。 一些人会对质量好的产品表示赞赏；而 另一些人则不管怎样都抱怨不休。客户和供应商之间也有各种不同的通信方式。一些人非常熟悉产品及生产厂商；而另一些人则可能素 未谋面，仅仅通过 信件来往和电话与生产厂商沟通。一个 不好的”客户可能会对一个软件项目组能否在
11、预算内完成项目产生很大的影响。对于项目管理者 而言，不好的客户是对项目计划的巨大威胁和实际的风险。下面的风险检查表中的条目标识了与客户特征 相关的常见风险： 你以前是否曾与这个客户合作过；* 该客户是否很清楚需要什么；他能否化时间把需求写岀来； 该客户是否同意花时间召开正式的需求收集会议，以确定项目范围；* 该客户是否愿意建立与开发者之间的快速通信渠道；* 该客户是否愿意参加复审工作；该客户是否具有改产品领域的技术素养； 该客户是否愿意你的人来做他们的工作； 该客户是否了解软件过程； 如果对于这些问题中的任何一个答案是否定的，则需要进一步的调研，以评估潜在地风险。4、过程风险 如果软件过程定义
12、得不清楚；如果分析、设计、测试以无序的方式进行；如果质量是每个人都认为很 重要的概念，但没有人切实采取行动来保证它，那么这个项目就处在风险之中。过程问题：* 高级管理层是否有一份已经写好的政策陈述，该陈述中强调了软件开发标准过程的重要性；* 开发组织是否已经拟定了一份已经成文的、用于本项目开发的软件过程的说明；* 开发人员是否同意按照文档所写的软件过程进行开发工作，并自愿使用它；* 该软件过程是否可以用于其它项目；4 管理者和开发人员是否接受过一系列的软件工程培训；4 是否为每一个软件开发者和管理者提供了印好的软件工程标准；* 是否为作为软件过程一部分而定义的所有交付物建立了文档概要及示例；*
13、 是否定期对需求规约、设计和编码进行正式的技术复审；是否定期对测试过程和测试情况进行复审；是否对每一次正式技术复审的结果建立了文档，其中包括发现的错误及使用的资源；* 有什么机制来保证按照软件工程标准来指导工作；* 是否使用配置管理来维护系统 / 软件需求、设计、编码、测试用例之间的一致性；* 是否使用一个机制来控制用户需求的变化及其对软件的影响；* 对于每一个承包岀去的子合同，是否有一份文档化的工作说明、一份软件需求规约和一份软件开 发计划；* 是否有一个可遵循的规程，来跟踪及复审子合同承包商的工作；技术问题是否使用方便易用的规格说明技术来辅助客户与开发者之间的通信;是否使用特定的方法进行软
14、件分析； 是否使用特定的方法进行数据和体系结构的设计； 是否 90 %以上的代码都是使用高级语言编写的； 是否定义及使用特定的规则进行代码编写；是否使用特定的方法进行测试用例的设计； 是否使用配置管理软件工具控制和跟踪软件过程中的变化活动； 是否使用工具来创造软件原型；是否使用软件工具来支持测试过程；是否使用软件工具来支持文档的生成和管理； 是否收集所有软件项目的质量度量值； 是否收集所有软件项目的生产率度量值；如果对于上述问题的答案多数是否定的，则软件过程是薄弱的，且风险很高5、技术风险突破技术的极限极具挑战性和令人兴奋，但这也是有风险的。下面的风险检查表中的条目标识了与建 造的技术相关的常
15、 见风险：该技术对于你的公司而言是新的吗；* 客户的需求是否需要创建新的算法或输入、输岀技术；待开发的软件是否需要使用新的或未经证实的硬件接口；* 待开发的软件是否需要与开发商提供的未经证实的软件产品接口；* 待开发的软件是否需要与功能和性能均未在本领域得到证实的数据库系统接口；4 产品的需求是否要求采用特定的用户界面；4 产品的需求中是否要求开发某些程序构件，这些构件与你的公司以前开发的构件完全不同；需求中是否要求采用新的分析、设计、测试方法；* 需求中是否要求使用非传统的软件开发方法；* 需求中是否有过分的对产品的性能约束；* 客户能确定所要求的功能是可行的吗？如果对于这些问题中的任何一个答案是肯定的，则需要进一步的调研，以评估潜在地风险。6、开发环境风险软件工程环境支持项目组、过程及产品，但是，如果环境有缺陷，它就有可能成为重要的风险源。下 面的风险检查表中 的条码标识了与开发环境相关的风险：* 是否有可用的软件项目管理工具；* 是否有可用的软件过程管理工具；* 是否有可用的分析及设计工具；分析和设计工具是否适用于待建造产品；* 是否有可用的编译器或代码生成器； 是否有可用的测试工具；
