51Testing软件测试论坛

标题: 请问在测试中的风险分析什么时候进行比较合适？ [打印本页]

作者: tester2005 时间: 2005-6-15 16:36
标题: 请问在测试中的风险分析什么时候进行比较合适？
风险分析什么时候进行比较合适？怎样进行呢？;)

作者: skinapi 时间: 2005-6-15 19:55
测试风险分析多在测试计划过程中进行，什么时候测试计划开始了，就需要考虑测试风险了。

作者: tester2005 时间: 2005-6-16 08:48
那仅仅通过开发人员提供的需求文档和概要设计说明书就能作出风险分析吗？需要从哪些方面具体着手分析呢？盼解答，谢谢！

作者: skinapi 时间: 2005-6-17 09:18
关于测试风险以前的帖子中有讨论，楼主可以在坛子里用“测试风险”为关键字搜搜。^_^

作者: wzb521 时间: 2005-6-17 14:30
进度、成本、技术、需求

作者: archonwang 时间: 2005-6-18 13:06
标题: 没贴图，有兴趣自己搜索一下。
软件项目风险管理

1 前言

一般来说，软件工程师总是非常乐观。当他们在计划软件项目时，经常认为每件事情都会像计划那样运行，或者，又会走向另外一个极端。软件开发的创造性本质意味着我们不能完全预测会发生的事情，因此制定一个详细计划的关键点很难确定。当有预想不到的事情引起项目脱离正常轨道时，以上两种观点都会导致软件项目的失败。

目前，风险管理被认为是IT软件项目中减少失败的一种重要手段。当不能很确定地预测将来事情的时候，可以采用结构化风险管理来发现计划中的缺陷，并且采取行动来减少潜在问题发生的可能性和影响。风险管理意味着危机还没有发生之前就对它进行处理。这就提高了项目成功的机会和减少了不可避免风险所产生的后果。

2 什么是风险

所谓“风险”，归纳起来主要有两种意见，主观说认为，风险是损失的不确定性；客观学认为，风险是给定情况下一定时期可能发生的各种结果间的差异。它的两个基本特征是不确定性和损失。IT行业中的软件项目开发是一项可能损失的活动，不管开发过程如何进行都有可能超出预算或时间延迟。项目开发的方式很少能保证开发工作一定成功，都要冒一定的风险，也就需要进行项目风险分析。在进行项目风险分析时，重要的是要量化不确定的程度和每个风险相当的损失程度，为实现这一点就必须要考虑以下问题：

要考虑未来，什么样的风险会导致软件项目失败？

要考虑变化，在用户需求、开发技术、目标、机制及其它与项目有关的因素的改变将会对按时交付和系统成功产生什么影响？

必须解决选择问题，应采用什么方法和工具，应配备多少人力，在质量上强调到什么程度才满足要求？

要考虑风险类型，是属于项目风险、技术风险、商业风险、管理风险还是预算风险等？

这些潜在的问题可能会对软件项目的计划、成本、技术、产品的质量及团队的士气都有负面的影响。风险管理就是在这些潜在的问题对项目造成破坏之前识别、处理和排除。

3 风险管理

项目风险管理实际上就是贯穿在项目开发过程中的一系列管理步骤，其中包括风险识别、风险估计、风险管理策略、风险解决和风险监控。它能让风险管理者主动“攻击”风险，进行有效的风险管理。

在项目管理中，建立风险管理策略和在项目的生命周期中不断控制风险是非常重要的，风险管理包括四个相关阶段：

风险识别识别风险的方法常用的有风险识别问询法（座谈法、专家法）、财务报表法、流程图法、现场观察法、相关部门配合法和环境分析法等。

风险评估对已识别的风险要进行估计和评价，风险估计的主要任务是确定风险发生的概率与后果，风险评价则是确定该风险的经济意义及处理的费/效分析，常用的方法有：概率分布、外推法、多目标分析法等。

风险处理一般而言，风险处理有三种方法，①风险控制法，即主动采取措施避免风险，消灭风险，中和风险或采用紧急方案降低风险。②风险自留，当风险量不大时可以余留风险。③风险转移。

风险监控包括对风险发生的监督和对风险管理的监督，前者是对已识别的风险源进行监视和控制，后者是在项目实施过程中监督人们认真执行风险管理的组织和技术措施。

在IT软件项目管理中，应该任命一名风险管理者，该管理者的主要职责是在制订与评估规划时，从风险管理的角度对项目规划或计划进行审核并发表意见，不断寻找可能出现的任何意外情况，试着指出各个风险的管理策略及常用的管理方法，以随时处理出现的风险，风险管理者最好是由项目主管以外的人担任。

4 风险识别

