关于测试成本不确定软件模型的风险分析研究

软件开发风险评估方式研究摘要：当今人们的生活中处处充斥着软件,软件已经成为了我们生活、工作、学习的一部分了,但是各种各样的软件风险却困扰着我们,给我们的生活造成了很大的不便。

这其中很大一部分原因是在软件开发过程中没有一个完善的风险评估体系。

传统的软件开发风险评估方式侧重于定量的计算,但是软件之中的风险有很大的不确定性,有些风险也不可能得到确切的数据,证据理论分析方法就弥补了这方面的不足。

本文首先介绍了传统的软件开发风险评估方式,然后说明了为什么要使用证据理论来进行风险分析,最后是从证据理论视角进行的具体风险分析。

关键词：软件开发;风险评估;证据理论计算机技术的高速发展,随之而来的是各种软件的爆发式增长,软件已经成为了我们生活中不可或缺的一部分,在这种情况下软件开发工作就显得尤为重要。

但是,软件在开发以及最后使用过程中存在着一定的风险,这些风险的存在造成了使用者的不便,也产生了很多的额外成本,这与当今人们对软件质量日益提高的需求极为不符。

传统的软件风险评估多是借助于计量模型,利用一定的数据来进行定量的计算,但是软件使用中的风险存在着很多的额不确定性,各种各样的因素都会影响到软件效用的发挥,一些因素也不能转化成数据而直接进行计算,这些缺点导致传统的软件开发的风险评估方式已经不能满足人们希望更精确地评估风险的要求了。

证据理论是一种新兴起的分析方法,它是一种基于不确定因素的定性的分析方法,这几年在软件风险评估方面得到了很大的应用,它虽然不能给出精确的风险值,但是可以给出具体方案的一个可行的实施范围,这对现代软件开发风险评估方式来说是一大进步,它取代了传统软件风险评估要求在不确定因素中选择确定性数据定量计量的不足。

一、传统软件开发风险评估的方式软件开发工作自身是一项智力投入高,具有创新性的研究性活动,而且其研究的也不是具有实物形态的产品,而是各种各样的代码与数据库。

软件开发过程中存在着很多的风险,这与软件开发自身所具有的特殊性质有着密切的关系,软件开发的客观性和普通性、不确定性、行为的相关性、多样性以及对称性决定了软件开发过程中风险的不确定性与来源广泛性,如果根据风险的本质来进行分类的话,大概分成三个种类：产品自身风险、项目特殊化风险以及开发环境的风险,对这各种各样的风险有着很多的评估方式。

软件开发项目风险模型分析作者：张云峰来源：《电脑知识与技术(学术交流)》2009年第22期摘要:随着产业的发展和软件规模的提高,软件项目开发和使用过程中超支、延时、技术缺陷等现象越来越严重。

如何在项目实施的过程中进行有效地评估和预防这些风险,以达到识别和消除不利因素对软件开发的影响,都属于软件项目风险管理问题。

该文着重讨论了集中软件开发项目风险模型并对其进行了相关分析。

关键字:软件开发;项目风险;风险模型中图分类号:TP311文献标识码:A 文章编号:1009-3044(2009)22-00000-001 软件项目风险管理概述1.1 软件项目风险定义软件开发项目的风险为软件项目在整个生命周期内,由于受各种环境的不确定性因素的影响,实际发生的成本、进度、质量等与预期结果的不利偏差。

软件项目的风险具有以下的几个特点:第一,对于项目各组成部分之间的复杂关系,任何个人都不可能彻底地了解。

第二,项目各个组成部分之间不是简单的线性关系。

第三,项目时刻处于动态变化之中,平衡状态即使出现也只能是短暂的。

第四,项目管理者不仅要面对技术和经济问题,还要面临一些非常复杂、非线性和不确定性极高的问题。

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

Boehom认为软件风险管理指的是“试图以一种可行的原则和实践,规范化地控制影响项目成功的风险,其目的是辨识、描述和消除风险因素,以免它们威胁软件的成功运作。

”Hall认为软件风险管理是对影响软件项目、过程或产品的风险进行估计和控制的实践过程,该实践围绕目标设定、项目计划、执行、度量、改进和发现新信息六大科目展开。

SEI在软件工程体系中提出软件风险管理是有关管理威胁开发软件产品计划风险的概念、方法和技术,包括风险辨识、分析、监控、减轻和计划。

不确定性分析与风险分析一、不确定性分析项目经济评价所采用的基本变量都是对未来的预测和假设，因而具有不确定性。

通过对拟建项目具有较大影响的不确定性因素进行分析，计算基本变量的增减变化引起项目财务或经济效益指标的变化，找出最敏感的因素及其临界点，预测项目可能承担的风险，使项目的投资决策建立在较为稳妥的基础上。

二、风险分析风险是指未来发生不利事件的概率或可能性。

投资建设项目经济风险是指由于不确定性的存在导致项目实施后偏离预期财务和经济效益目标的可能性。

经济风险分析是通过对风险因素的识别，采用定性或定量分析的方法估计各风险因素发生的可能性及对项目的影响程度，揭示影响项目成败的关键风险因素，提出项目风险的预警、预报和相应的对策，为投资决策服务。

经济风险分析的另一重要功能还在于它有助于在可行性研究的过程中，通过信息反馈，改进或优化项目设计方案，直接起到降低项目风险的效果。

风险分析的程序包括风险因素识别、风险估计、风险评价与防范应对。

三、不确定性与风险分析的区别与联系不确定性分析与风险分析既有联系，又有区别，由于人们对未来事物认识的局限性，可获信息的有限性以及未来事物本身的不确定性，使得投资建设项目的实施结果可能偏离预期目标，这就形成了投资建设项目预期目标的不确定性，从而使项目可能得到高于或低于预期的效益，甚至遭受一定的损失，导致投资建设项目“有风险”。

通过不确定性分析可以找出影响项目效益的敏感因素，确定敏感程度，但不知这种不确定性因素发生的可能性及影响程度。

借助于风险分析可以得知不确定性因素发生的可能性以及给项目带来经济损失的程度。

