软件开发过程中的风险分析

 风险分析实际上是4个不同的活动： 风险识别，风险估计，风险评价和风险驾驭。

(1) 风险识别

风险识别就是要系统地确定对项目计划(估算、进度、资源分配)的威胁，通过识别已知的或可预测的风险，就可能设法避开风险或驾驭风险。

① 风险类型

用各种不同的方法对风险进行分类是可能的。从宏观上来看，可将风险分为项目风险、技术风险和商业风险。

项目风险威胁到项目计划，一旦项目风险成为现实，可能会拖延项目进度，增加项目的成本。项目风险是指潜在的预算、进度、个人(包括人员和组织)、资源、用户和需求方面的问题，以及它们对软件项目的影响。项目复杂性、规模和结构的不确定性也构成项目的(估算)风险因素。

技术风险威胁到待开发软件的质量和预定的交付时间。如果技术风险成为现实，开发工作可能会变得很困难或根本不可能。技术风险是指潜在的设计、实现、接口、检验和维护方面的问题。此外，规格说明的多义性、技术上的不确定性、技术陈旧、最新技术(不成熟)也是风险因素。技术风险之所以出现是由于问题的解决比我们预想的要复杂。

商业风险威胁到待开发软件的生存能力。5种主要的商业风险是：

•  建立的软件虽然很优秀但不是市场真正所想要的（市场风险）；
•  建立的软件不再符合公司的整个软件产品战略（策略风险）；
•  建立了销售部门不清楚如何推销的软件；
•  由于重点转移或人员变动而失去上级管理部门的支持（管理风险）；
•  没有得到预算或人员的保证（预算风险）。

特别要注意，有时对某些风险不能简单地归类，而且某些风险事先是无法预测的。

② 风险项目检查表

识别风险的一种最好的方法就是利用一组提问来帮助项目计划人员了解在项目和技术方面有哪些风险。因此，Boehm建议使用一个“风险项目检查表”，列出所有可能的与每一个风险因素有关的提问。从如下几个方面识别已知的或可预测的风险。

•  产品规模——与待开发或要修改的软件的产品规模(估算偏差、产品用户、需求变更、复用软件、数据库)相关的风险。
•  商业影响——与管理和市场所加之的约束(公司收益、上级重视、符合需求、用户水平、产品文档、政府约束、成本损耗、交付期限)有关的风险。
•  客户特性——与客户的素质(技术素养、合作态度、需求理解)以及开发者与客户定期通信(技术评审、通信渠道)能力有关的风险。
•  过程定义——与软件过程定义与组织程度以及开发组织遵循的程度相关的风险。
•  开发环境——与用来建造产品的工具(项目管理、过程管理、分析与设计、编译器及代码生成器、测试与调试、配置管理、工具集成、工具培训、联机帮助与文档)的可用性和质量相关的风险。
•  建造技术——与待开发软件的复杂性及系统所包含技术的“新颖性”相关的风险。
•  人员数量及经验——与参与工作的软件技术人员的总体技术水平(优秀程度、专业配套、数量足够、时间窗口)及项目经验(业务培训、工作基础)相关的风险。

③ 全面评估项目风险

下面的问题是通过调查世界各地有经验的软件项目管理者而得到的风险数据导出的。这些问题根据它们对于项目成功的相对重要性顺序排列。

•  高层的软件和客户的管理者是否正式地同意支持该项目？
•  终端用户是否热心地支持该项目和将要建立的系统�M产品？
•  软件工程组和他们的客户对于需求是否有充分的理解？
•  客户是否充分地参与了需求定义过程。
•  终端用户的期望是否实际？
•  项目的范围是否稳定？
•  软件工程组是否拥有为完成项目所必须的各种技术人才。
•  项目的需求是否稳定？
•  项目组是否具有实现目标软件系统的技术基础和工作经验？
•  项目组中的人员数量对于执行项目的任务是否足够？
•  所有客户是否都一致赞同该项目的重要性并支持将要建立的系统�M产品