风险识别就是企图采用系统化的方法，识别某特定项目已知的和可预测的风险。常用方法是建立“风险条目检查表”，利用一组提问来帮助项目风险管理者了解在项目和技术方面有些风险。在“风险条目检查表”中，列出了所有可能的与每一个风险因素有关的提问，使得风险管理者集中来识别常见的、已知的和可预测的风险，如产品规模风险、依赖性风险、需求风险、管理风险及技术风险等。 “风险条目检查表”可以以不同的方式组织，通过判定分析或假设分析，给出这些提问确定的回答，就可以帮助管理或计划人员估算风险的影响。软件项目一般有如下五类风险：

4.1 产品规模风险

有经验的项目经理都知道：项目的风险是直接与产品的规模成正比的。与软件规模相关的常见风险因素有：

　　估算产品的规模的方法（LOC或代码行，FP或功能点，程序或文件的数目）。

　　产品规模估算的信任度

　　产品规模与以前产品规模平均值的偏差

　　产品的用户数

　　复用的软件有多少

　　产品的需求改变多少

4.2 需求风险

很多项目在确定需求时都面临着一些不确定性和混乱。当在项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生错误的产品或者拙劣地建造正确的产品。每一种情况都会导致使人不愉快。

　　与客户相关的风险因素有：

　　对产品缺少清晰的认识

　　对产品需求缺少认同

　　在做需求中客户参与不够

　　没有优先需求

　　由于不确定的需要导致新的市场

　　不断变化需求

　　缺少有效的需求变化管理过程

　　对需求的变化缺少相关分析

4.3 相关性风险

许多风险都是因为项目的外部环境或因素的相关性产生的。经常我们不能很好地控制外部的相关性，因此缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并且觉察潜在的问题。与外部环境相关的因素有：

　　客户供应条目或信息

　　内部或外部转包商的关系

　　交互成员或交互团体依赖性

　　经验丰富人员的可得性

　　项目的复用性

4.4 管理风险

尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没有包括所有管理活动而感到惊奇。在大部分项目里，项目经理经常是写项目风险管理计划的人，并且大部分人都不希望在公共场合暴露自己的弱点。然而，像这些问题可能会使项目的成功变得更加困难。如果不正视这些棘手的问题，它们就很有可能在项目进行的某个阶段影响项目。当我们定义了项目追踪过程并且明晰项目角色和责任，就能处理这些风险因素：

　　计划和任务定义不够充分

　　实际项目状态

　　项目所有者和决策者分不清

　　不切实际的承诺

　　员工之间的冲突

4.5 技术风险

软件技术的飞速发展和经历丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。在早期，识别风险从而采取合适的预防措施是解决风险领域问题的关键，比如：培训、雇佣顾问以及为项目团队招聘合适的人才等。主要有下面这些风险因素：

　　缺乏培训

　　对方法、工具和技术理解的不够

　　应用领域的经验不够

　　新的技术和开发方法

　　不能正确工作的方法

5 风险估计

风险估计，又称风险预测，常采用两种方法估价每种风险。一种是估计风险发生的可能性或概率，另一种是估计如果风险发生时所产生的后果。一般来讲，风险管理者要与项目计划人员、技术人员及其他管理人员一起执行四种风险活动：

　　（1）建立一个标准（尺度），以反映风险发生的可能性。

　　（2）描述风险的后果。

　　（3）估计风险对项目和产品的影响。

　　（4）确定风险的精确度，以免产生误解。

另外，要对每个风险的表现、范围、时间做出尽量准确的判断。对不同类型的风险采取不同的分析办法。

1．确定型风险估计

（a）盈亏平衡分析

盈亏平衡分析（Break-Even Analysis）通常又称为量本利分析或损益平衡分析。它是根据软件项目在正常生产年份的产品产量或销售量、成本费用、产品销售单价和销售税金等数据，计算和分析产量、成本和盈利这三者之间的关系，从中找出它们的规律，并确定项目成本和收益相等时的盈亏平衡点的一种分析方法。在盈亏平衡点上，软件项目既无盈利，也无亏损。通过盈亏平衡分析可以看出软件项目对市场需求变化的适应能力。

（b）敏感性分析

敏感性分析（Sensitivity Analysis）的目的，是考察与软件项目有关的一个或多个主要因素发生变化时对该项目投资价值指标的影响程度。通过敏感性分析，使我们可以了解和掌握在软件项目经济分析中由于某些参数估算的错误或是使用的数据不太可靠而可能造成的对投资价值指标的影响程度，有助于我们确定在项目投资决策过程中需要重点调查研究和分析测算的因素。

（c）概率分析