不确定性分析找出的敏感因素又可以作为风险因素识别和风险估计的依据。

四、不确定性分析主要内容盈亏平衡分析是指项目达到设计生产能力的条件下,通过盈亏平衡点（Break-Even-Point, BEP）分析项目成本与收益的平衡关系。

敏感性分析是投资建设项目评价中应用十分广泛的一种技术，用以考察项目涉及的各种不确定因素对项目基本方案经济评价指标的影响，找出敏感因素，估计项目效益对它们的敏感程度，粗略预测项目可能承担的风险，为进一步的风险分析打下基础（敏感度系数、临界点分析）。

第22卷第5期Vol.22No.5控　制　与　决　策Cont rolandDecision2007年5月 May 2007收稿日期:2006201207;修回日期:2006204209.基金项目:国家自然科学基金项目(70272002).作者简介:潘春光(1974—),男,济南人,讲师,博士生,从事软件项目风险管理、决策分析技术的研究;陈英武(1963—),男,湖南益阳人,教授,博士生导师,从事公共管理、项目管理等研究. 文章编号:100120920(2007)0520481206软件项目风险管理理论与方法研究综述潘春光,陈英武,汪　浩(国防科学技术大学信息系统与管理学院,长沙410073)摘　要:软件项目风险管理是软件工程的重要分支,也是项目管理和决策研究中的热点问题.为此,简要介绍了软件项目风险管理的相关基本概念,阐述了软件项目风险管理的框架体系和研究方法,并讨论了其各自的优缺点.据此对该学科的研究发展趋势作了展望.关键词:软件项目;风险管理;风险分析;风险控制中图分类号:O157.5 文献标识码:AOvervie w of the study on theories and methods of soft w are projectrisk m anagementPA N Chun 2g uan g ,C H EN Yi ng 2w u ,W A N G H ao(College of Information System and Management ,National University of Defense Technology ,Changsha 410073,China.Correspondent :PAN Chun 2guang ,E 2mail :chunguangpan @ )Abstract :As an important branch of software engineering ,software project risk management (SPRM )is a hotspot in project management and decision 2making.The conceptions of SPRM are introduced generally.An overview of the study on theories and methods in this field is made and the merits and defects are also discussed.The prospect of this subject is presented.K ey w ords :Software project ;Risk management ;Risk analysis ;Risk control1　引 言 软件项目风险管理作为一门学科,出现于上世纪80年代末.经过近30年的发展,已从理论、方法乃至实践上都取得了一定的进展.目前,随着软件工程技术的进步和软件企业的不断成熟,其研究已成为软件工程和项目管理中的热点问题之一.本文对近年来软件项目风险管理理论与方法的研究进展情况进行综述,分析了各种理论体系和方法的特点和不足,并对该学科的发展趋势作了展望.2　软件项目风险管理的有关概念 风险的概念最早出现于19世纪末的西方经济领域,目前已广泛应用于社会学、经济学、工程学、环境学等领域.风险一词在不同领域有不同的界定,目前尚无统一的定义[1].但一般认为风险概念应包含以下几方面内涵[1,2]:1)风险是指事物发生发展过程中某种客观存在的不确定性;2)这种不确定性对主体的决策和价值目标构成了潜在威胁或可能造成损失;3)不同主体对同样风险的承受能力与收益大小、投入多少、项目活动的主体地位和拥有的资源有关.在软件工程领域,人们一直试图将软件开发活动工程化,并通过借鉴工程项目的管理办法来解决软件项目中出现的风险问题.对软件项目风险概念的理解源于其他工程项目风险管理,并经过一定的讨论和改进.如最早研究软件项目风险管理的美国国防部,把风险定义为[3]:在预定成本、工期和技术约束下,可能无法达到全面计划目标的度量指标,它包含两部分:1)无法达到具体结果的概率(或可能性);2)达不到那些结果的后果(或影响).Boehm 等将这两部分归结为“风险暴露”[3,4],用公式表示为R E =P (U O )*L (U O ).(1)其中:R E 指风险或风险造成的影响,P (U O )表示令人不满意结果发生的概率,L (U O )表示不利结果可能产生的破坏程度.上述概念未指明其主体,即是什 控 制 与 决 策第22卷么造成的不利影响,所以有些文献又将风险主体表示为“场景”.如Charette将风险定义为一个三元组[5]Risk={(s i,l i,v i)—i=1,2,…,n},(2)分别表示风险所处的环境描述、可能概率和风险发生时的后果.然而该定义仍存在缺陷,它将低概率高损失的情形与高概率低损失的情形等同起来.为此,Kumamoto等又作了扩展,将风险定义为一个四元组[6]Risk={(s i,o i,l i,v i)—i=1,2,…,n},(3)其中o i表示对第i个场景造成后果严重性的度量.经过一系列补充,人们对软件风险的概念逐渐加深,为理论研究奠定了基础.风险管理是指辨识、分析和控制风险的活动,这组活动不是孤立的,而是一组系统化、持续化的过程[7].软件项目风险管理是指贯穿于软件项目生命周期,保证项目按计划进行的策略、方法、技术和工具的集合,它含有风险辨识、评估、排序、计划、监督和控制活动,并成为软件项目管理的主要部分[8].3　软件项目风险管理的框架体系 从软件项目风险管理的发展历史看,Boehm于1989年出版的专著《软件风险管理》[3],奠定了该领域的理论基础.在随后近30年中,又陆续出现了几种框架体系.现总结和比较如下.3.1　Boehm和Charette的风险管理框架Boehm在《软件风险管理》中,将软件项目风险管理分为风险评估和风险控制两大部分,其中风险评估又分为风险识别、风险分析和风险的优先级排序,风险控制又分为风险管理计划、风险解决和风险监控.软件项目风险管理的另一位创始人Charette构建的风险管理框架[5],则直接将其分为风险分析和风险管理两部分,其中风险分析包括识别、估算和评价,风险管理包括计划、控制和监控.二者的理论框架如表1所示.表1　Boehm和Charette的风险管理框架Boehm的风险管理框架Charette的风险管理框架风险评估风险识别风险分析风险优先级排序风险分析风险识别风险估算风险评价风险控制风险管理计划风险解决风险监控风险管理风险计划风险控制风险监控 从本质上讲,二者风险管理框架基本相同.从内容上看,与其他工程项目风险管理也没有实质性差别.3.2　Higuera和H aimes的持续风险管理框架模型Higuera和Haimes提出的软件项目风险管理框架,是美国卡内基・梅隆大学软件工程研究所(SEI)风险管理体系中的一部分.该体系将风险管理划分为风险识别、分析、计划、跟踪、控制5个步骤,风险管理的方式是连续循环的,其核心是风险沟通.它要求在项目生命期的所有阶段都关注风险管理,即所谓持续风险管理(CRM)框架模型[9,10](见图1).图1　SEI的持续风险管理框架模型SEI的模型在Boehm和Charette的模型基础上有所改进,注重了软件项目的过程特点.但这一模型只是在理论上对风险管理的过程有了初步认识,而如何把风险管理演绎成一个动态、持续的风险管理过程,未作详细阐述.3.3　H all的六学科模型Hall的六学科风险管理模型[11](见图2),将风险管理分解为6个学科.其中:E代表预想,是把思想转化为目标的学科,用于研究软件产品的远期规划;P代表计划,是为软件目标分配资源的学科;W 代表工作,是指产品计划的执行;M代表度量,是比较期望值和实际值的学科,两个值的差异用于调整项目计划;I代表改进,是从过去经验中学习的学科,它通过分析基准和项目度量结果,找出改进的方向;D代表发现,是预知未来的学科,它通过对不确定性的评价和对困惑的思考,考虑机会和风险的均衡,预先指导计划和规划的改变.图2　H all的六学科风险管理模型Hall的六学科模型考虑了风险管理与项目管理的结合,注重风险的度量和控制,是理论与实践相结合的有益尝试.不足之处是对如何取得预想方案中风险和机会的均衡重视不够.其基本思路是改进284第5期潘春光等:软件项目风险管理理论与方法研究综述 项目管理,带动风险管理,管理范围仍以核心风险管理为主.3.4　基于CMM/CMMI的软件项目风险管理框架文献[12,13]提出了基于CMM I的软件项目风险管理框架,对软件项目风险管理理论作了进一步研究和扩展.能力成熟度模型(CMM)是SEI主持研发的一套评估软件能力和成熟度的标准.该标准基于众多专家的经验,侧重于开发过程的管理,是目前国际上流行的软件生产过程标准和软件企业成熟度等级认证标准.CMM主要用5个不断进化的层次来表达,即初始级、可重复级、已定义级、已管理级和优化级,项目风险管理被集成在第3级水平.SEI将CMM扩展为能力成熟度模型集成(CMM I),从内容和特征上对CMM进行完善.在CMM I中,风险管理作为第3级中的一个独立的关键过程域,是软件工程管理的一个重要方面,体现了风险管理的过程特点,从而使在过程中进行风险管理的原则得以真正体现[14].基于CMM/ CMM I的软件项目风险管理的研究,推动了风险管理理论与以软件过程改进为主导的软件工程实践的融合,使软件项目风险管理朝着可预测、有规律、可量化的管理方向发展.4　软件项目风险管理的研究方法、技术和工具 软件项目风险管理发展近30年中,出现了不少方法、技术和工具.这些成果大多以系统整体的形式出现,并贯穿于风险识别、评估、分析和控制的全过程,各方法和技术之间也有交叉,并因阐述的角度不同而有所侧重.下面就其主要研究成果进行简要评述.4.1　软件项目风险识别方法风险识别是任何风险管理活动的起点.从已有成果看,软件项目风险识别的研究方法大致有以下几种:1)风险清单法.Boehm给出了top10风险序列[3],并提出了顶级十大风险源清单[6].随后,他指出在软件项目开发生命期的每个重要阶段,都可进行top10风险清单的调查和修改,并将风险管理加入软件项目开发生命期模型.Boehm还提出了软件项目开发期的螺旋式模型,使项目管理人员可对软件项目进行动态风险追踪.Barki等通过总结列出了35项风险变量[15];Jones描述了60项最常见的风险因素[16].这些成果对于开展风险识别、提供风险源素材具有很大的帮助.2)风险识别法(TB I).Marvin等提出的基于分类的风险识别法[17],主要是从项目分类学的角度考虑风险,对项目的风险项进行分类,从单纯的清单列表走向由分类树与问卷识别过程的统一,从而使软件项目风险项具有结构性的特点.另外,它也秉承了动态管理的特点,使风险识别及后续处理有计划、分步骤、周期性地在项目生命期内进行.3)基于分类的问卷调查表法(TBQ)[17].该方法是由专家根据项目特点设计风险管理问卷调查表,对企业有关人员进行问卷调查,并根据调查结果对数据进行统计分析.文献[18]在问卷调查的基础上提出一种簇分析方法,对507个软件项目管理人员进行问卷调查.文献[19]在此基础上进一步扩展,提出一种软件风险和性能的层次模型,并对调查结果作了统计分析.4.2　网络分析模型网络分析技术在项目风险管理中经常使用,软件项目风险管理中很多方法和工具都借鉴了传统的网络技术.其研究方法主要有以下几种:1)PER T/CPM,GER T和V ER T.PER T(计划评审技术)主要是针对项目进度风险进行评估,通常要求各随机事件都服从三点分布.在实践中,这一假定往往无法满足,这时一般可与蒙特卡洛仿真联合使用.GER T(图形评审技术)可处理活动间的前后逻辑关系受活动结果支配的情况,其活动及活动的先后次序均为随机变量.它既能评估进度风险,又能评估成本和质量等风险.V ER T(风险评审技术)是以管理系统为对象、以随机网络仿真为手段的定量风险分析技术.它可根据每项活动的性质,在网络节点上设置多种输入和输出逻辑功能,使网络模型能充分反映实际过程的逻辑关系和随机约束.这类技术最为常用,在软件项目风险管理中多有引入,如文献[20222]等.2)关键链技术.G oldratt将其提出的制约理论引入项目管理,提出了以关键链取代关键路径的思想.他出版了企业管理专著《关键链》[23],提出了关键链项目管理(CCPM).文献[24]论述了CCPM在软件工程中应用的可行性,文献[25]将关键链技术与系统动力学模型相结合,对多个软件项目进行仿真,并给出了仿真结果.3)贝叶斯置信网络(BBN)模型.BBN是人工智能领域的一种概率推理方法,可描述不确定因素之间的表示和推理.文献[26]应用BBN对软件项目进行风险识别、预测和动态监控,并对项目资源进行动态调整,给出了仿真实例和结果,具有一定的参考价值.4)Pet ri网技术.Pet ri网是研究离散事件动态384 控 制 与 决 策第22卷系统的理论工具之一,它具有并行、并发、同步等特性,适合于描述软件开发过程,在软件工程领域中应用较广[27].5)其他网络模型.这类模型一般是研究人员自行设计的特殊网络模型,如文献[28]提出的设计网模型,文献[29231]提出的软件项目管理网络模型等,对软件项目的并发和迭代现象进行建模和仿真研究.需要说明的是,网络分析模型往往与系统仿真技术结合在一起使用.仿真技术能使网络模型中的不确定性得以量化,是风险管理中的基本技术之一.4.3　系统动力学仿真技术以上总结的各种网络分析模型,大都是从微观的角度考虑软件项目中存在的风险问题,它们在进行风险管理时往往表现出静态和局部的特点,而忽略了项目各部分之间的相互作用对项目整体的影响.软件开发项目是一个动态的复杂系统[32],传统的项目管理方法不能有效地应对软件项目的动态复杂性,也不能从整体上把握软件项目风险管理.一些学者注意到这些方法的缺陷,将系统动力学引入软件项目管理.系统动力学是以反馈控制理论为基础、以计算机仿真为手段的定量分析技术.它通常以分析系统各部分之间的因果关系来建立非线性定量模型,并通过仿真的方法来考察系统的整体结构.Abdel和Madnick[33]对软件开发过程进行系统动力学的建模和仿真,在此基础上开展项目管理.一些学者[34236]先后对这一问题作了深入详细的探讨.以上学者的研究主要是对软件过程进行建模. Houston[37,38]专门为风险管理建立了软件项目系统动力学模型.他基于先前的系统动力学模型,提出一种所谓的基本模型,并对基本模型仿真得到一个基线值.在基本模型的基础上,给出了最为常见的6个软件项目的主要风险项,建立了一个扩展的系统动力学模型,并通过仿真得出各风险因素对系统的影响结果.Houston的模型是专为评估、缓和、调节风险管理活动而设计的,它通过调整输入参数,对成本、进度和产品质量进行风险分析和决策.4.4　基于成本估算模型的风险评估方法成本估算模型主要有SPL M模型和结构化成本模型(COCOMO),其中以COCOMO较为流行.下面简要介绍基于COCOMO的软件项目风险评估[4].Behem在其专著《软件工程经济学》[39]中发表了COCOMO模型(COCOMO81),它包括基本COCOMO,中级COCOMO和详细COCOMO3个层次.随后,为支持Ada项目评估,又开发了Ada COCOMO,对成本驱动因子作了适当调整.1990年后,出现了快速应用开发模型、软件重利用、再工程、CASE、面向对象方法、软件过程成熟度模型等一系列软件工程方法和技术,而早期的COCOMO不能适应新的需要.为此,Boehm重新调整了原有模型,根据未来软件市场的发展趋势,发表了COCOMO Ⅱ模型.COCOMOⅡ的基本构成为5个规模度量因子和17个成本驱动因子,利用它们来调整成本模型计算公式,将Delp hi专家法与Bayes统计分析法相结合,通过不同的成本因子来计算工作量并进行风险评估.4.5　其他方法体系结合软件工程实践,还有一些有特点的软件项目风险管理方法.主要有:1)J yrki[40]提出的Riskit方法.该方法构造了风险因素、风险事件、风险反应和效用损失的影响图,透彻地说明了风险的起因、发展和最后结果.2)Yacoub等[41]提出的客观评估方法.认为评估应基于产品的属性,而不只是专家的经验,所以必须尽可能地采用项目度量体系得到量化数据,并掌握好风险评估的时机.3)Greer等提出的SERUM法[42].它将以往的软件项目风险管理过程或模式称为“明确的方法”,主要选择一些风险管理策略来处理比较重要的风险,并通过风险减少技术达到对风险的控制. SERUM提出了“含蓄风险管理”,该方法从一开始就从商业角度考虑风险,并一直贯串于软件项目的整个过程.4)层次全息模型(H HM).H HM是研究风险管理的一种方法体系,并已成功地引入大型数据库开发系统.它强调将复杂系统以互补、协作的方式分解为部件、子系统等层次,每个层次都是完整系统的某一特定视角结构.文献[43246]采用层次全息模型对软件项目风险管理进行研究,给出了风险管理的一套方法和模型.文献[47]对项目风险管理中各个阶段使用的工具进行评述,并通过问卷调查和分析,给出了风险管理各个阶段可使用工具的排序,为管理人员的决策提供了可靠的依据.5　我国软件项目风险管理的研究现状 从我国软件项目风险管理研究现状看,由于国内软件行业发展较晚,软件企业不很成熟,很多公司主要以中小企业为主,很难谈得上系统、科学的软件项目风险管理.随着信息化浪潮的到来,我国软件业已在近几年取得了飞速发展,构建规范化、组织化的软件企业已成为业界人士的普遍共识.在这种情况484第5期潘春光等:软件项目风险管理理论与方法研究综述 下,软件项目的风险管理也开始受到重视.目前,国内对软件项目风险管理的研究还停留在学习和吸收国外已有理论和方法的基础上,近年来逐渐有文章见诸期刊,如张珞玲、李师贤对M IS 项目开展了一些风险管理的研究[48];张李义提出一种信息系统开发的动态风险模糊估测方法[49];鞠彦兵等提出一种基于证据理论的软件开发风险评估方法[50];潘陈勇从生命周期的角度提出了软件开发动态风险管理的研究方法[51].另外,方德英以IT项目风险管理为题,提出一种风险管理体系,在SEI风险管理框架中加入了组织保障体系[52].焦鹏对软件项目全生命周期的风险评估方法与应用作了详细探讨[53].纵观这些研究可知,我国的软件项目风险管理研究大都还是秉承国外的模式,在理论、方法及实践上没有取得实质性的突破,因此我国软件项目的风险管理研究基本上还处于起步阶段.如何结合我国软件行业的实际进行相关技术的研究,是一个挑战性的课题,也必将经历一个较长的阶段.6　未来研究展望 从目前软件项目风险管理的发展趋势看,其研究热点和需要进一步解决的问题主要有以下几方面:1)与软件过程改进相融合的风险管理理论和实践.软件项目管理朝着稳定化、有规律、可重复、可量化的方向发展已是大势所趋,风险管理应与当前软件工程的发展潮流相融合.软件过程改进的成功,使得软件项目风险管理受益匪浅.目前,人们已将风险管理的研究置于过程改进的框架之下,力图使风险管理在理论和实践上真正突破静态管理的模式,从而从根本上克服操作性不强、缺乏有效的技术和工具支持、定性分析多于量化管理等缺陷.这样,在过程改进的基础上发展起来的新的软件项目风险管理的研究,便成为该学科的一个发展方向.2)基于客观度量的风险评估技术.尽管目前应用于软件项目领域的风险评估技术不少,但大多是借鉴其他工程项目风险管理技术,而且多是以经验和主观分析为主.这些方法虽在一定程度上解决了某些风险问题,但在实践中往往不能取得较好的效果.因此应研究以软件度量为基础的客观风险评估方法.3)与新的项目管理方法的结合.项目管理领域中新的突破,往往能给软件项目的风险管理提供有益的参考,如前面总结的关键链等技术.但如何应用于软件项目风险管理并发挥作用,也是目前研究的热点问题之一.4)新的软件工程实践给风险管理带来的变化.软件工程的不断实践会出现一些新的问题,随之而来也会有许多风险问题出现.如何对这些变化开展有针对性的研究,也是未来软件项目风险管理需要解决的课题之一.总之,软件项目风险管理是一门实践性很强的学科,必须不断探求软件开发项目的规律和特点,紧密与软件工程的最新实践相结合,才会使其具有更强的生命力.参考文献(R eferences)[1]丁义明,方福康.风险概念分析[J].系统工程学报,2001,16(5):4022406.(Ding Y M,Fang F K.Analysis of concept of risk[J].J of Systems Engineering,2001,16(5):4022406.) [2]张哲.风险哲学初探[J].武警工程学院学报,2000,16(5):30232.(Zhang Z.A study of risk philosophy[J].J of Engineering College of Armed Police Force,2000,16(5):30232.)[3]Boehm B W.Software risk management[M].Piscataway:IEEE Computer Society Press,1989. [4]Madachy R.Heuristic risk assessment using cost factors[J].IEEE Software,1996,14(5/6):51259.[5]Charette R.Software engineering risk analysis andmanagement[M].New Y ork:Mc Graw2Hill,1989. [6]Kumamoto H,Henley E J.Probabilistic riskassessment and management for engineers and scientists [M].New Y ork:IEEE Press,1996.[7]Software Engineering Institute.The SEI approach tomanaging software technical risks[R].Bridge:Software Engineering Institute,1992:19221.[8]Boehm B W.Software risk management:Principles andpractices[J].IEEE Software,1991,8(1):32241. [9]Higuera Ronald P,Haimes Y Y.Software riskmanagement[R].Pittsburgh:Carnegie Mellon University,1996.[10]Dorofee A J,Walker J A.Continuous risk management[R].Pittsburgh:Carnegie Mellon University,1996.[11]Elaine M Hall.Managing risk:Methods for softwaresystems development[M].Addison2Wesley Publishing Company,1998.[12]Prikladnicki R,Yamaguti M H,Antunes D C.Riskmanagement in distributed software development:A process integration proposal[C].5th IFIP Working Conf on Virtual Enterprises.Toulouse,2004.[13]Dipak Surie.Evaluation and integration of riskmanagement in CMMI and ISO/IEC[J].http://www.cs.umu.se/～dipak/paper2cmmi.pdf.[14]Alf red B.Process2based software risk assessment[C].584 控 制 与 决 策第22卷Proc of the4th European Workshop on Software Process Technology.Nordwijkerhout,1995:1221. [15]Barki H,Riverd S,Talbot J.Toward an assessment ofsoftware development risk[J].J of Management Information Systems,1993,10(2):2032225.[16]Capers Jones.Assessment and control of software risks[M].Englewood Cliff s:Y ourdon Press,1994.[17]Carr M,K onda S L,Monarch F.Taxonomy2basedrisk identification[R].Pittsburgh:Carnegie Mellon University,1993.[18]Linda Wallace,Mark Keil,Arun Rai.Understandingsoftware project risk:A cluster analysis[J].Information and Management,2004,42(1):1152125.[19]Linda Wallace,Mark Keil,Arun Rai.How softwareproject risk affects project performance:An investigation of the dimensions risk and an exploratory model[J].Decision Sciences,2004,35(2):2892321.[20]Dawson R J,Dawson C W.Practical proposals formanaging uncertainty and risk in project planning[J].Int J of Project Management,1998,16(5):2992310.[21]Alquier A M,Tignol M H.Project managementtechnique to estimate and manage risk of innovative projects[C].IPMA Int Symp and NORDN ET’2001.Stockholm,2001.[22]Moeller G L,Digman L A.Operations planning weihV ER T[J].Operations Research,1981,29(4):6762 697.[23]G oldratt E M.Critical chain[M].New Y ork:NorthRivef Press Inc,1997.[24]Lawrence M Hayhurst.The critical chain in softwareengineering[J]./hunsaker/Critical_Chain_Software_Eng.pdf.[25]Bengee Lee,J ames Miller.Multi2project managementin software engineering using simulation modeling[J].J of Software Quality,2004,12(1):59282.[26]Fan C F,Yu Y C.BBN2based software project riskmanagement[J].J of Systems and Software,2004,73(1):1932203.[27]Ammar H,Nikzadeh T,Dugan J B.An example ofrisk assessment of software systems specifications[C].Proc of8th Int Symp on Software Reliability Engineering.Albuquerque,1997:1562167.[28]Liu L C,Horowitz E.A formal model for softwareproject management[J].IEEE Trans on Software Engineering,1989,15(10):128021293.[29]Chang C K,Christensen M.A net practice forsoftware project management[J].IEEE Software, 1999,16(6):80288.[30]Chang C K,Christensen M,Zhang T.G eneticalgorithms for project management[J].Annals ofSoftware Engineering,2001,11:1072139.[31]Chang C K.SPMN ET:A new methodology forsoftware management[D].Chicago:The University of Illinois,1995.[32]Lai L S Linda.A synergistic approach to projectmanagement in information systems development[J].Int J of Project Management,1997,15(3):1732179.[33]Abdel Hamid T K,Madnick S.Software projectdynamics:An integrated approach[M].Prentice2Hall, 1991.[34]Madachy Raymond J.A software project dynamicsmodel for process cost,schedule and risk assessment[D].University of Southern California,1994.[35]John Douglas Tvedt.An extensible model forevaluating the impact of process improvements on software development cycle time[D].Phoenix:Arizona State University,1996.[36]Sycamore Douglas M.Improving software projectmanagement through system dynamics modeling[D].Phoenix:Arizona State University,1996.[37]Dan X Houston,Gerakd T Mackulak,J ames SCollofello.Stochastic simulation of risk factor potential effects for software development risk management[J].J of Systems and Software,2001,59(3):2472257. [38]Dan X Houston.A software project simulation modelfor risk management[D].Phoenix:Arizona State University,2000.[39]Barry Boehm.Software engineering economics[M].New Jersey:Prenctice Hall,1981.[40]J yrki K ontio.Software engineering risk management:A method,improvement f ramework and empiricalevaluation[D].Helsinki:Helsinki University of Technology,2001.[41]Yacoub S M,Ammar H H,Robinson.A methodologyfor architectural2level risk assessment using dynamic metrics[C].11th Int Symp on Software Reliability Engineering.San Jose,2000:2102221.[42]Greer D,Bustard D W.SERUM—Softwareengineering risk:Understanding and management[J].Project and Business Risk Management,1997:1(4): 3732388.[43]Michael J Pennock,Yacov Y Haimes.Principles andguidelines for project risk management[J].Systems Engineering,2002,5(2):892107.[44]Clyde G Chittister,Yacov Y Haimes.Systemintegration via software risk management[J].IEEE Trans on Systems,Man and Cybernetics:Part A, 1996,26(5):5212532.(下转第493页)684第5期康惠骏等:混合励磁电机系统输入输出解耦和线性化 excitation of AC and DC machine[C].Electrical Machines and Drives:4th Int Conf.London,1989:48252.[2]Naoe Nobuyuki,Fukami Tadashi.Trial production of ahybrid excitation type synchronous machine[C].Electric Machines and Drives Int Conf.Cambridge,2001:5452 547.[3]Aydin M,Huang S R,Lipo T A.A new axial fluxsurface mounted permanent magnet machine capable of field control[C].IEEE IAS Annual Meeting.Pittsburgh,2002:125021257.[4]Amara Y,Oujehani K,Hoang E,et al.Flux weakeningof hybrid synchronous machines[C].Electric Machines and Drives Int Conf.Cambridge,2001:3672373.[5]Hori H,Ashikaga T.Current controller for hybridexcitation type permanent magnet motor[P].J apan Patent:8242600,1996.[6]Zhao C H,Yan Y G.A review of development of hybridexcitation synchronous machine[C].IEEE ISIE.Dubrovnik,2005:8572862.[7]徐衍亮,唐任远.混合励磁同步电机的结构、原理及参数计算[J].微特电机,2000,28(1):16218.(Xu Y L,Tang R Y.A kind of structure,principle and parameter calculation for hybrid excitaion synchronous machine[J].Small and Special Electrical Machines,2000,28(1):16218.)[8]杨儒珊.混合磁路电机系统的结构性质分析[D].上海:上海大学,2005.(Yang R S.Analysis of structure of hybrid excitation permanent magnet sychronous machine system[D].Shanghai:Shanghai University,2005.)[9]谢七月,康惠骏.混合磁路电动机的非线性解耦控制[J].上海大学学报,2006,12(2):1582161.(Xie Q Y,Kang H J.Nonlinear decoupling control of hybrid excitation permanent magnet synchronous motor [J].J of Shanghai University,2006,12(2):1582161.)[10]康惠骏,谢七月,杨儒珊.混合励磁电动机的可逆性[C].2006中国控制与决策学术年会论文集.天津,2006:131321316.(Kang H J,Xie Q Y,Yang R S.Invertibility of hybrid excitation synchronous machine[C].CDC’2006.Tianjin,2006:131321316.)[11]Isidori A.Nonlinear control systems[M].2nd ed.Birlin:Springer2Verlag,1989.[12]康惠骏.异步电动机非线性系统分析与控制[D].上海:上海大学,1996.(Kang H J.Analysis and control for nonlinear systems of induction motors[D].Shanghai:Shanghai University,1996.) (上接第486页)[45]Leung M F,Santos J R,Haimes Y Y.Risk modeling,assessment and management of lahar flow threat[J].Risk Analysis,2003,23(6):132321335.[46]Yacov Y Haimes,Kaplan S,Lambert J H.Riskfiltering,ranking and management f ramework using hierarchical holographic modeling[J].Risk Analysis, 2002,22(2):3812395.[47]Raz T,Michael e and benefits of tools for projectrisk management[J].Int J of Project Management, 2001,19(1):9217.[48]张珞玲,李师贤.软件项目风险管理方法比较和研究[J].计算机工程,2003,29(3):91294.(Zhang L L,Li S parision and research on models of software project risk management[J].Computer Engineering,2003,29(3):91294.)[49]张李义.信息系统开发的动态风险模糊估测方法[J].系统工程理论与实践,2001,21(10):88292.(Zhang L Y.Approach to dynamic risk estimation for information system development[J].System Engineering Theory and Practice,2001,21(10):88292.)[50]鞠彦兵,冯允成,姚李刚.基于证据理论的软件开发风险评估方法[J].系统工程理论方法应用,2003,12(3):2182223.(J u Y B,Feng Y C,Yao L G.Research on the measure of risk in the course of software development[J].Systems Engneering—Theory Methodology Applications,2003,12(3):2182223.)[51]潘陈勇.基于生命周期的软件开发动态风险管理[D].杭州:浙江大学,2002.(Pan C Y.Dynamic risk management based on the software development life cycle[D].Hangzhou: Zhejiang University,2002.)[52]方德英.IT项目风险管理理论与方法研究[D].天津:天津大学,2003.(Fang D Y.The study on theories and methods of IT project risk management[D].Tianjin:Tianjin University,2003.)[53]焦鹏.软件项目风险评估方法的研究[D].北京:北京工业大学,2003.(Jiao P.The study on software project risk assessment[D].Beijing:Beijing University of Technology,2003.)394。

