软件开发质量和风险的定量监理1

软件开发风险的定量监理

　　很多应用软件项目之所以陷入混乱状态而使项目组人员经常感到疲于奔命，就是因为对风险管理的不重视。在监理过程中也常常如此，很多情况下都是问题发生时才意识到问题的存在。而资源和项目周期的压力，使得项目的相关方不得不在没有很充分准备的情况下仓促应战，而在这种情况下产生的结果往往是不理想的。

　　软件风险监理就是在风险成为影响软件项目成功的威胁之前，识别、着手处理并消除风险的源头。

　　风险关注未来将要发生的事情。那么，什么样的风险会导致软件项目彻底失败呢？改变也是我们所关心的—用户需求、开发技术、目标计算机以及所有其他与项目相关的因素的改变，将会对按时交付和总体成功产生什么影响呢？最后，我们必须抓住选择机会—我们应该采用什么方法和工具？需要多少人员来参与工作？对质量的要求要达到什么程度才是“足够的”？……诸如此类的问题还有很多，这些问题是风险监理最关键的部分。

　　对风险进行定量监理的第一步，就是要识别那些可能将风险带到项目计划中的因素，也就是对风险进行分类。

　　1、项目风险威胁到项目计划。也就是说，如果项目风险变成现实，有可能会拖延项目的进度，且增加项目的成本。

　　项目风险是指潜在的预算、进度、人力(工作人员及组织)、资源、客户、及需求等方面的问题以及它们对软件项目的影响。项目复杂性、规模以及结构不确定性也被定义为项目风险因素。

　　2、技术风险威胁到要开发软件的质量及交付时间。如果技术风险变成现实，则开发工作可能变得很困难或根本不可能。

　　技术风险是指潜在的设计、实现、接口、验证、和维护等方面的问题。此外，规约的二义性、技术的不确定性、陈旧的技术及“先进的”技术也是风险因素。

　　3、组织风险。常见的组织风险是组织内部对目标未达成一致、高层对项目不重视、资金不足或与其他项目有资源冲突等都是潜在的组织风险。

　　4、外部风险。比如法律法规变化、项目相关接口方的情况发生变化，这些事件往往是不可控制的。但要注意的是，一般将不可控制的“不可抗力”不作为风险，而是将它们当作灾难进行防御。

　　风险预测，又称为风险估算，试图从两个方面评估每一个风险—风险发生的可能性或概率，以及如果风险发生后所产生的后果。

　　项目计划者以及其他管理人员和技术人员需要一起执行四个风险预测活动：（1）建立一个尺度，以反映风险发生的可能性；（2）描述风险的后果；（3）估算风险对项目及产品的影响；（4）标注风险预测的整体精确度，以免产生误解。

　　风险表可以给项目管理者、监督者提供一种简单的风险预测技术。风险表的样本如表3所示。

　　在这里，PS指产品/项目规模风险，BU指商业风险，CU是指客户特性风险，TE是指建造技术风险，DE是指开发环境风险，ST是指人员经验与经验风险，……像这样风险可以有许多，在这里就不一一举例了。

　　项目组一开始要在表中的第一列列出所有风险(不管多么细微)。每一个风险在第二列上加以分类。每个风险发生的概率则输入到第三列中。每个风险的概率值可以由项目组成员个别估算，然后将这些单个值求平均，得到一个有代表性的概率值。

　　下一步是评估每个风险所产生的影响。使用表3所述的特性评估每个风险因素，并确定其影响的类别。对四个风险因素--性能、支持、成本及进度的影响类别求平均可得到一个整体的影响值(如果其中一个风险因素对项目特别重要，也可以使用加权求平均值)。



　　在表三中，影响类别取值如下：

　　1-灾难的，2-严重的，3-轻微的，4-可忽略的

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

　　项目监理者研究已排序的表，并定义一条中止线。该中止线(表中某一点上的一条水平线)表示：只有那些在线之上的风险才会得到进一步的关注。而在线之下的风险则需要再评估以完成第二次排序。排序后找出需要关注的风险点，进行处理。可以依次类推完成第三次排序或更多的排序。

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