它是运用概率论及数理统计方法，来预测和研究各种不确定因素对软件项目投资价值指标影响的一种定量分析。通过概率分析可以对项目的风险情况做出比较准确的判断。主要包括解析法和模拟法（蒙特卡罗Monte Carlo技术）两种。

2．不确定型风险估计

主要有小中取大原则、大中取小原则、遗憾原则、最大数学期望原则、最大可能原则。

3．随机型风险估计

主要有最大可能原则、最大数学期望原则、最大效用数学期望原则、贝叶斯后验概率法等。

5.1 建立风险清单

风险清单是关键的风险预测管理工具，清单上列出了在任何时候碰到的风险名称、类别、概率及该风险所产生的影响。其中整体影响值可对四个风险因素（性能、支持、成本及进度）的影响类别求平均值（有时也采用加权平均值）。

一旦完成了风险表的内容，就可以根据概率及影响来进行综合考虑，风险影响和出现概率从风险管理的角度来看，它们各自起着不同的作用（见图1）。一个具有高影响但低概率的风险因素不应当占用太多的风险管理时间，而具有中到高概率、高影响的风险和具有高概率及低影响的风险，就应该进行风险分析。

5.2 风险评估

在风险分析过程中，我们对风险进行评估时可以建立一个如下的四元数组：

　　[ri , li, xi，yi]

其中，ri是风险，li 为风险出现的概率，xi 则表示风险损失大小，yi 则表示期望风险。

一种对风险评估的常用技术是定义风险的参照水准，对绝大多数软件项目来讲，风险因素——成本、性能、支持和进度就是典型的风险参照系。也就是说对成本超支、性能下降、支持困难、进度延迟都有一个导致项目终止的水平值。如果风险的组合所产生的问题超出了一个或多个参照水平值时，就终止该项目的工作，在项目分析中，风险水平参考值是由一系列的点构成的，每一个单独的点常称为参照点或临界点。如果某风险落在临界点上，可以利用性能分析、成本分析、质量分析等来判断该项目是否继续工作。图2 表示了这种情况。

但在实际工作中，参照点很少能构成一条光滑的曲线，大多数情况下，它是一个区域，而且是个易变的区域。因而在做风险评估时，尽量按以下步骤执行：

　　（1）定义项目的水平参照值

　　（2）找出每组[ri , li, xi，yi]与每个水平参照值间的关系

　　（3）估计一组临界点以定义项目的终止区域

　　（4）估计风险组合将如何影响风险水平参照值

5.3 估计损失的大小

表1是风险分析表的一个例子，可以建立一个用风险、损失概率、损失大小和期望风险这样的风险评估表。

在表1所示的风险估价的例子中，一个理论项目已经识别了从1到20周期间的潜在的几个风险，风险发生的概率范围在5%到50%之间。在现实的项目中，可能会识别出比此表要多得多的风险。

损失的大小常常比概率更容易受到控制。在以上的例子中，可以很精确地估计出完全支持自动从主机更新数据的时间是20个月。根据管理层将在何时讨论项目建议书,可以知道项目不是在2月1日就是3月1日会被批准。如果假定会在2月1日批准，项目被批准的风险大小会比期望的长一些，也就是1个月时间。

如果损失的大小不容易直接估计出来，可以将损失分解为更小的部分，再对其进行评估，然后将各部分评估结果累加，形成一个合计评估值。例如，如果使用3种新编程工具，可以单独评估每种工具未达到预期效果的损失，然后再把损失加到一起，这要比总体评估容易多了。

5.4 评估损失的概率

评估损失的概率要比评估损失大小更具有主观性。这里有许多实践方法可以提高主观评估的准确度。有以下方法：

由最熟悉系统的人评估每个风险的发生概率，然后保留一份风险评估审核文件。

使用Delphi法或少数服从多数的方法。使用Delphi法，必须要求每个人对每个风险进行独立地评估，然后讨论（口头或纸上）每个评估的合理性，特别是最高和最低的那个。一轮轮讨论，直到达成共识。 ? 使用“形容词标准”。首先让每个人用表示可能性的形容词短语选择风险的级别，如非常可能、很可能、可能、或许、不太可能、不可能、和根本不可能。然后把可能性的评估转换为数量化的评估（Boehm1989）。

5.5 整个项目超限和缓冲

实际上，表1中表示的期望风险的计算数值来源于一个被称为“期望值”的统计术语。设计欠佳引起的风险如果真正发生将花费15周的时间。既然它不是100%地会发生，当然不能预计损失15周时间。但它也不是没有可能发生，所以也不应指望不会发生损失。统计学认为，预计损失的数量是概率乘以损失大小，即15%乘以15周。因此，在这个例子中，预计的是损失2.25周。由于只是谈论计划风险，可以累加所有的风险暴露量来得到项目的全部可预料超标值。这个项目可预料的超标值是12.8到13.2周，这就是如果不做任何风险管理的话有可能超过计划的周数。