软件测试风险评估在软件开发过程中，测试是一个至关重要的环节，它能够帮助发现和解决潜在的问题，确保软件的质量和稳定性。

然而，测试本身也存在一定的风险。

为了更好地评估软件测试的风险，本文将从风险的定义、评估方法以及应对策略等方面进行探讨。

一、风险的定义与分类风险是指在特定环境下，由于不确定性因素而导致达不到预期结果的可能性。

在软件测试领域，风险可以分为项目风险和产品风险两个层面。

1. 项目风险：指软件开发过程中可能发生的各种不确定性因素，如人员变动、进度延迟、资源短缺等。

这些因素可能会导致测试活动无法按计划进行，从而影响测试效果和成果。

2. 产品风险：指软件产品功能和质量方面可能存在的不确定性因素，如系统性能问题、安全漏洞等。

这些因素可能会导致软件产品在实际使用中出现故障或者无法满足用户需求，从而影响用户体验和企业形象。

二、软件测试风险评估方法为了全面评估软件测试的风险，我们可以采用以下常用的评估方法：1. 风险识别：通过与团队成员和相关利益相关者的交流，以及对软件测试过程中可能发生的问题进行分析，确定可能存在的风险点和潜在影响。

2. 风险分析：对识别出的潜在风险进行定性和定量分析，评估其概率和影响程度。

