软件开发项目风险模型分析

摘要:随着产业的发展和软件规模的提高,软件项目开发和使用过程中超支、延时、技术缺陷等现象越来越严重。如何在项目实施的过程中进行有效地评估和预防这些风险,以达到识别和消除不利因素对软件开发的影响,都属于软件项目风险管理问题。该文着重讨论了集中软件开发项目风险模型并对其进行了相关分析。

关键字:软件开发;项目风险;风险模型

中图分类号:TP311文献标识码:A 文章编号:1009-3044(2009)22-00000-00

1 软件项目风险管理概述

1.1 软件项目风险定义

软件开发项目的风险为软件项目在整个生命周期内,由于受各种环境的不确定性因素的影响,实际发生的成本、进度、质量等与预期结果的不利偏差。软件项目的风险具有以下的几个特点:第一,对于项目各组成部分之间的复杂关系,任何个人都不可能彻底地了解。第二,项目各个组成部分之间不是简单的线性关系。第三,项目时刻处于动态变化之中,平衡状态即使出现也只能是短暂的。第四,项目管理者不仅要面对技术和经济问题,还要面临一些非常复杂、非线性和不确定性极高的问题。

1.2 软件项目风险管理

软件项目风险管理是对有关软件项目、软件开发过程和软件产品损失的可能性,它涉及操作过程、组织过程和合同等相关参数,主要包括资源制约、外界因素、供应商关系或合同制约的管理。

Boehom认为软件风险管理指的是“试图以一种可行的原则和实践,规范化地控制影响项目成功的风险,其目的是辨识、描述和消除风险因素,以免它们威胁软件的成功运作。”Hall认为软件风险管理是对影响软件项目、过程或产品的风险进行估计和控制的实践过程,该实践围绕目标设定、项目计划、执行、度量、改进和发现新信息六大科目展开。SEI在软件工程体系中提出软件风险管理是有关管理威胁开发软件产品计划风险的概念、方法和技术,包括风险辨识、分析、监控、减轻和计划。具体分成三个知识单元:风险分析、风险管理计划和风险监控。通过以上软件风险项目管理的不同观点,可以归纳出软件风险管理是一个为了避免和减小软件项目失败的风险,对软件风险进行识别、分析、计划、监控的管理过程。

2 经典软件项目风险管理模型

2.1 Boehm体系

Boehm于1991年详细描述了他的思想体系,其中把风险管理活动分成两大阶段,每一阶段含有三个步骤:第一阶段,风险估计阶段。此阶段可分为:风险辨识、风险分析,风险排序三个步骤。第二,风险控制阶段。此阶段可分为:编制风险管理计划,风险解决,风险监督三个步骤。

每一步骤都备有不少的相关实现技术,例如,风险辨识中给出了10大软件风险因素清单。同时还推荐了各个因素的相关处理意见及方法。从该清单出发,经理和工程师们能够进一步细化风险因素,并加以评估和化解。

2.2 Charette体系

1989年Charette设计了称为风险分析和管理的体系,两大阶段分别为分析阶段和管理阶段,每个阶段都内含三个过程,风险分析阶段分为:辨识、估计、评价;风险管理阶段分为:计划、控制、监督。每个阶段内的过程活动并不能完全分离,有相互重叠甚至交错反复的现象。Charette同时为各个过程提供了相应的战略思路、方法模型和技术手段,特别在风险的辨识和估计过程中,其中大多数是运筹学、系统科学中的模型应用。

2.3 SEI体系

SEI 在软件风险管理方面作了大量的工作,1999年前后分别以技术报告和手册等形式公布了基于分类的风险辨识(TBQ)、连续风险管理(CRM)、软件风险评估(SRE)、软件采购风险管理成熟度模型(RM-CMM)和团队风险管理(TRM)。完整思想是想以TRM为框架,贯穿 CRM 思想,依托SRE过程,以TBQ 等为基本手段,配合软件能力成熟度模型(SW-CMM)和(SA-CMM)完成软件的风险管理。

其中 CRM 思想如上图1所示,SRE 过程分为合同签订、风险辨识和分析(RI&A)、中间报告、缓和战略计划(MSP)和最终报告 5 个阶段。SA-CMM 与 SW-CMM 类似,前者是对获取软件产品或服务一方组织管理能力的描述,后者是对开发组织过程能力的描述。RM-CMM配合SA-CMM模型的5个成熟度等级和关键过程域(KPA),也提出了风险管理关键过程域(RM-KPA)的概念。RM-KPA 的结构包括目标、为达成目标的活动和支持活动顺利开展的制度化特征。其中目标有3个:1)鼓励项目全体人员参与到所遇风险的辨识和缓和中来;2)在所有的项目职责中明确项目团队软件采购过程的风险辨识、分析和缓和;3)项目评审已识别出风险的状态。

2.4 Hall体系

