软件工程-风险管理

·是否有最优秀的人员可用？ ·人员在技术上是否配套？ ·是否有足够的人员可用？

·开发人员是否能够自始自终地参加整个项目的工作？ ·项目中是否有一些人员只能部分时间工作？ ·开发人员对自己的工作是否有正确的期望？ ·开发人员是否接受过必要的培训？

·开发人员的流动是否仍能保证工作的连续性？

如果对于这些问题中的任何一个的回答是否定的，则需要进行进一步的调研，以评估潜在的风险。

1.3.8 风险因素和驱动因子

美国空军［AFC88］写了一本小册子，其中包含了如何很好地识别和消除软件风险的指南。

他们所用的方法要求项目管理者标识影响软件风险因素的风险驱动因子，这些因素包括性能、成本、支持和进度。在本讨论中，风险因素是以如下的方式定义的：

·性能风险——产品能够满足需求且符合于其使用目的的不确定的程度。 ·成本风险——项目预算能够被维持的不确定的程度。 ·支持风险——软件易于纠错、适应及增强的不确定的程度。

·进度风险——项目进度能够被维持且产品能按时交付的不确定的程度。

每一个风险驱动因子对风险因素的影响均可分为四个影响类别——可忽略的、轻微的、严重的及灾难性的。表1－1［BOE89］指出了由于错误而产生的潜在影响（标为1的行）或

没有达到预期的结果所产生的潜在影响（标为2的行）。影响类别的选择是以最符合表中描述的特性为基础的。

1.4 风险预测

风险预测，又称风险估算，试图从两个方面评估每一个风险——风险发生的可能性或概率，以及如果风险发生了，所产生的后果。项目计划者，以及其他管理人员和技术人员，一起执行四个风险预测活动：（1）建立一个尺度，以反映风险发生的可能性；（2）描述风险的后果；（3）估算风险对项目及产品的影响；（4）标注风险预测的整体精确度，以免产生误解。

1.4.1 建立风险表

风险表给项目管理者提供了一种简单的风险预测技术（风险表应该采用电子表格来实现，这样使得表中的内容易于操纵及排序）。风险表的样本如图1－2所示。

项目组一开始要在表中的第一列列出所有风险（不管多么细微）。这可以利用1.3节所述的风险检查表条目来完成。每一个风险在第二列上加以分类（如，PS指产品规模风险，BU指商业风险）。每个风险发生的概率则输入到第三列中。每个风险的概率值可以由项目组成员个别估算，然后将这些单个值求平均，得到一个有代表性的概率值。下一步是评估每个风险所产生的影响。使用表1－1所述的特性评估每个风险因素，并确定其影响的类别。对四个风险因素——性能、支持、成本、及进度——的影响类别求平均可得到一个整体的影响值（如果其中一个风险因素对项目特别重要，也可以使用加权求平均值）。

一旦完成了风险表的前四列内容，就要根据概率及影响来进行排序。高发生概率、高影响的风险放在表的上方，而低概率风险则移到表的下方。这样就完成了第一次风险排序。

项目管理者研究已排序的表，并定义一条中止线。该中止线（表中某一点上的一条水平线）表示：只有那些在线之上的风险才会得到进一步的关注。

而在线之下的风险则需要再评估以完成第二次排序。

风险影响及概率从管理的角度来考虑，是起着不同的作用的（见图1－1）。一个具有高影响但发生概率很低的风险因素不应该花费太多的管理时间。而高影响且发生概率为中到高的风险、以及低影响且高概率的风险，应该首先列入管理考虑之中。

所有在中止线之上的风险都必须进行管理。标有RMMM的列中包含了一个指示器，指向为所有中止线之上的风险所建立的风险缓解、监控、及管理计划（Risk Mitigation，Monitoringand Management Plan）。RMMM计划将在1.5节讨论。

风险概率的确定可以通过先做个别估算而后求出一个有代表性的值来完成。虽然该方法是可行的，不过仍存在很多其他确定风险概率的更加复杂的技术［AFC88］可供使用。风险驱动因子的评估是以一个定性的概率尺度：不可能、不一定、可能和极可能为基础，然后，根据每一个定性值相关的数学概率值（如，概率为0.7到1.0表示极可能发生的风险）来计算的。

1.4.2评估风险影响