可以采用常用的风险矩阵等工具进行分析。

3. 风险评估：根据风险分析的结果，对各个风险进行评估，并确定其优先级。

这样可以有针对性地制定相应的应对措施和规划测试资源的分配。

4. 风险控制：根据评估结果制定合理的风险应对策略，包括风险避免、风险转移、风险缓解和风险接受等。

在测试过程中及时监控和控制风险的发生和演化。

三、软件测试风险应对策略为了降低软件测试风险对项目和产品的影响，我们可以采取以下应对策略：1. 提前规划：在软件开发的早期阶段，就要对测试活动进行充分规划。

明确测试目标、范围和资源需求，并与相关团队进行充分的沟通和协调。

2. 引入自动化测试：通过引入自动化测试工具和框架，可以提高测试效率和测试覆盖率，减少人为因素对测试结果的影响，降低测试风险。

摘自—项目管理技术软件开辟项目是一项复杂的工程，涉及的因素不少，风险的管理过程有：风险的识别、风险的管理计划的制定、风险追踪、风险控制。

风险识别是风险管理的第一步，而有效的风险分析是进行风险管理的基础，因此做好这 2 个过程的工作是软件项目成功的关键。

1 软件风险的识别风险识别过程的活动是将项目实施中的不确定性转变为明确的风险陈述。