只要对这些问题的回答有一个是否定的，就应当制定缓解、监控、驾驭的步骤以避免项目失败。项目处于风险的程度直接与对这些问题否定回答的数目成比例。

④ 风险构成和驱动因素

美国空军在一本关于如何识别和消除风险的手册中给出如何标识影响风险构成的风险驱动因素。风险构成有如下几种：

•  性能风险——产品是否能够满足需求且符合其使用目的的不确定的程度。
•  成本风险——项目预算是否能够维持的不确定的程度。
•  支持风险——软件产品是否易于排错、适应及增强的不确定的程度。
•  进度风险——项目进度是否能够维持及产品是否能够按时交付的不确定的程度。

(2) 风险估计

风险估计从两个方面估价每一种风险。一是估计一个风险发生的可能性。一是估价与风险相关的问题出现后将会产生的结果。通常，项目计划人员与管理人员、技术人员一起，进行4种风险估计活动：建立一个尺度来表明风险发生的可能性；描述风险的后果；估计风险对项目和产品的影响；指明风险估计的正确性以便消除误解。

① 建立风险表

风险表的示例如表9.16所示。第1列列出风险(不论多么细微)，可以利用风险项目检查表的条目来给出。每一个风险在第2列加以分类，在第3列给出风险发生概率，第4列是利用表9.15给出的对风险产生影响的评价。这要求对4种风险构成(性能、支持、成本、进度)的影响类别求平均值，得到一个整体的影响值。

风险出现概率可以使用从过去项目、直觉或其它信息收集来的度量数据进行统计分析估算出来。例如，由45个项目中收集的度量表明，有37个项目遇到的用户要求变更次数达到2次。 作为预测，新项目将遇到的极端的要求变更次数的概率是 37／45＝0.82，因而，这是一个极可能的风险。

一旦完成了风险表前四列的内容，就可以根据概率和影响进行排序。高发生概率和高影响的风险移向表的前端，低概率低影响的风险向后移动，完成第一次风险优先排队。

项目管理人员研究已排序的表，定义一条截止线(Cutoff line)，这条截止线(在表中某一位置的一条横线)表明，位于线上部分的风险将给予进一步关注而位于线下部分的风险需要再评估以完成第二次优先排队。

参看图9.10，风险影响和发生概率对驾驭参与有不同的影响。一个具有较高的影响但发生概率极低的风险应当不占用很多有效管理时间。然而，具有中等到高概率的高影响的风险和具有高概率的低影响的风险，就必须进行风险的分析。

② 风险评价

在进行风险评价时，可建立一系列三元组：[ ri, li, xi ]，其中，ri是风险，li是风险出现的可能性(概率)，而xi是风险产生的影响。在做风险评价时，应进一步审查在风险估计时所得到的估计的准确性，尝试对已发现的风险进行优先排队，并着手考虑控制和�M或消除可能出现风险的方法。

在做风险评价时常采用的一个非常有效的方法就是定义风险参照水准。对于大多数软件项目来说，性能、支持、成本、进度就是典型的风险参照水准。就是说，对于成本超支、进度延期、性能降低、支持困难，或它们的某种组合，都有一个水准值，超出它就会导致项目被迫终止。如果风险的某种组合所产生的问题导致一个或多个这样的参照水准被超出，工作就要中止。在软件风险分析的上下文中，一个风险参照水准就有一个点，叫做参照点或崩溃点。在这个点上，要公平地给出可接受的判断，看是继续执行项目工作，还是终止它们（出的问题太大）。

图9.11用图示表示这种情况。如果因为风险的某一组合造成问题，导致项目成本超支和进度延迟，一系列的参照点构成一条曲线，超出它时就会引起项目终止(黑色阴影区域)。在参照点上，要对做出是继续进行还是终止的判断公正地加权。            

