计算机软件工程风险管理研究
软件工程中的软件项目风险识别与应对
软件工程中的软件项目风险识别与应对软件工程项目的成功与否往往受到许多风险因素的影响。
因此，在软件项目的计划和实施过程中，风险管理是一个至关重要的环节。
本文将探讨软件工程中的软件项目风险识别与应对的方法和策略。
一、风险识别风险识别是软件项目风险管理的第一步，只有找到风险，才能有针对性地进行应对。
以下是一些常见的软件项目风险：1. 人员变动风险：例如项目组成员离职、缺乏相关技能的人员加入等，可能导致项目进度延迟或者质量下降。
2. 需求变更风险：客户需求的频繁变更会给项目带来很大的不确定性，可能导致项目计划无法按时完成。
3. 预算不足风险：预算不足可能导致项目无法按时交付或者降低项目的质量。
4. 技术风险：新技术的使用、技术难题的解决等都可能给项目带来一定的风险。
识别风险的方法可以采用头脑风暴、需求分析、经验总结等。
在项目启动阶段，可以组织专家会议或者借鉴类似项目的经验，以识别可能的风险。
二、风险评估风险评估是对已经识别到的风险进行评估和排序，确定其对项目的影响程度和发生概率。
评估风险可以采用专家评估、统计数据分析等方法。
常用的评估方法有风险概率和影响矩阵、风险等级划分等。
在评估风险时，可以根据风险发生的可能性和影响程度进行排序，以确定应对风险的优先级。
高概率高影响的风险往往需要重点关注和应对。
三、风险应对策略针对不同的风险，需要采取相应的应对策略。
以下是一些常见的风险应对策略：1. 人员变动风险：建立一个稳定的项目团队，并进行项目经验的积累和共享，以降低人员变动的风险。
2. 需求变更风险：在项目启动之前，与客户充分沟通和协商，明确项目的目标和需求，尽量减少需求的变更。
3. 预算不足风险：合理评估项目成本，并与客户进行充分沟通，明确项目预算和交付标准。
4. 技术风险：及早评估和解决技术难题，对新技术进行充分的研究和测试，确保其在项目中的稳定性和可靠性。
此外，还可以采用风险转移、风险规避、风险接受等策略，根据具体情况进行选择。
计算机软件工程管理常见问题及解决对策
计算机软件工程管理常见问题及解决对策计算机软件工程管理是一个复杂的过程，涉及了软件开发周期的各个阶段，包括需求分析、设计、编码、测试、部署和维护等。
在软件工程管理过程中，常常会遇到各种问题，例如进度延误、需求变更、人员管理等。
在本文中，我们将讨论计算机软件工程管理中常见的问题，并提出相应的解决对策。
1.需求变更频繁需求变更是软件工程中常见的问题之一，客户往往在项目进行过程中会提出新的需求或修改原有需求，导致项目计划的变更，影响项目的进度和质量。
解决对策：在需求分析阶段尽可能详细地了解客户需求，并建立变更管理机制，明确需求变更的流程和责任人。
采用敏捷开发方法，将需求分解成小的模块，灵活地应对需求变更。
2.进度延误软件工程项目中，进度延误是一个普遍存在的问题，可能由于需求变更、技术难题、人员变动等原因导致项目无法按时完成。
解决对策：在项目计划中合理地预留一定的缓冲时间，以应对可能的风险和延误。
采用项目管理工具进行进度跟踪和风险评估，及时发现问题并采取相应措施。
3.人员管理软件项目的成功与否关键取决于团队的协作和个人的能力，而人员管理问题往往是软件工程管理中的难点。
解决对策：建立合理的团队激励机制，激励团队成员以更高的积极性和创造力参与项目。
进行人员的适应性培训，以提高团队成员的技能水平和团队协作能力。
4.技术选型在软件工程项目中，技术选型是一个至关重要的决策，不同的技术选择会影响项目的质量和进度。
解决对策：在项目初期进行充分的技术调研和评估，选择适合项目需求和团队能力的技术方案。
建立技术储备和技术交流机制，以及时应对技术难题和变动。
5.沟通与协作良好的沟通和协作是软件工程项目成功的关键，但在实践中往往面临各种沟通障碍和协作问题。
解决对策：建立项目团队成员之间、团队与客户之间的有效沟通渠道，明确沟通方式和责任人。
采用协作工具和方法，提高团队成员之间的协作效率和质量。
计算机软件工程管理中常见的问题需要采取相应的解决对策。
浅谈计算机软件工程化管理
浅谈计算机软件工程化管理计算机软件工程化管理是指对软件项目进行全面、系统地组织、规划、控制和管理的过程。
它主要涉及项目管理、质量管理、配置管理、需求管理、变更管理以及工作流程管理等方面，旨在提高软件开发效率、质量和可维护性。
下面将从项目管理、配置管理、质量管理和需求管理四个方面来浅谈计算机软件工程化管理。
项目管理是计算机软件工程化管理的基础和核心。
项目管理包括项目计划、进度管理、资源管理、风险管理等。
在项目计划阶段，需要制定详细的项目计划，明确项目的目标、范围、时间和成本等要素。
在进度管理方面，要合理分解和安排项目任务，制定详细的工作计划，并及时跟踪项目进展情况，及时解决问题。
在资源管理方面，需要合理配置项目资源，包括人力、物力和技术等。
在风险管理方面，要及时识别并评估项目风险，制定相应的应对措施，以降低项目风险对项目目标的影响。
配置管理是软件工程化管理中的关键环节，它主要包括配置项的控制、配置项的标识、变更控制和版本控制等。
在配置项的控制方面，需要明确软件项目中的各个配置项，并建立相应的配置项库，确保每个配置项的完整性、一致性和可追溯性。
在配置项的标识方面，需要为每个配置项分配一个唯一的标识符，用于跟踪和管理配置项的变更和版本。
在变更控制方面，要建立严格的变更控制流程，确保所有的变更都经过评审、测试和验证，以防止不合格的变更进入项目。
在版本控制方面，要及时记录和管理软件的版本，确保对软件的修改和发布有序进行。
质量管理是保证软件项目高质量的关键。
质量管理包括质量计划、质量保证和质量控制等。
在质量计划方面，需要制定详细的质量计划，明确每个阶段的质量目标、评估方法和检测标准等。
在质量保证方面，需要建立质量保证体系，包括过程审核、培训和管理评审等，以确保软件项目按照规定的过程和标准进行。
在质量控制方面，要建立合适的质量控制措施，包括代码检查、单元测试、集成测试和系统测试等，以发现和解决软件项目中的问题，确保软件的质量和稳定性。
软件项目风险管理理论与方法研究综述_潘春光
第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.进度风险：包括项目进展缓慢、进度延误、资源不足等。
3.需求风险：包括需求变更、需求不明确、用户对软件功能预期不符等。
4.质量风险：包括软件缺陷、系统稳定性差、性能不足等。
5.人员风险：包括人员流动、人员能力不匹配、沟通合作困难等。
二、项目风险管理流程为了有效管理软件项目中的风险，可以采取以下流程：1.风险识别：通过充分分析项目的各个方面，识别潜在的风险因素。
可以借助SWOT分析、头脑风暴等方法，将想象的可能风险一一列举出来。
2.风险评估：对已经识别的风险进行评估，确定风险的概率和影响程度。
可以采用定性分析和定量分析相结合的方法，依据历史数据和专家经验进行评估。
3.风险优先级排序：根据风险的概率和影响程度，对风险进行优先级排序。
将高概率和高影响的风险列为重点关注对象。
4.风险应对策略制定：针对每个风险，制定相应的应对策略。
常见的应对策略包括：避免风险、减轻风险、转移风险和接受风险。
具体策略可以根据风险的特点和项目情况来确定。
5.风险控制与监控：在项目开发过程中，密切关注已识别的风险并采取相应的控制措施。
持续监控风险的变化，及时调整应对策略。
三、项目风险应对策略针对不同类型的项目风险，可以采取不同的应对策略：1.技术风险应对：建立完善的技术评估机制，确保选择合适的技术方案；提供培训和学习机会，提高技术人员的能力；与技术专家合作，解决技术难题。
2.进度风险应对：制定详细的项目计划，合理安排资源；提前做好风险评估，制定应急计划；建立团队沟通机制，及时解决进度方面的问题。
软件项目风险管理文献综述
软件项目风险管理文献综述一九八九年，美国心理学家Barry Boehm在其《软件风险管理》书中也曾提到，软件工程项目风险控制是开发项目的基础和保证。
在以后的一段时间内，由于计算机科学与软件工程的进一步发展，对软件项目与风险管理体系的研究也越来越向着系统性发展，理论框架模型也越来越多，大致有如下几类：一、Boehm 和 Charette 的风险管理框架Boehm在其作品《软件风险管理》当中，软件系统的风险管理工作基本上包含了风险评估和风险控制二个大部份，风险评估包含危机识别、危险分级和危险偏好，而经营风险则包含风险管理计划、危机管理和风险监测。
Boehm和Charette风险管理框架列表如下：表1：风险管理框架在这个情形下，风险识别法主要是指向可能会阻碍项目取得成功的风险清单上，这也成为了风险管理的基石。
风险分析，是指评价各种风险的可能性与危害，并确定风险水平。
按照对经营风险的影响程度决定了经营风险优先级。
将经营风险控制又分为风险管理计划sk管理和经营风险监测。
经营风险管理工作规划是指建立一个计划体系，以处理每项重大风险，并保证在每项风险管理工作规划和全部项目管理规划体系之间的统一性。
风险控制是指针通过对各种重大风险进行规划。
而风险监测则是对处理经营风险流程问题的监测。
风险监控还应该包含通过认识新的经营风险，并将它带到更长期的风险管理过程中。
二、Higuera 和 Haimes 风险管理框架Higuera和Haimes共同设计的软件工程项目风险管理体系框架是由国家卡内基梅隆学校软件研究所提供的风险管理理论体系的重要组成部分。
管理共分五个阶段：风险辨识、分类、规划、跟踪和控制。
风险管理的基本方法是一种持续的循环，核心理念是风险沟通。
(CRM)。
具体如图，持续风险管理的框架模型。
图2；持续风险管理框架模型在深入研究软件项目风险管理体系的各种理论架构时，各个理论体系均具备着架构完备、内容完整的特征，并伴随着与架构和内容相配套的管理方法与技能。
软件项目的风险分析
软件项目的风险分析软件工程项目的开发也存在各种各样的风险，有些风险甚至是灾难性的。
R.Charette认为，风险与将要发生的事情有关，它涉及诸如思想、观念、行为、地点、时间等多种因素；风险随条件的变化而改变，人们改变、选择、控制与风险密切相关的条件可以减少风险，但改变、选择、控制条件的策略往往是不确定的。
在软件开发过程中，人们关心的问题是，什么风险会导致软件项目的彻底失败？顾客需求、开发环境、目标机、时间、成本的改变对软件项目的风险会产生什么影响？人们必须抓住什么机会、采取什么措施才能有效地减少风险、顺利完成任务？所有这些问题都是软件开发过程中不可避免并需要妥善处理的。
软件工程的风险分析包括：风险标识、风险估算、风险评价和风险管理四部分1、风险标识从宏观上看，风险可以分为项目风险、技术风险和商业风险三类。
由于项目在预算、进度、人力、资源、顾客和需求等方面的原因对软件项目产生的不良影响称为项目风险。
软件在设计、实现、接口、验证和维护过程中可能发生的潜在问题，如规格说明的二义性、采用陈旧或尚不成熟的技术等等，对软件项目带来的危害称技术风险。
开发了一个没人需要的优质软件，或推销部门不知如何销售这一软件产品，或开发的产品不符合公司的产品销售战略，等等，称为商业风险。
这些风险有些是可以预料的，有些是很难预料的。
为了帮助项目管理人员、项目规划人员全面了解软件开发过程存在的风险，Boehm建议设计并使用各类风险检测表标识各种风险。
2、风险估算软件项目管理人员可以从影响风险的因素和风险发生后带来的损失两方面来度量风险。
为了对各种风险进行估算，必须建立风险度量指标体系；必须指明各种风险带来的后果和损失；必须估算风险对软件项目及软件产品的影响；必须给出风险估算的定量结果。
3、风险评价和管理在风险分析过程中，经常使用三元组[RI,LI,XI]描述风险。
其中RI代表风险，LI表示风险发生的概率，XI是风险带来的影响，I = 1，2，…L是风险序号，表示软件项目共有L种风险。
软件工程中的软件工程项目风险与风险管理
软件工程中的软件工程项目风险与风险管理软件工程项目是指由软件工程师及开发团队合作完成的软件开发工作。
然而，在软件开发过程中，会面临各种风险，这些风险可能会影响项目进度、质量和成本，甚至可能导致项目失败。
因此，软件工程项目风险管理成为保障项目成功的重要环节。
本文将深入探讨软件工程项目风险的来源、分类以及常见的风险管理策略。
一、软件工程项目风险的来源1. 技术风险：软件开发过程中，如不合理的技术选型、技术难题以及技术实现的不确定性等因素都可能导致技术风险。
例如，选择不成熟的开发工具或框架、技术人员技术不足等。
2. 需求风险：需求的不明确或变更频繁可能导致项目进度和计划的不确定性，从而产生需求风险。
例如，用户需求定义不明确、需求变更无法有效控制等。
3. 资源风险：包括人力资源和技术资源的不足，如项目人员流失、硬件设备故障等。
这些都会导致项目执行过程中的能力和资源缺失。
4. 进度风险：软件项目的进度可能受到外部环境变化的影响，也可能受到内部团队沟通、协作等问题的制约，从而导致进度风险。
例如，项目资源分配不合理、沟通不畅造成的进度延迟等。
5. 成本风险：软件工程项目在开发过程中，如果无法准确估算成本，未能合理控制成本，将导致项目成本超支。
例如，忽略了人员培训、软件测试以及维护的成本等。
二、软件工程项目风险的分类根据风险发生的可能性和影响程度，软件工程项目风险可以分为高、中、低三个等级。
具体分类如下：1. 高风险：高风险指那些可能性和影响程度都很高的风险。
例如，技术选型不合适，在项目开发过程中可能出现严重的问题，导致项目无法按计划完成。
2. 中风险：中风险意味着某个风险的可能性和影响程度在中等水平。
例如，需求变更频繁，可能会导致项目进度推迟，但不会对整个项目的成功造成严重威胁。
3. 低风险：低风险表示某个风险的可能性和影响程度较低。
例如，项目资源分配不合理，可能会导致一些小规模的影响，但并不会对整体项目的进度和质量产生严重影响。
软件开发过程与风险管理研究
２ 软件风险、风险分析与风险管理概念
对风 险的定义有多 种。管理工程 专家 Ｐ ．ｒｃｅ 定义 为 ．Ｄ ｕｋｒ Ｆ “ 险是将现有 资源投 向未来并期 望结果 的委托行 为 中固有 风
率 ， —— 风险后 果 ， 即软件风 险实际就是 每一种风 险及 其作 软件风 险主要有 ３ 种不 同类型 ： 目管理 风险、 项 技术风险
和 产 品 质 量 风 险 。
件风 险的概念 、 特性 ， 险处理 的策略 、 风 方法 ， 以降低或 克服软
件风 险的危害性 ， 从而提 高软件产 品的质量 。本 文从软件 风 险的概 念 出发 ， 研究并探 索了软件风 险分析及 风险管理 的方
Ｈ ＵＡＮＧ ａ—ｈ ｕ Ｑｕｎｚｏ
（ ｏｌ ｅ ｆ ｏ ｐ ｔ ，Ｘｉ ｈ ｏ ｎｖ ｒ ｔ Ｃ ｌ ｇ Ｃ ｍ ｕｅ ｅ ｏ ｒ ’ Ｓ ｉ ｕＵ ｉｅ ｉ ，Ｘ ’ １０ ５ ｈ ａ ｎ ａ ｙ ｓｙ ｉｎ７ ０ ６ ，Ｃ ｉ ） ａ ｎ
Ａ ｓｒｃ：Ｔ ｒ ｆ ｏ ，ｒ ｓ ｂ ｔａｔ ｅｍｓ ￣， ｅ ｉ ｏｓ ａ ｒ Ｌ ｒｌｔ ｎｈｐｏ ｆｗ ｒ ｓ ｎ ｆ， ｅ ｅｅｏ ｍｅ ｔ ｒｃｓ ｗｅ ｔ ｄ ｃｄ Ｔ ｅ ｒｃｓｉｇ ｅａ ｏ ｓｉ ｆ ｏ ａｅｒ ｋａ ｄｓ ｂ ａ ｖｌｐ ｎ ｏ ｅｓ ｒ ｉ ｒ ｕ ｅ． ｈ ｎｐｏｅｓ ｉ ｓｔ ｉ ｏ ， ｄ ｒ ｐ ｅ ｎｏ ｎ ｗａｓ ｆｏ ｗ ｒ ｓ，ｗａｓｏｄｃｅｓ ｆ ａｅｉ ａ ｄ ａ ｓ ｆ ｓ ｍａｎ ｆ ｒｅｉ ｎｄ ｎ ａ ｉ ｓ ｗｅ ｄｓｕ ｓｄ ｅｅ － ｙ ｏ ｓｆ ａｅ ｉ ｔ ｒｋ ｙ ｔ ｅｒａｅ ｏ ｗ ｒｒ Ｌ ｎ ｍｅ ｏ ｅｔ ｔ ｇｓｔ ｓｔ ｓ ｎ ｉ ｉ ｏ ｗａ ｓ ｒ ｋａ ｍａ ｇｎ ｒ ｋ ｒ ｉ ｓｅ ．Ｒ ｓａ ｇｉ ｅ ｃ ｒ
软件开发的风险评估和管理
软件开发的风险评估和管理在信息时代，软件开发已经成为人类日常生活和工作中不可或缺，且日益重要的组成部分。
然而软件开发过程中的风险也在不断地挑战着工程师们的智慧和耐心。
风险评估和管理是帮助开发团队预测、发现和应对风险的必要手段，下面将从多个方面探讨软件开发中的风险评估和管理工作。
一、软件开发的风险类型1. 管理风险：包括时间规划、资源分配、成本预算等管理问题，并对开发进度和成果产生影响；2. 软件需求风险：指开发团队未清晰或客户未明确需求的风险，可能会导致客户的不满和工程师的开发重复造轮子；3. 技术风险：涉及技术创新、技术实现难度、新兴技术的不稳定性等各方面因素；4. 算法风险：对于算法需要不断地优化和调整，时间、成本和可行性都可能成为风险因素；5. 设计风险：软件的设计在很大程度上体现了开发团队的整体水平，设计累积的失误和漏洞都可能影响到软件后期的开发和处6. 编码风险：开发人员个人因素，如代码风格、技术知识水平、经验不足等也会成为风险因素；7. 测试风险：测试是软件开发的重要环节，其失误都可能导致软件最终的效果被大幅降低。
二、软件开发的风险评估软件开发的风险评估是在了解和分析开发过程中可能出现的问题的基础上，对软件开发过程中的风险进行精细化的分析和判定，从而帮助开发人员制定出合理的解决方案。
传统的风险评估通常是静态的，即面对开发之初对项目的整体风险进行评估，但由于软件开发本质是一种动态、不断变幻的工作，因此这种静态的风险评估通常很难把握软件开发中随时可能出现的问题。
现代软件工程在评估风险时已经完全采用了动态评估的方法，同时结合项目管理和版本管理，及时对每一个风险进行有效判定、监测和记录，以便后续针对性地解决和调整。
常见的风险评估方法有风险概率评估、风险影响评估和弹性评估等。
1. 风险概率评估风险概率评估是通过事先分析和调查，对出现风险的可能性进行定性或定量的分析。
在该方法中，需要对各个风险进行分级，例如以一定的概率出现的风险可列为不重要级别的风险等。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
计算机软件工程风险管理研究
【摘要】：风险管理是使得计算机软件工程规避风险的一项重要措施，本文以下内容将对计算机软件工程风险管理进行研究和探讨，以供参考。
【关键词】：计算机；软件工程；风险管理
1、前言
风险管理是社会组织或者个人用以降低风险的消极结果的决策过程，通过风险识别、风险估测、风险评价，并在此基础上选择与优化组合各种风险管理技术，对风险实施有效控制和妥善处理风险所致损失的后果，从而以最小的成本收获最大的安全保障。
本文以下内容将针对计算机软件工程风险管理进行研究和探讨，以供参考。
2、计算机软件工程风险管理的目标研究
根据本人多年的实践经验，认为计算机软件工程风险管理的目标主要有如下两种：第一，损前目标。
①合法性目标。
风险管理者必须密切关注与经营相关的各种法律法规，对每一项经营行为、每一份合同都加以合法性的审视，不致于使企业蒙受财务、人才、时间、名誉的损失，保证企业生产经营活动的合法性。
②经济目标。
计算机软件工程应以最经济的方法预防潜在的损失，即在风险事故实际发生之前，就必须使整个计算机软件工程风险管理计划、方案和措施最经济、最合理，这要求对安全计划、保险以及防损技术的费用进行准确分析。
③安全状况目标。
安全状况目标就是将风险控制在可承受的范围内。
风险管理者必须使人们意识到风险的存在，而不是隐瞒风险，这样有利于人们提高安全意识，防范风险并主动配合风险管理计划的实施。
第二，损后目标。
①收益稳定目标。
保持企业经营的连续性便能实现收益稳定的目标，从而使企业保特生产持续增长。
对大多数投资者来说，一个收益稳定的软件工程项目要比高风险的企业更具有吸引力。
稳定的收益意味着软件工程项目的正常发展，为了达到收益稳定目标，企业必须增加风险管理支出。
②社会责任目标。
尽可能减轻企业受损对他人和整个社会的不利影响，因为企业遭受一次严重的损失会影响到员工、顾客，供货人、债权人、税务部门以至整个社会的利益。
为了实现上述目标，风险管理人员必须辨识风险、分析风险和选择适当的应对风险损失的方法和措施。
③生存目标。
一旦不幸发生风险事件，给软件工程企业造成了损失，损失发生后风险管理的最基本、最主要的目标就是维持生存。
实现维持生存目标是受灾风险主体在损失发生之后，在一段合理的时间内能够部分恢复生产或经营的前提。
④保持企业生产经营的连续性目标。
风险事件的发生给人们带来了不同程度的损失和危害，影响正常的生产经营活动，严重者可使生产陷于瘫痪。
3、计算机软件工程风险管理要点分析
根据本人多年的实践经验，认为计算机软件工程风险管理应注意如下几个要点：第一，识别风险。
其是试图系统化地确定对项目计划（估算、进度、资源分
配）的威胁。
通过识别已知和可预测的风险，项目管理者就有可能避免这些风险，且当必要时控制这些风险。
每一类风险可以分为两种不同的类型：一般性风险和特定产品的风险。
一般性风险对每一个软件项目而言都是一个潜在地威胁。
特定产品的风险只有那些对当前项目的技术、人员、及环境非常了解的人才能识别出来。
为了识别特定产品的风险，必须检查项目计划及软件范围说明，从而了解本项目中有什么特殊的特性可能会威胁到项目计划。
一般性风险和特定产品的风险都应该被系统化地标识出来。
识别风险的一个方法是建立风险条目检查表。
该检查表可以用来识别风险，并可以集中来识别下列常见子类型中已知的及可预测的风险。
第二，风险估算。
软件项目管理人员可以从影响风险的因素和风险发生后带来的损失两方面来度量风险。
为了对各种风险进行估算，必须建立风险度量指标体系；必须指明各种风险带来的后果和损失；必须估算风险对软件项目及软件产品的影响；必须给出风险估算的定量结果。
第三，风险应对。
风险应对过程的活动是执行风险行动计划，以求将风险降至可接受程度。
包括以下内容：对触发事件的通知作出反应，得到授权的个人必须对触发事件作出反应。
适当的反应包括回顾当前现实以及更新行动时间框架，并分派风险行动计划；执行风险行动计划，应对风险应该按照书面的风险行动计划进行；对照计划，报告进展，确定和交流对照原计划所取得的进展，定期报告风险状态，加强小组内部交流，小组必须定期回顾风险状态。
第四，进行充分论证。
软件开发是探索性很强的工作，潜在着许多失败的风险。
在可行性分析阶段，要广泛搜集相关信息，设计多种可行方案，进行充分论证。
在制定决策时，情报的数量和质量致关重要。
掌握的信息越多、越准确，才能作出正确的的决策，项目失败的风险也就相对减少；反之，承担的风险就会增大。
第五，设计先行。
在做软件工程的总体设计方案时，务必把好相关产品的选型关，确保网络、主机、系统软件与应用软件之间不要存在较大的技术兼容性问题。
在网络平台建设方案中，明确相关设备的技术参数和配置要求。
3、结尾
本文以上内容首先分析了计算机软件工程风险管理目标，随后对计算机软件工程风险管理要点进行了研究和探讨，但作为一名技术人员，我深知，必须加大对软件工程的管理，施行精细化管理，只有这样才能降低甚至避免软件工程风险，从而创造更多的效益。
【参考文献】
[1]《软件工程》宋雨等，中国电力出版社
[2] 《软件工程项目管理》张青等，电子科技大学出版社
[3] 《软件工程与项目管理案例教程》刘新航等，北京大学出版社。