系统地识别风险是这个过程的关键，识别风险不仅要确定风险来源，还要确定何时发生、风险产生的条件，并描述其风险特征和确定哪些风险事件有可能影响本项目。

风险识别不是一次性的活动，应当在项目执行过程中自始至终定期进行。

1.1 风险识别的依据从项目管理角度讲，风险识别依据有：合同、项目计划、工作任务分解WBS、各种历史参考资料(类似项目的资料)、项目的各种假设前提条件和约束条件。

从软件开辟的生命周期看，每一个阶段的输出(各种文档)都是下一阶段进行风险识别的依据，许多技术风险都可据此来分析。

1.2 风险识别方法和工具风险识别的方法不少，不同的方法合用于不同的场合，下表给出了常用的方法的合用情况。

识别方法合用情况专家访谈法(Delphi) 从定性方面出发进行初步风险识别历史纪录统计法从定性方面对新项目的风险进行预测现场调查法对一些动态风险因素进行识别与预测风险数据库类似项目的风险识别故障树分析法直接经验较少的风险识别流程图法分阶段进行的项目风险识别聚类分析法具有相同或者相似属性的风险识别含糊识别法风险的形态或者属性不确定软件项目的风险识别通常采用的工具为：(1) 风险核对清单：将可能浮现的问题列出清单，然后对照检查潜在的风险。