超出预期值的大小为整个项目风险控制级别的确定提供了依据。如果例子中的项目是个25周的项目，超出预期值的12.8到13.2周就很明显需要进行风险管理了。

6 风险管理策略

风险管理策略就是辅助项目组建立处理项目风险的策略。项目开发是一个高风险的活动，如果项目采取积极的风险管理策略，就可以避免或降低许多风险，反之，就有可能使项目处于瘫痪状态。一般来讲，一个较好的风险管理策略应满足以下要求：

　　（1）在项目开发中规划风险管理，尽量避免风险

　　（2）指定风险管理者，监控风险因素

　　（3）建立风险清单及风险管理计划

　　（4）建立风险反馈渠道

7 风险驾驭和监控

风险的驾驭与监控主要靠管理者的经验来实施，它是利用项目管理方法及其它某些技术，如原型法、软件心理学、可靠性等来设法避免或转移风险。风险的驾驭和监控活动可用图3 来表示。

7.1 建立风险驾驭与监控计划

从图3中可以看出，风险的驾驭与监控活动要写入RMMP（Risk Monitoring and Management Plan风险驾驭与监控计划）。RMMP记述了风险分析的全部工作，并且作为整个项目计划的一部分为项目管理人员所使用。

风险管理策略可以包含在软件项目计划中，也可以组织成一个独立的风险缓解、监控和管理计划（RMMP计划）。RMMP计划将所有风险分析工作文档化，并由项目管理者作为整个项目计划中的一部分来使用。一旦建立了RMMP计划，且项目开始启动，则风险缓解及驾驭及监控步骤也开始了。正如前面讨论的，风险缓解是一种问题避免活动。风险驾驭及监控则是一种项目跟踪活动，它有三个主要目标： ? 判断一个预测的风险是否事实、是否发生。

　　进行风险再估计，确保针对某个风险而制定的风险消除活动正在使用。

　　收集可用于将来进行风险分析的信息。

　　风险驾驭及监控的策略如下：

　　与在职人员协商，确定人员流动原因。

　　在项目开始前，把缓解这些流动原因的工作列入风险驾驭计划。

　　项目开始时，要作好人员流动的思想准备，并采取一些措施确保人员一旦离开时，项目仍能继续。

　　制定文档标准，并建立一种机制，保证文档及时产生。

　　对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作。

　　对每个关键性技术人员培养后备人员。

　　在考虑风险成本之后，决定是否采用上述策略。

7.2 软件项目风险追踪工具

追踪风险的一个办法是将风险输入缺陷追踪系统中，缺陷追踪系统能将风险项目标示为已解决或尚未处理等状态，也能指定解决问题的项目团队成员，并安排处理顺序。可将软件风险项目依序排列出来，按照缺陷存在的时间与负责者等资料排列。这样，缺陷追踪系统就是追踪风险的工作能更好执行并且不那么单调。

8 结束语

软件项目风险管理是一种特殊的规划方式，当对软件项目有较高的期望值时，一般都要进行风险分析。进行过大中型项目开发的人都亲身体验到许多事情可能出错，最成功的项目就是采取积极的步骤对要发生或即将发生的风险进行管理。对任何一个软件项目，可以有最佳的期望值，但更应该要有最坏的准备，“最坏的准备”在项目管理中就是进行项目的风险分析。

作者: tester2005 时间: 2005-6-20 16:56
谢谢各位了，我大概明白了！继续努力中。。。。

作者: Chenny 时间: 2005-6-20 17:08
archonwang
够勤劳！

作者: texiang 时间: 2005-6-23 13:00
不错,一篇较为详细的文章

作者: walker_lai 时间: 2006-8-27 16:54
长见识了

作者: yuyanshe 时间: 2007-5-9 17:39
不错，看得我都有点迷糊了sdlkfj5

作者: changlang530 时间: 2007-8-17 11:03
了解，不过还没有实际操作的实践

作者: 119139107 时间: 2007-8-20 09:27
archonwang
感谢
学习了。。。。

作者: huruihai 时间: 2007-8-20 23:14
谢谢　，看了之后才知道自己想的太单一了　

作者: ieee 时间: 2007-8-21 14:16
受教

作者: zlnhgn 时间: 2007-8-21 17:43
不错的好贴子！！！

作者: zhangsy 时间: 2007-8-21 21:20
好详细哟，要仔细看了

作者: zhsh1203 时间: 2007-8-22 11:57
学习学习、

作者: jennie_crab 时间: 2008-7-2 17:32
好文章

作者: let$it$be 时间: 2008-8-8 11:31
恩，很细，赞

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)