实际上，参照点能在图上被表示成一条平滑的曲线的情况很少。在多数情况中，它是一个区域，在此区域中存在许多不确定性的范围，在这些范围内想做出基于参照值组合的管理判断往往是不可能的。

因此，在做风险评价时，我们按以下步骤执行：

•  定义项目的各种风险参照水准；
•  找出在各 [ ri, li, xi ] 和各参照水准之间的关系；
•  预测一组参照点以定义一个项目终止区域，用一条曲线或一些不确定性区来界定；
•  预测各种复合的风险组合将如何影响参照水准。

(3) 风险驾驭和监控

为了执行风险驾驭与监控活动，必须考虑与每一风险相关的三元组(风险描述、风险发生概率、风险影响)，它们构成风险驾驭(风险消除)步骤的基础。例如，假如人员的频繁流动是一项风险ri，基于过去的历史和管理经验，频繁流动可能性的估算值li为0.70，而影响xi的估计值是：项目开发时间增加15％，总成本增加12％。为了缓解这一风险，项目管理必须建立一个策略来降低人员的流动造成的影响。可采取的风险驾驭步骤如下：

•  与现有人员一起探讨人员流动的原因(如，工作条件差，收入低，人才市场竞争等)；
•  在项目开始前，把缓解这些原因的工作列入管理计划中。
•  当项目启动时，做好人员流动会出现的准备。采取一些技术以确保人员一旦离开后项目仍能继续；
•  建立良好的项目组织和通信渠道，以使大家都了解每一个有关开发活动的信息；
•  制定文档标准并建立相应机制，以保证文档能够及时建立；
•  对所有工作组织细致的评审，使大多数人能够按计划进度完成自己的工作；
•  对每一个关键性的技术人员，要培养后备人员。

这些风险驾驭步骤带来了额外的项目成本。例如，培养关键技术人员的后备需要花钱、花时间。因此，当通过某个风险驾驭步骤而得到的收益被实现它们的成本超出时，要对风险驾驭部分进行评价，进行传统的成本－效益分析。

对于一个大型的软件项目，可能识别30－40项风险。如果每一项风险有3－7个风险驾驭步骤，那么风险驾驭本身也可能成为一个项目。 正因为如此，我们把Pareto的80／20规则用到软件风险上来。经验表明，所有项目风险的80％(即可能导致项目失败的80％ 的潜在因素)能够通过20％ 的已识别风险来说明。在早期风险分析步骤中所做的工作可以帮助计划人员确定，哪些风险属于这20％之内。由于这个原因，某些被识别过、估计过及评价过的风险可以不写进风险驾驭计划中，因为它们不属于关键的20％（具有最高项目优先级的风险）。

风险驾驭步骤要写进风险缓解、监控和驾驭计划RMMM（Risk Mitigation Monitoring and Management Plan）。RMMM记叙了风险分析的全部工作，并且做为整个项目计划的一部分为项目管理人员所使用。

一旦制定出RMMM且项目已开始执行，风险缓解与监控就开始了。风险缓解是一种问题回避活动，风险监控是一种项目追踪活动，它有三个主要目标：

•  判断一个预测的风险事实上是否发生了；
•  确保针对某个风险而制定的风险消除步骤正在合理地使用；
•  收集可用于将来的风险分析的信息。

多数情况下，项目中发生的问题总能追踪到许多风险。风险监控的另一项工作就是要把“责任”（什么风险导致问题发生）分配到项目中去。

风险分析需要占用许多有效的项目计划工作量。识别，估计，评价，管理和监控都需要时间，但这些工作量花得值得。孙子曾经说过：“知己知彼，百战不殆。”

更多软件工程文章：

• 软件开发过程中的风险分析
• 软件开发的过程设计
• 软件设计的过程
• 软件开发 ISO 9000系列标准的特点
• 软件开发的质量认证与管理