(2) 头脑风暴法：项目成员、外聘专家、客户等各方人员组成小组，根据经验列出所有可能的风险。

(3) 专家访谈：向该领域的专家或者有经验人员了解项目中会遇到哪些困难。

(4) 风险数据库：一个已知风险和相关的信息的仓库，它将风险输入计算机，并分配下一个连续的号码给这个风险，同时维持所有已经识别的风险历史纪录，它在整个风险管理过程中都起着很重要的作用。

不确定性分析与风险分析培训1. 引言不确定性是我们在日常生活和商业决策中经常面对的现象。

在现代社会，我们经常需要面对各种不确定性因素，例如市场波动、技术发展、政策变化等等。

这些不确定性因素可能会给我们的决策带来风险和挑战。

为了降低风险、做出明智的决策，不确定性分析和风险分析成为了必不可少的工具和方法。

本文档旨在提供一份关于不确定性分析与风险分析的培训材料，以帮助大家更好地理解和应对不确定性和风险。

2. 不确定性分析2.1 什么是不确定性分析不确定性分析是一种通过定量和定性方法来研究和评估不确定性的工具。

不确定性分析通过收集和分析数据、建立数学模型、应用统计方法等手段，来评估不确定性因素对我们的决策结果的影响。

2.2 不确定性分析的方法在不确定性分析中，我们常用的一些方法包括：•敏感性分析：通过改变不确定性因素的值，来观察结果的变化，以评估这些因素对结果的影响程度。