Hall女士受SEI连续过程改进和PDCA质量管理方法的启发,提出了“6-学科模型”(Six-Discipline, 6-D),如图2。图中E代表预想(Envision),这是把思想转换为目标和目的的学科,用于研究软件产品的远期规划;P代表计划(Plan),是要为软件目标分配资源的学科;W代表工作(Work),指生产产品计划的执行,工作的伴生产品是状态和不确定性;M代表度量(Measurement),指比较期望值和实际值的学科,两个值的差异用于调整项目计划;I 代表改进(Improve)是指从过去的经验中学习的学科,它通过分析基准和项目度量结果,找出改进的方向;D 表示发现(Discover),是指要预知未来的学科,是通过对工作中不确定性的评价和困惑的思考,思考机会和风险的均衡,预先指导计划和规划的改变。

3 软件项目风险管理模型分析

以上4种典型的软件项目风险管理体系各有特色,较早出现的两套体系(Boehm和Charette体系)偏重于理论结构的完善,不妨称为理论体系,后两套体系则偏重于实践应用,不妨称为实践体系。总体来说,理论体系结构完整,内容完善,并附带有与结构和内容相配套的不少方法和技术。体系构建者旁征博引,着重说明了为什么要这样做的道理,阐明了如何从其它学科,如运筹学、决策理论等中借用思想、方法和工具。但研究范围局限于软件项目的核心风险管理,研究对象主要是开发技术风险,很少论及实现体系思想所需要的保障措施,基本上只站在开发商一方讨论风险管理问题,操作性也显得不足,整体上看思想性大于技术性,对实施过程中人所发挥的作用估计不足,从一定程度上说有理想化的成份。

Boehm先生一直关注软件项目的风险管理问题,曾提出了围绕风险管理开展软件开发的方法,即螺旋模型,还从经济学角度论证了软件开发问题,并引入了构造型成本模型(COCOMO)。他最突出的贡献之一是建立了软件风险管理研究领域,提出了头10大风险清单的风险辨识思想,尽管有缺乏动态性的不足,但确实对后续研究产生了很大的影响,只是他的体系在计算风险当量时没有考虑效用因素。

Charette先生的体系从结构上看与Boehm体系只在用词不同,本质上区别不大(两者同在1989年独立提出软件风险管理体系)。Charette 的体系中认识到了风险的投机性,也从步骤上强调了对组合风险的评价。但就如何获取单一风险估计值和组合风险分析效果,还缺乏可行的手段和措施,在风险的效用问题上只考虑了目标效用,而没有考虑到不同项目参与人的效用。另外,与Boehm一样,也没有考虑点概率值在实践应用中的不足。

两套实践体系最明显的特点是考虑到了体系的可操作性,体系中的理性思考以指导实践步骤为主要目的,基本上摒弃了复杂的数学运算,强调与软件开发过程的紧密结合,强调把划分好的任务落实到人的重要性,还绘制出了关键的风险管理实用表格,注意到了风险管理数据的形成和利用问题。但为保证复杂体系的一致实施,需要对实施人员进行专业化培训。SEI体系明确提出了软件采购方在项目风险管理中的地位和作用,注重发挥和要求采购方参与到风险管理中来。该体系基于风险分类结构辨识风险,组织了194个揭示风险的问题,设计了各项实施措施的场景,有些活动甚至详细规定到了需要在多少分钟内完成。为了简化风险管理的实施成本和实施难度,该体系将风险发生的可能性定义为非常可能、可能和不可能3种,把风险后果定义为灾难性的、严重的、次要的和可以忽略的4级,两项因素组合成的风险当量简化为高、中和低 3档结果,不过这种做法在降低管理成本的同时也降低了管理精度。SEI体系的管理步骤多于技术、方法和工具,没有涉及到组合风险的处理,可以看出其主体思想是以简单的学术背景要求、方便的日常事务应用,再加上严格的管理规定达成IT项目风险管理效果。所以尽管技术要求不高,但实施成本不低,因此更适合于大型公司或开发大型项目时采用。但不足的是对如何取得预想方案中风险和机会的均衡重视不够,基本思路是改进项目管理,带动风险管理,管理范围仍以核心软件风险管理为主。也可以认为上述4套体系归属两个风险管理层次,一个是研究如何辨识、处理和消除风险的学科,一个是试图辨识并采取规避措施的行为或过程。照此理解前两套体系属学科层,后两套体系属过程层。以上4套体系总体都偏重解决开发活动内部的技术风险,在风险控制手段上也往往着眼于降低风险发生的可能性,而对如何规避风险后果措施不多。

参考文献:

[1] 黄梯云.管理信息系统[M].第二版.北京:高等教育出版社, 1999.

[2] 薛华成.管理信息系统[M].第三版.北京:清华大学出版社, 1999.

[3] 郑人杰.软件工程(高级)[M].北京:清华大学出版社, 1999.

[4] 张海藩.软件工程导论[M].北京:清华大学出版社, 1987.