如果风险真的发生了所产生的后果有三个因素可能会受影响：风险的性质，范围，及时间。风险的性质是指当风险发生时可能产生的问题。例如，一个定义得很差的与客户硬件的外部接口（技术风险）会妨碍早期的设计及测试，也有可能导致项目后期阶段的系统集成问题。风险的范围结合了严重性（即风险有多严重？）及其整体分布情况（项目中有多少部分受到影响或有多少用户受到损害？）。最后，风险的时间主要考虑何时能够感到风险及持续多长时间。在大多数情况下，项目管理者希望“坏消息”越早出现越好，但在某些情况下，越迟越好。

让我们再回到美国空军提出的风险分析方法上来［AFC88］。以下的步骤被建议用来确定风险的整体影响：

1.确定每个风险元素发生的平均概率。

2.使用表1－1，基于其中列出的标准来确定每个因素的影响。 3.按照前面几节给出的方法完成风险表，并分析其结果。

1.4.1节和1.4.2节所述的风险预测和分析技术可以在软件项目进展过程中迭代使用。项目组应该定期复查风险表，再评估每一个风险，以确定新的情况是否引起其概率及影响发

生改变。这个活动的结果可能需要在表中添加一些新风险，删除一些不再有影响的风险，并改变风险的相对位置。

1.4.3风险评估

在风险管理中的这一步，我们建立了如下形式的一系列三元组［CHA89］： ［ri，li，xi］

其中ri表示风险，li表示风险发生的概率，xi则表示风险产生的影响。在风险评估过程中，我们进一步审查在风险预测阶段所做的估算的精确度，试图为所发现的风险排出优先次序，并开始考虑如何控制和/或避免可能发生的风险。

要使评估发生作用，必须定义一个风险参考水平值［CHA89］。对于大多数软件项目而言，前面所讨论的风险因素——性能、成本、支持、及进度——也代表示了风险参考水平值。即，对于性能下降、成本超支、支持困难、或进度延迟（或者这四种的组合），都有一个水平值的要求，超过它就会导致项目被迫终止。如果风险的组合所产生的问题引起一个或多个参考水平值被超过，则工作将会停止。在软件风险分析中，风险参考水平值存在一个点，称为参考点或临界点，在这个点上决定继续进行该项目或终止它（问题太大了）都是可以接受的。

图1－2以图形方式表示了这种情况。如果风险的组合产生问题而导致成本超支及进度延迟，则会有一个水平值，即图中所示的曲线，当超过它时会引起项目终止（阴影区域）。在临界点上，决定继续进行或终止项目都是可以的。

实际上，参考水平很少能表示成如图所示的一条光滑曲线。在大多数情况下，它是一个区域，其中存在很多不确定性（即，基于参考值的组合进行管理决策常常是不可能的）。

因此，在风险评估过程中，我们执行以下步骤： 1.定义项目的风险参考水平值。

2.建立每一组［ri，li，xi］与每一个参考水平值之间的关系。

3.预测一组临界点以定义项目终止区域，该区域由一条曲线或不确定区域所界定。

4.预测什么样的风险组合会影响参考水平值。

更详细的讨论参见专门探讨风险分析的论著（如文献［CHA89、ROW88］）。 1.5风险缓解、监控和管理

这一步的所有风险分析活动都只有一个目的——辅助项目组建立处理风险的策略。一个有效的策略必须考虑三个问题：

·风险避免。 ·风险监控。

·风险管理及意外事件计划。

如果软件项目组对于风险采用主动的方法，则避免永远是最好的策略。这可以通过建立一个风险缓解计划来达到。例如，假设频繁的人员流动被标注为一个项目风险，r0。基于以往的历史及管理经验，人员频繁流动的概率l0被估算为0.7（70％，相当高），而影响x0被预测为对于项目成本及进度有严重的影响（见图1－1）。

为了缓解这个风险，项目管理必须建立一个策略来降低人员流动。可能采取的策略如下：

·与现有人员一起探讨一下人员流动的原因（如，恶劣的工作条件，低报酬，竞争激烈的劳动力市场）。

·在项目开始之前，采取行动以缓解那些在管理控制之下的原因。

·一旦项目启动，假设会发生人员流动并采取一些技术以保证当人员离开时的工作连续性。

·对项目组进行良好组织，使得每一个开发活动的信息能被广泛传播和交流。 ·定义文档的标准，并建立相应的机制，以确保文档能被及时建立。 ·对所有工作进行详细复审，使得不止一个人熟悉该项工作。