•蒙特卡洛模拟：通过随机抽样和重复模拟的方法，来评估不确定性因素对结果的影响，并得到结果的概率分布。

•场景分析：通过构建不同的场景，来评估不同的不确定性因素对不同场景下结果的影响。

•增量分析：通过逐步加入不确定性因素，来研究每个因素对结果的影响。

2.3 不确定性分析的应用不确定性分析可以应用于各个领域和行业。

下面是一些应用案例：•金融领域：不确定性分析可以帮助投资者评估投资组合的风险和收益，以做出更好的投资决策。

•工程领域：不确定性分析可以帮助工程师评估工程项目的成本和进度风险，并采取相应的措施减少风险。

•决策支持：不确定性分析可以帮助决策者评估决策方案的风险，并选择最合适的方案。

3. 风险分析3.1 什么是风险分析风险分析是一种通过识别、评估和控制风险的过程。

风险是指可能发生的事件或行为对目标的不确定性带来的威胁。

风险分析通过对可能发生的风险进行评估，并制定相应的风险应对策略，来降低风险对目标的影响。

3.2 风险分析的步骤风险分析通常包括以下几个步骤：•风险识别：通过收集信息和利益相关者的参与，识别与目标相关的可能风险。

软件风险分析报告一、引言在当今的信息化时代，软件已成为各个行业的重要支柱。

