分类： 项目管理
2008-11-25 05:56:30
太多的历史悲剧告示我们风险无处不在，不学会控制它,就一定会被它所控制。软件中的风险小到可以影响你不能访问一个网页，大到可以让宇宙飞船失事。所以我们一定要注重控制软件中的风险。
我们知道，完全一个软件是不可能也是不现实的，因为受到Cost，Schedule，Resource的影响。入下图所示，测试的时候的测试用例只可能是所有测试用例的一小部分。
我们应该要根据Schedule，将Resource和cost合理的分配到一个软件系统中优先级最高，最关键，最需要被测试的地方去。而这个前提就是对软件系统或者软件项目做风险分析。
作者告诉了我们两种风险的分类：
1． 软件风险
这种风险分析主要是确定软件中要测试什么，测试的优先级，测试的深度
2． 规划风险
这种风险主要是为了防范未计划的影响项目进度的事件的发生。比如测试人员突然离开导致人员不足、软件的需求的突然变更。
好，首先来看看软件风险。作者提到了参与软件风险分析的人是来自各个领域的专家。项目经理，开发者，测试者，用户，界面设计者都需要来共同分析软件的风险。而且软件的风险分析要在项目的周期一开始就开始进行，因为风险越迟发现越会影响项目的成功。作者接着给出了软件风险分析的10个步骤，这个流程化的步骤相当好用，我在项目中运用中发现越是大的项目越是能受益于这种分析。不论开发人员、测试人员都能够明确系统中什么是最重要的。下面简要介绍一下：
1． 组建一个“头脑风暴”小组
这个头脑风暴小组是由项目经理，开发者，测试者，用户，界面设计者等各个方面的专家组成。在我所经历的项目中，通常是由Program manager, Testers, Developers来进行讨论。当然比较有经验的比如 Lead和Developer Lead会参与其中，利用经验发现一些潜在可能存在的风险。
2． 列出软件中的所有功能列表
头脑风暴小组应该需要在讨论之前，拿到相应的文档比如需求文档，功能设计文档等。而且一开始可以是对大的方面进行分类，不需要过于细化，慢慢的随着讨论的深入才进行细化。
举书中的ATM机器的例子，比如一开始可以分成
a) 功能性
a.1) 取钱
a.2) 存钱
a.3) 查余额
a.4) 转帐
a.5) 自动还款
b) 性能
c) 安全性
d) 可用性
3． 确定某个功能失败的可能性
这个部分非常关键，就是要确定软件中的那个特性最可能导致失败。这个其实是客观和主观的因素同时才能决定的，可以从下面几方面来判断：
a) 功能对系统功能或者组件的依赖程度，依赖程度很高的话，失败可能性就高
b) 功能本身的复杂度
c) 功能的实现和设计者的经验，如果这个team是年轻和没有太多经验的，那么失败可能性就高
d) 如果用的是新或者实践，可能失败可能性高
e) 如果是旧的功能的改写，那么如果过去它Bug比较多，也是失败可能性较大的。
f) 如果是对旧功能的改写，那么改写几行代码的可能比大量改写失败可能性大，因为回归测试往往不充分
回到书中的例子，
|
ATM软件 |
失败可能性 | |
|
功能 |
特性 | |
|
取钱 |
|
高 |
|
存钱 |
|
中 |
|
查余额 |
|
低 |
|
转帐 |
|
中 |
|
|
可用性 |
中 |
|
|
性能 |
低 |
|
|
安全性 |
高 |
不要太在意目前的高、中、低的评价，可能每个team都可能得出的不同。关键是如果小组中对某个功能或者特性的失败可能性的界定有很多不同的意见时候，给它大部分人意见的赋值并且继续下个功能或者特性的界定。因为我的经验是往往到了后面，还会有很多变数。
4． 确定某个功能失败的所造成的影响
这个分析更多的是从用户的角度。在这时候不要考虑太多技术的角度。这个分析可能有主观，有时候甚至需要市场分析人员的帮助。
|
ATM软件 |
失败可能性 |
失败的影响 | |
|
功能 |
特性 | ||
|
取钱 |
|
高 |
高 |
|
存钱 |
|
中 |
高 |
|
查余额 |
|
低 |
中 |
|
转帐 |
|
中 |
中 |
|
|
可用性 |
中 |
高 |
|
|
性能 |
低 |
中 |
|
|
安全性 |
高 |
高 |
5． 量化
书中提到了将高，中， 低，分别赋值3, 2, 1。当然你也可以设为10，3，1，这是由你的项目组所决定的，但是关键是要在项目的周期内保持一致。
6． 计算出风险优先级
书中用的公式是
风险优先级＝失败可能性＋失败影响。但是我认为乘法也未尝不可。但是这里要注意，如果软件的功能是和人命相关的，那么不论如何设置风险优先级为最高，因为有时候它的失败可能性很低导致计算出的风险优先级也不高
|
ATM软件 |
失败可能性 |
失败的影响 |
优先级 | |
|
功能 |
特性 | |||
|
取钱 |
|
高 |
高 |
6 |
|
存钱 |
|
中 |
高 |
5 |
|
查余额 |
|
低 |
中 |
3 |
|
转帐 |
|
中 |
中 |
4 |
|
|
可用性 |
中 |
高 |
5 |
|
|
性能 |
低 |
中 |
3 |
|
|
安全性 |
高 |
高 |
6 |
|
ATM软件 |
失败可能性 |
失败的影响 |
优先级 | |
|
功能 |
特性 | |||
|
取钱 |
|
高 |
高 |
6 |
|
|
安全性 |
高 |
| |
9． 决定“Cut Line”
有时候在Cost，Schedule，Resource衡量的情况下，可能会Cut一些功能或者特性。红线之下可能放到下个周期再行实现。
|
ATM软件 |
失败可能性 |
失败的影响 |
优先级 | |
|
功能 |
特性 | |||
|
取钱 |
|
高 |
高 |
6 |
|
|
安全性 |
高 |
高 |
6 |
|
存钱 |
|
中 |
高 |
5 |
|
|
可用性 |
中 |
高 |
5 |
|
转帐 |
|
中 |
中 |
4 |
|
查余额 |
|
低 |
中 |
3 |
|
|
性能 |
低 |
中 |
3 |
但是如果这个功能或者特性是非常关键和必不可少的话，那么可能就要增加时间或者经费和人员了。
10． 确定缓解风险的措施
缓解风险的措施为了能够减少软件功能或者特性的失败可能性。注意只是失败可能性，因为失败的影响是不可能被改变的，这个是用户的行为。比如对于复杂的模块，可以在做黑盒测试前，做Code Review（代码评审）
说完了软件风险，我们来说一下规划风险。所谓规划风险指得是项目进行中，出现了一些在计划之外的事件而导致了影响项目的进度。对于这个风险，必须在测试计划中加以说明，并列出缓解的措施。举书中的例子：
事件：用户在项目后阶段，给软件又增加了几个主要的需求
缓解措施1：增加测试资源
缓解措施2：将已有的低优先级的功能或者特性推迟
缓解措施3：降低对低优先级的功能和特性的测试的质量
再举个我遇到过的问题：测试人员突然离开导致测试资源缺乏
缓解措施1：测试人员加班
缓解措施2：推迟项目发布
缓解措施3：从其它项目组调测试人员
缓解措施4：降低对低优先级的功能和特性的测试的质量
缓解措施5：Cut掉某些系统功能或者特性
我们有很多这样的计划之外的事件产生，必须一一列出，给出每个事件产生后的对策，而且这种对策在不同的情景下是不一样的，更多的是依靠经验了。
原文地址：