然而，随着软件系统的日益复杂，其面临的风险也日益增加。

为了更好地管理和降低软件风险，本报告旨在分析软件生命周期中可能出现的风险，并提出相应的应对策略。

二、软件风险定义与分类软件风险是指在软件开发过程中可能出现的不确定因素，可能导致项目延期、超出预算或软件质量不达标等后果。

根据其性质，软件风险可分为以下几类：1、技术风险：由于技术难度、缺乏经验或工具等原因导致的风险，如需求变更频繁、技术实现困难等。

2、管理风险：由于项目管理不善或沟通不畅等原因导致的风险，如项目计划不合理、资源分配不均等。

3、组织风险：由于组织结构、文化或人员等原因导致的风险，如团队协作不畅、人员技能不足等。

4、外部风险：由于法律法规、市场竞争或自然灾害等原因导致的风险，如知识产权纠纷、客户需求变化等。

三、软件风险分析方法针对不同类型的软件风险，可以采用以下几种方法进行识别和分析：1、风险矩阵：通过列出可能的风险因素，评估其发生的概率和影响程度，从而确定重点的风险。

2、失效模式影响分析（FMEA）：通过对系统或组件的失效模式进行分类和评估，确定潜在的风险和相应的预防措施。

3、概率-影响图：通过绘制风险因素的发生概率与影响程度的曲线，找出需要重点的风险因素。

4、模拟与仿真：通过模拟软件的实际运行环境和使用情况，评估潜在的风险和可能的后果。

四、软件风险应对策略针对不同类型的软件风险，可以采取以下几种应对策略：1、技术风险：加强技术培训和知识积累，提高开发团队的技术能力和经验；采用成熟的技术架构和工具，降低技术实现的难度；进行充分的技术论证和评审，确保技术方案的有效性和可行性。

2、管理风险：制定合理的项目计划和预算，明确阶段性目标和时间节点；加强项目管理和沟通协调，确保资源分配的合理性和工作进度的把控；建立有效的反馈机制和质量管理体系，及时发现和解决问题。

3、组织风险：建立良好的组织结构和团队文化，提高团队协作的效率和凝聚力；加强人员培训和技能提升，提高团队整体的技术能力和素质；进行定期的团队沟通和绩效评估，了解团队成员的需求和问题，提升团队的协作效果。

软件项目风险管理一、风险管理概述软件风险是指软件开发过程中及软件产品本身可能造成的伤害或损失。

风险关注未来的事情，这意味着，风险涉及选择及选择本身包含的不确定性，在软件开发过程及软件产品都要面临各种决策的选择。

风险是介于确定性和不确定性之间的状态，是处于无知和完整知识之间的状态。

另一方面，风险将涉及思想、观念、行为、地点等因素的改变。

当在软件工程领域考虑风险时，我们要关注以下的问题：什么样的风险会导致软件项目的彻底失败？用户需求、开发技术、目标计算机、以及所有其它与项目有关的因素的改变将会对按时交付和总体成功产生什么影响？对于采用什么方法和工具，需要多少人员参与工作的问题，我们如何选择和决策？对软件质量要达到什么程度才是“足够的”？当没有办法消除风险，甚至连试图降低该风险也存在疑问时，这些风险就是真正的风险了。

在我们能够标识出软件项目中的真正风险之前，识别出所有对管理者和开发者而言均为明显得风险是很重要的。

二、被动和主动的风险策略被动风险策略是针对可能发生的风险来监督项目，直到它们变成真正的问题时，才会拨出资源来处理它们，更普遍的是，软件项目组对风险不闻不问，直到发生了错误才赶紧采取行动，试图迅速地纠正错误。

这种管理模式常常被称为“救火模式”。

当补救的努力失败后，项目就处在真正的危机之中了。

对于风险管理的一个更聪明的策略是主动式的。

主动策略早在技术工作开始之前就已经启动了――标识出潜在地风险，评估它们出现的概率及产生的影响，对风险按重要性进行排序，然后，软件项目组建立一个计划来管理风险。

主动策略风险管理的主要目标是预防风险。

但是，因为不是所有的风险都能够预防，所以，项目组必须建立一个应付意外事件的计划，使其在必要时能够以可控的及有效的方式作出反应。

三、软件风险1、软件风险包含两个特征：不确定性——刻划风险的事件可能发生也可能不发生，没有100％发生的风险。

损失——如果风险变成了现实，就会产生恶性后果或损失。