基于风险因子分析的软件项目管理模型(共63页)

1、精选优质文档-倾情为你奉上基于风险因子分析的软件项目管理模型A Software Project Management Model Based on Risk Factor Analysis张宏书指导老师：金志权、邵栋二零零四年四月摘要软件项目开发过程中存在着大量不确定事件，这给项目的成功带来了风险。能否在规定的时间内交付软件产品，与项目进度计划是否合理、项目风险管理活动是否有效有很大的关系。这需要综合考虑软件项目进度计划与软件项目风险管理计划，提供工具用以标识、分析和管理软件项目风险，并在此基础上获得合理的软件项目进度计划。本文提出了基于风险因子分析的软件项目管理模型。本文通过对文献著作的研

2、究和某通讯公司软件项目的实际分析，标识出影响软件项目成功的20个风险因子，并根据其出现的比例，选择6个主要风险因子进行进一步地量化分析，分析它们各自对软件项目进度的影响，并使用蒙特卡罗模拟方法，模拟出所选择的风险因子对软件项目进度的总体影响，该影响以风险图的方式给出。同时，利用模型中识别出的主要风险因子，标识软件项目风险；综合考虑风险因子的潜在影响和项目进度的要求，制定出软件项目风险管理计划和合理的软件项目进度计划。本文实现了基于风险因子分析的软件项目管理模型，并对模型本身进行了正确性验证，也在软件项目组进行了符合项目经理需要的确认。结果显示，该模型能够帮助项目经理制定风险管理计划和合理的进度

3、计划。关键词：风险因子；模型；风险管理计划；进度计划。ABSTRACTMany uncertainties are existed in software development process, and they give rise to risk of project success. Whether the project can deliver the product to the customer in time is much dependent on its estimated schedule plan and risk management plan. It is requi

4、red to integrate software project schedule plan and software project risk management plan, and to offer tools for identifying, assessing, and managing the project risk, and to obtain a reasonable project schedule plan based on risk analysis.This paper has produced a software project management model

5、 based on risk factor analysis. Based on study of literatures and actual software projects developed in recent years of a famous communication company, twenty risk factors that affect software project success are identified. The six main risk factors are selected and further quantitative analysis of

6、 their effects to project schedule is made. Monte Carlo method is used to simulate the total effects to project schedule, and the result is described as a risk graph. The project can identify project risk based on selected risk factors. By considering the potential effects of risk factors and the pr

7、oject schedule requirement, software risk plan and a reasonable software schedule plan can be made. A software project management model has developed in this paper. Model verification is done to check its correctness, and validation is done by software projects to check whether it can satisfy projec

8、t managers needs. The results indicate that the simulation model can help project manager to prepare his risk management plan and schedule plan effectively and efficiently.Key words: risk factor, simulation model, risk management plan, schedule plan目录第一章 绪论11.1本文研究的背景及问题11.2软件估计常用方法31.3风险管理过程框架51.4常

9、用的风险识别和风险评估方法71.5本文的工作10第二章 软件项目的风险因子112.1风险的定义112.2风险的影响纬度112.3风险的量化定义122.4风险因子的定义142.5软件项目风险因子标识方法15第三章 主要风险因子的潜在影响分析173.1实际软件项目的风险因子标识173.2主要风险因子原因结果图193.3风险因子影响调查253.4风险因子影响图曲线263.5软件主要风险因子对项目进度的总体影响42第四章 基于风险分析的软件项目管理模拟模型444.1风险因子与不确定性444.2软件项目风险因子454.3模拟模型464.4基于风险分析的软件项目管理模拟模型介绍474.5基于风险分析的软件

10、项目管理模拟模型的实现484.6模拟模型使用案例524.7模型验证55第五章 总结与展望56参考文献57致谢59专心-专注-专业第一章 绪论1.1 本文研究的背景及问题软件已经成为基于计算机的系统及产品成功的关键因素，其重要作用已经得到了人们的普遍认同。在过去的50年中，软件已经从特殊的问题解决和信息分析工具演化为一门独立的产业，但在提供客户所需要的软件的能力方面取得的进展却非常缓慢。软件项目失控现象依然大量存在失控项目的定义KPMG 1995：软件失控项目是显著未能实现目标和（或）至少超出原定预算30%的项目。KPMG在1995年对英国大约250个主要企业进行了软件项目调查，结果表明84%的

11、企业经历过失控项目。著名的CHAOS报告（2003）28中的一些统计数据如下：66%的软件项目失败，15%的软件项目在完成前被取消；82%的软件项目交付延期，43%的软件项目实际成本超过预算，48%的客户需求没有得到满足。造成以上现象的原因有很多，Jones（1994）23针对交付延期和预算超支的现象，归纳出以下四个根本原因：1、在项目初始估计时，进度/成本就是不可能达到的目标，但项目还是如期启动了；2、在项目进度/成本确定后，项目范围发生了变化；3、项目估计和计划的方法不合理；4、企业没有收集有用的历史数据。在软件业，学术界和企业界都越来越强烈地相信，没有一个独立的方法、技术、工具或过程能够

12、解决软件项目失控问题，驾御项目失控最好的方法是从开始就管理项目的风险。KPMG 199524报告中列举的项目失控企业，55%的失控项目没有实行过任何风险管理，而在38%实行了风险管理(有些调查者不知道是否实行了风险管理)的项目中,有50%的项目在启动之后没有使用风险发现(Risk Finding)，缺少风险管理可能会导致项目失控的事件。管理项目风险的好处是明显的，Boehm（1989）认为，风险管理之所以重要，是因为它使得人们脱离灾难，避免返工，并促使软件项目取得双赢的局面。Jones认为软件项目计划不合理是软件项目交付延期的主要原因。大多数人在做项目计划时比较乐观，倾向于忽视某些“可能需要做

13、”的工作，而不是把“可能不需要做”的工作也计算在内。“可能需要做”与“可能不需要做”这种不确定性事件正是风险管理的内容。因此，在制定软件项目进度计划时，考虑风险对软件项目的潜在影响，并将这种影响落实到软件项目进度计划中，将避免过度的项目进度压力现象。Kemerer（1991）8认为进度压力常常在项目的后期出现，并对项目带来三个主要方面的影响：1、经济影响。后期发现项目无论如何也不能在接近计划范围内完成，常常导致项目被取消，同时到此为止的所有工作都将前功尽弃。2、产品质量影响。当项目计划的成本或进度目标临近，但还剩余大量附加工作时，为了按照计划或接近计划完成项目，一般会缩减最终任务。当最终期限到

14、来时，在无法确定交付产品质量的情况下，项目常常会停止测试而简单进行交货。3、组织影响。当不切实际的最终期限临近时，为了尽快完成项目，全体开发人员可能要忍受被施加的附加压力。这种压力除了有可能会对工作质量产生短期不利影响之外，对士气的长期影响也是巨大的。如果在项目开发的后期，给项目组增加人力，又可能产生所谓的布鲁克斯（Brooks 1974）现象：给后期项目增加人力，会导致项目推迟完成。如果这样的问题遍布整个组织，那么，将产生一种“恐慌心理”。在软件领域，关于项目风险管理和项目进度计划主题的文献著作很多。Boehm（1991）在他的软件风险管理：原理和实践30一文中提出一种软件项目风险管理的方法

15、，他将风险管理划分为风险评估和风险控制，并对每一种分类提供了许多步骤。对每一个步骤都给出了一个简短的技术列表，并附有TRW一些实际项目的例子。一组有用的图表说明了这些技术，包括项目风险因子的Top Ten列表。Fairley（1994）在他的软件项目的风险管理8一文中验证了Boehm的方法在电信软件项目中的应用，他充分利用了COCOMO成本估算模型来估计风险因子对预算的影响，并且证明了人们可以利用统计学方法求出可能产生结果的预期范围。软件进度计划方面的研究主要体现在两个方面。一方面关注如何提高进度估算的能力，Boehm（1981）在他的软件工程经济学32一书中提出了COCOMO成本估计模型；V

16、icinaca等人（1991）在软件投入估计中以案例为基础的论证8中使用人工智能领域的技术开发了一个以知识为基础的成本估计系统；Abdel-Hamid（1989）在从软件开发动力学的模拟中学习的课程8中使用系统动力学开发了一个成本估计模型，该模型可以重复一些共同的现象，如布鲁克斯规则。进度计划研究的另外一个方面关注如何安排项目进度，主要的技术有关键路径法（Critical Path Method，CPM）、关键链进度计划（Critical Chain Schedule）以及计划评审技术（Program Evaluation and Technique，PERT）；McConnell （1996

17、）在他的快速软件开发：有效控制与完成进度计划14一书中对导致乐观的软件项目进度安排的问题进行了深入讨论，并指出了你能为此做些什么；Brooks（1995）则在人月神话6一书中提出了著名的布鲁克斯规则。不难发现，软件项目风险管理的研究与项目进度计划的研究是有交集的，在考虑项目风险时，进度风险通常是考虑的重点，在制定项目进度计划时，要考虑达到进度目标可能遇到的风险。但是，将软件项目风险管理与项目进度计划有机地结合起来的综合研究还鲜见于文献资料。本文提出一种基于风险因子分析的软件项目管理模型，能方便地帮助软件项目标识出主要的风险因子，并量化分析风险因子对项目进度的影响，最终给出合理的项目交付进度计划

18、。1.2 软件估计常用方法软件项目管理过程总是从项目计划开始。在项目可以开始前，管理者和软件小组必须估计将要完成的工作、所需要的资源以及从开始到完成所需要的时间。软件估计需要经验、以前项目的有用信息，以及当仅存在定性的数据时进行定量估计的勇气。软件估计是一项预测未来的工作，天生具有某种程度的不确定性，Kemerer描述了由于估计不准而给项目造成的经济、质量和组织影响。为了解决这些估计不准的问题，软件业界对估计做了大量的研究，提出了许多软件估计方法和工具。由于软件进度估计总是依赖于软件工作量估计和可以投入的软件人力资源，在人力资源投入策略确定后，软件开发工作量与软件项目进度的对应关系就确定了。所

19、以本文仅仅介绍常用的软件工作量估计方法。1.2.1 算法模型估计方法算法模型估计方法又称参数估计方法，它使用特定的数学公式进行软件工作量估计，该公式是经过一定的理论推导或者通过历史项目经验数据总结而得到的。参数估计方法的输入通常有软件代码行规模，软件功能点数，以及设定的工作量驱动因子。参数估计方法的准确度可以通过校正因子处理而得到提高。参数估计方法的最大优点是能够重复进行估计，输入参数可以方便地进行调整，所使用的数学公式也可以进行优化。其最大缺点是不能处理意外情况。参数估计方法的例子有：COCOMO（结构成本模型）COCOMO方法是Boehm 1981年在其著名的软件工程经济学32中提出的一种

20、软件估计方法，它实际上是一个包含三个详细程度（Basic，Intermediate，Advanced）逐渐增加的层次模型结构。COCOMO方法又根据待开发软件的特点，分为组织式、半分离式和嵌入式三种模式。COCOMO估计模型具有以下形式：式中，MM是以人月为单位的工作量，TDEV是以月表示的项目持续时间，EAF是成本调整因子（对于Basic模型，EAF=1），a，b，c，d的取值与模式有关。一个简单的例子：一个飞行器控制系统，其代码规模为319KDSI，属于嵌入式模式。可靠性要求非常高，故a取1.40。计算结果如下：工作量 Effort =进度 Schedule=平均人力资源投入=SLIM（软

21、件方程式模型）SLIM方法是在20世纪70年代后期由QSM组织的Putnam开发的，它是一个动态的多变量模型。该模型假设在软件开发项目整个生命周期中存在一个特定的工作量分布曲线。该模型是从4000多个当代软件项目中收集的生产率数据中导出的。基于这些数据，估计模型具有以下形式：式中，E为以人月或人年为单位的工作量，t为以月或年表示的项目持续时间，B为“特殊技能因子”，随着“对集成、测试、质量保证、文档及管理技能的需求的增长”而缓慢增加。对于较小的软件（515 KLOC），B=0.16，对于规模超过70KLOC的较大软件，B=0.39；P为“生产率参数”，对于实时嵌入式软件的开发，典型值是P=20

22、00，对于电信及系统软件，P=10000，而对于商业系统应用，P=28000，当前项目的生产率参数可以通过从以前的开发工作中收集到的历史数据中导出。1.2.2 专家评价法专家评价法使用专家的知识和经验，对软件项目的工作量进行估计。专家估计方法在缺乏量化的历史数据时比较有用，而且专家估计方法可以根据项目的特点，识别出与以前项目的不同之处，并进行估计修正。专家估计方法的缺点就是估计结果完全依赖于估计专家。常用的专家估计方法有Delphi专家估计方法。Delphi方法由Rand公司在1940年提出，各估计专家采用匿名的方式进行软件估计，相互之间保密各自的估计结果。Delphi方法鼓励参加者就问题相互

23、讨论，要求有多种软件相关经验人的参与，互相说服对方。Delphi方法的步骤是：1、协调人向各专家提供项目规格和估计表格； 2、协调人召集小组会议，各专家讨论与成本相关的因素；3、各专家匿名填写估计表格；4、协调人整理出一个估计总结，当估计差异较大时，将估计结果返回专家；5、协调人召集小组会议，讨论较大的估计差异；6、专家复查估计、总结，并提交另一个匿名估计；7、重复4-6，直到达到一个可以接受范围内的估计。1.2.3 Top-Down（自上而下法）根据软件产品的总体特性来估计项目的总成本。然后，将总成本分解到各组成部分。1.2.4 Bottom-Up（自下而上法）先分别估计软件项目每一组成部分

24、的成本，再将它们综合起来得到整个项目的成本估计。1.2.5 Estimation by Analogy（类比法）该方法通过与一个以上已完成项目进行类比来进行推理，把实际成本与一类似新项目的成本估计联系起来。类比法估计方法基于有代表性的经验，但对项目之间的类似程度有多大缺乏量化的数值，并且在没有类似历史项目的情况下无法使用。1.2.6 Price to Win Estimation（成功代价法）这里，成本估计等同于被认为是工作成功所必要的代价（或者是新产品首次出现在市场上所必须的进度安排等等）。成功代价法估计结果经常能帮助取得契约合同，但常常会导致实际结果大大超出限度。1.3 风险管理过程框架本

25、文提出的基于风险因子分析的软件项目管理模型中关于风险管理相关活动符合业界风险管理过程框架定义。Charette（1989）22、Boehm（1991）30、Higuera and Haimes（1996）31提出的风险管理框架如表1-1所示。表1-1 典型的风险管理框架CharetteBoehmHiguera and Haimes风险分析与管理风险分析 风险标识 风险估计 风险评估风险管理 风险计划 风险控制 风险监控风险管理风险评估 风险标识 风险分析 风险优先级分配风险控制 风险管理计划 风险解决 风险监控SEI风险管理风险标识风险分析风险计划风险跟踪风险控制风险沟通1.3.1 Chare

26、tte风险管理框架在Charette风险管理框架中，风险分析和风险管理各由三个可以重叠的过程组成。风险分析包括风险标识、风险估计和风险评估三个过程：风险标识是试图系统化地确定对项目计划的威胁，并将识别的风险分类。风险估计从两个方面评价每一条已识别的风险风险发生的可能性以及风险发生后所产生的后果。风险评估就是进一步审查在风险估计阶段所做的估计的精确度，试图为所发现的风险排出优先次序，并开始考虑如何控制和/或避免可能发生的风险。风险管理包括风险计划、风险控制和风险监控：风险计划就是确定对项目中可能遇到风险的措施，并形成明确的计划。风险控制就是根据既定的风险计划实施具体的活动。风险监控就是在针对风险

27、的措施落实后，观察其效果是否与计划的一致，这常常通过监控某些指标来实现，这些指标可以提供风险是否正在变高或变低的指示。风险监控提供了风险计划改进的机会。1.3.2 Boehm风险管理框架Boehm的风险管理方法包括两个主要步骤，每一步又各自包含三个小步骤。第一个主要步骤，即风险评估，包括风险识别、风险分析和风险优先级分配：风险识别产生特定项目详细风险的列表，这些风险可能对一个项目的成功起阻碍作用。风险分析评估每一条已识别风险的损失的概率和损失的大小，并评估风险互相作用时产生的综合风险。风险优先级分配对已识别和分析过的风险进行排序。第二个主要步骤是风险控制，包括风险管理计划、风险解决和风险监控。

28、风险管理计划有助于准备确定各种风险应对方式（如风险转移、风险规避、风险降低等），包括单个风险项计划之间的协调和与总体项目计划之间的协调。风险解决，就是采用某种措施，使风险项得到消除或者由此得到了解决（比如通过降低要求来规避风险）。风险监控，跟踪项目风险的状态，并在适当的时候采取纠正措施。1.3.3 SEI SEI：Software Engineering Institute，美国Carnegie Mellon大学的软件工程研究所，发布过系列能力成熟度模型SW-CMM，SE-CMM，P-CMM，CMMI等。的风险管理框架SEI的Higuera与Haimes提出的持续风险管理框架（CRM）包括风险

29、识别，风险分析、风险计划、风险跟踪、风险控制和风险沟通。其中风险识别、分析、计划、跟踪、控制等活动以环型的方式组织，表明其持续的特征。另外，SEI将风险沟通置于模型的中心位置。这是因为，如何没有有效的风险沟通，任何一种风险管理方法都是不可行的。除了该模型中标识出的几大风险活动之间需要互相沟通，还有其他层次的风险沟通需要考虑，如项目与组织之间，开发人员与客户或最终用户之间。正是由于风险沟通的普遍性，SEI将风险沟通置于模型的中心位置，而不是之外，或仅仅是其他风险活动的一种补充。图1-1 SEI的持续风险管理模型图示1.4 常用的风险识别和风险评估方法1.4.1 风险识别方法头脑风暴法头脑风暴法是

30、团队通过本能地、不加判断地汇集一些想法，产生新的主意，从而找出解决某一特定问题的方案。建立一份综合风险清单的时候可能用到这一方法。Delphi方法Delphi方法是从一组专家中得到一致的意见，来预测未来的发展。它是一种以互相独立的输入为基础，对未来事件进行预测的系统化、交互式程序。Delphi方法重复使用几个回合的提问，包括来自前几轮的反馈，从而发挥团组输入的优点，同时又可以避免面对面商议中可能出现的偏见效应。如果达不成一致的意见，组织者需要确定是否过程有问题。访谈访谈是通过面对面或电话讨论的方式，收集信息、寻求事实的一种技术，访谈也可以通过电子邮件和即时信息进行。与那些具有类似项目经历的人们

31、进行面谈，是识别可能风险的重要工具。例如，如果一个新项目用到一种特殊类型的硬件和软件，那么近来使用过这种硬件或软件经验的人，可能会描述出他们在先前项目中所遇到的问题。检查表当检查表用来进行风险识别时，将项目可能发生的许多潜在风险列于一个表上，供识别人员进行检查核对，用来判别某项目是否存在表中所列或类似的风险。检查表中所列的内容都是历史上类似项目曾发生过的风险，是项目风险管理的结晶，对软件项目有开阔思路、启发联想、抛砖引玉的作用。此外，也可以通过使用Standish Group，SEI或其他组织开发的检查表，来帮助识别项目的风险。流程图流程图是一种风险识别的常用工具。借助于流程图可以帮助项目风险

32、识别人员去分析和了解项目风险所处的具体项目环节、项目各个环节之间存在的风险以及项目风险的起因和影响。1.4.2 风险评估方法概率/影响图概率/影响图是风险定性分析的方法。概率表示风险发生的可能性大小，而结果表示风险发生后所带来影响的程度。使用风险暴露值=发生概率*结果影响来评价风险。图1-2 风险概率/影响示意图专家判断法专家判断法是依赖专家们的直觉和以往的经验来代替或补充数学分析技术，专家可以使用或不使用较为复杂的技术，例如，无须计算风险暴露值，直接把风险定为高、中和低三种。决策树决策树是一种图形化的风险量化分析方法，可以帮助在未来结果不确定的情况下，选择最好的行动路径。模拟模拟是指用系统的

33、模型或表示法来分析系统的预期行为或绩效，也是一种量化分析方法。大多数模拟都以某种形式的蒙特卡罗（Monte Carlo）分析为基础。蒙特卡罗分析通过多次模拟一个模型的结果，从而提供计算结果的统计分布。图1-3 决策树风险分析方法示意图蒙特卡罗法的基本原理假定函数Y=f（X1，X2， , Xn）,其中变量X1，X2， , Xn概率分布为已知。但在实际问题中，f（X1，X2， , Xn）往往是未知的，或者是一个非常复杂的函数方程式，一般难以用解析法求解有关Y的概率分布及其数字特征。蒙特卡罗法利用一个随机数发生器，通过直接或间接的方式抽样取出每一组随机变量（X1，X2， , Xn）的值（X1t，X2

34、t， , Xnt），然后按Y对于（X1，X2， , Xn）的关系式确定函数Y的值Yt,Yt,=f（X1t，X2t， , Xnt ）反复独立抽样（模拟）多次，便可以得到函数Y的一批抽样数据Y1, Y2, , Yn，当模拟次数足够多时，便可以给出与实际情况相近的函数Y的概率分布及其数字特征。1.5 本文的工作本文通过对文献著作的研究和某通讯公司软件项目的实际分析，标识出影响软件项目正常运作的20个风险因子，并根据其出现的比例，选择6个风险因子进行进一步的量化分析，分析风险因子对项目进度的影响程度，并使用Monte-Carlo方法，建立项目进度计划模型。该模型的主要功能有：1、帮助软件项目标识项目风

35、险2、制定风险管理计划3、制定项目进度计划本文关注于软件企业软件开发项目的风险管理和项目进度计划制定，对于个人软件开发、维护项目等不涉及，软件项目风险对产品质量的影响也不涉及。第二章 软件项目的风险因子2.1风险的定义虽然对于软件风险的严格定义还存在很多争议，但在风险包含了如下两个特性这一点上已经达成共识：不确定性风险可能发生，也可能不发生；也就是说，没有100%发生的风险。损失如果风险变成了事实，就会产生恶性后果或损失。Webster字典（1981）将“风险”定义为“可能的损失、损伤、缺点、破坏”。SEI接受了这个说法，并将风险定义为“可能的损失”。为了使风险的描述能够被理解，SEI规定风险

36、的描述必须包括两个部分：1）可能导致损失的当前状况描述；2）损失的描述。一个符合要求的风险例子是：项目组成员缺乏面向对象技术的经验和培训，可能导致无法在规定的时间范围内推出满足客户性能需求或功能需求的产品。Charette（1989）在他的软件风险分析与管理22一书中将隶属于某一活动、事件或事物的风险进一步定义为如下三个部分：1）活动、事件或事物附带的损失。2）损失在现有条件下发生的不确定性。3）将影响到产出（如损失程度等）的一些行为选择。Charette风险定义与其他定义的不同点主要在于第3）部分。行为选择给后续的风险管理活动提供了依据。项目组在风险被标识后，将根据这些选择做进一步的分析和决

37、策，选择合理的措施，使得风险带来的损失最小，而该活动、事件或事物本身的效益则最大化。2.2风险的影响纬度对一个软件项目实际状态的测量主要包括四个纬度：功能、质量、进度和成本，这与软件项目的目标是一致的，即在规定的时间和成本范围内，提供高质量的符合客户需要的产品。功能（F）可以使用一组产品特性（pf）及其重要程度（fw）来定义，如下：F（pfi，fwi）| i=1，n质量的一种简单化表示是由软件项目所包含的缺陷来定义的。因此，质量（Q）可以使用一组缺陷（pd）及其严重程度（dw）来定义，如下：Q（pdi，dwi）| i=1，n对于进度，一般使用期望完成的日期来表示，如“2005-06-30”；对

38、于成本，通常使用人力成本或开发工时来表示。如“￥50000”、“3000人时”。根据风险的定义，风险是指“可能的损失”，因此，风险对软件项目的影响也主要体现在这四个纬度上，这四个纬度上的任何偏差或不确定性都是软件项目组要关心和控制的。特别地，进度纬度上的偏差和不确定性是所有四个纬度中最需要重点关注的。2.3风险的量化定义通常“风险”被量化地定义为发生潜在损失的可能性与潜在损失两者的乘积。Boehm将之称为“风险暴露”（Risk Exposure）。风险暴露可以通过下面的关系式表现出来：RE=P（UO）*L（UO）其中RE是风险暴露，P（UO）代表结果不令人满意的概率，L（UO）表示由于结果不令

39、人满意而给被影响者造成的损失。基于以上的基本定义，一种常见的风险量化定义为：Risk（Pi，Li）| i=1，n式中，Pi表示某种损失出现的可能性，Li表示损失的大小Charette（1989）22认为对于每一个潜在的损失，必须相应地定义一个场景，该场景描述了风险的原因或者触发因素。他给风险定义了一个三元组：在什么场景下将会出现损失（Si），出现这种损失的可能性（Li），这种损失的大小（Xi），具体表示如下：Risk（Si，Li，Xi）| i=1nCharette的定义还存在一个问题，即“低可能性，高损失”的风险与“高可能性，低损失”的风险在数值上的表现是一样的。很明显，对于能带来10万元收益

40、而潜在损失为200元的风险与能带来1000元收益而潜在损失为200元的风险是不一样的。为了克服以上不足，Henley和Kumamoto（1996）加入了效益或产出（Oi）指标。这种风险定义的具体表示如下：Risk（Si，Oi，Li，Xi）| i=1n上述几种风险的量化定义方式均是“以数字的形式考虑风险”。Demarco与Lister（2004）在他们的与熊共舞：软件项目风险管理3一书中提出了“用图形的方式考虑风险”风险图的概念。设想你是一个软件项目经理，你的项目计划在10月30日之前完工。你清楚地感觉到不可能在10月30日之前完成任务；但除此以外，你一无所知。你对项目的进度毫无把握，手下的员工

41、也一样。于是，仲夏时节，离最后期限还剩4个月的时候，你找来了一名顾问圈子里最好的顾问，就算他睡着了也能判断出项目的处境。经过几天的工作阅读规格书、检查阶段性成果、会见团队成员和客户代表。之后，他告诉了你真相：“听着，这个项目根本没有可能在明年1月之前完成。最有可能交付一个象样产品的时间是明年4月初，而且这个日期也不能打包票。你最好不要承诺在5月1日前的任何时间交付，至少应该承诺在5月以后，这样你成功的机会大概有一半。如果你想一个几乎不可能失败的日期，那大概会是明年的12月。”之所以找来一名顾问，正是因为你不敢肯定项目什么时候能完成。但看起来这位顾问先生自己也多少有些不确定。你的不确定（完全盲目

42、）与他的不确定之间的区别在于：他给不确定性画定了明确的界限。可以用一幅图来表示这位顾问的估计。既然他谈到的都是可能性的问题，这幅图也就借助“某一日期交付的概率”来展现不确定性。用纵轴表示可能性，横轴表示时间，如图2-1所示：图2-1 项目交付日期不确定性图这幅描述不确定性的图形，就叫不确定性图。当不确定的东西与项目的成败休戚相关时，描述它的不确定性图就被称为风险图。风险图最重要的特征有：曲线下方的区域表示“在某一特定日期之前完工的”总的可能性。也就是说，如果有1/3的区域位于4月1日的左侧，就表示在4月1日当天或之前完成项目的可能性为33%。整条曲线下方区域的面积为1.0，这就是顾问对项目的整

43、体评估：项目一定会在明年1月1日至12月31日之间的某个时间完成。上述风险图还可以等价地表示为另一种形式累积风险图，如图2-2所示。累积风险图表示了在某一日期或之前完成项目的累积可能性，相应地，表示某一日期完成相对可能性的风险图则称为增量风险图。基于风险图的观点，Demarco与Lister将风险量化地定义为：风险是描绘所有可能结果及由其引发的相关后果的加权图。图2-2 累积风险图示意图Demarco与Lister给出了风险图和风险的定义，也指出了风险图必须基于历史项目数据得到。但对于如何有效得到这些风险图，并没有给出方法上的指导。本文试图从影响项目的关键风险因子研究出发，借助风险图的方法，量

44、化地研究风险因子对项目进度的影响。2.4风险因子的定义何文炯（1999）在他的风险管理17一书中对风险因子作了比较完整的定义。他认为风险因子是促使或引起风险事件发生的条件，以及风险事件发生时，致使损失增加、扩大的条件。风险因子是风险事件发生的潜在因素，是造成损失的间接的和内在的原因。关于风险因子的称呼有多种，有叫“风险因素”，有叫“风险源”的，英文叫“Hazard”。本文统一称为“风险因子”。软件项目开发过程中的需求膨胀，对项目进度延迟而言，就是风险因子。根据其性质，通常把风险因子分成实质风险因子（Physical Hazard）、道德风险因子（Moral Hazard）和心理风险因子（Mor

45、ale Hazard）三种。实质风险因子是指增加风险事件发生机会或扩大损失严重程度的物质条件，它是一种有形的风险因子。例如，缺乏合适的开发、测试环境对于项目进度的危害，关键技术不熟悉对于生产率降低等，都是实质性风险因子。道德风险因子是指与人的不正当社会行为相联系的一种无形的风险因子。常常表现为由于恶意行为或不良企图，故意促使风险事件发生或损失扩大，例如偷工减料引起质量事故就属于道德风险因子。心理风险因子也是一种无形的风险因子，但与道德风险因子不同。它是指由于人的主观上疏忽或过失，导致增加风险事件发生机会或扩大损失程度。例如，由于设计方案的错误选择导致软件项目失败，项目组成员的非正常退出而没有进

46、行必要的分析和采取适当的措施等等，都属于心理风险因子。风险因子、风险事件以及危害之间的关系可以通过图2-3来表示：图2-3 风险因子、风险事件、危害关系图前面提到的Charette风险三元组（Si，Li，Xi）中，根据项目场景Si的定义，Si可以表示为一系列风险因子（记为rf）和时间（记为t）的函数，如下：Si=（rfi1，rfi2， rfin，ti）| i=1.n一个将导致项目进度延期风险事件的Si例子描述如下：30%需求变更，没有变更控制，进度没有缓冲，编码阶段对于一个软件项目而言，存在着许多场景，其中某几个场景决定了项目的成败。标识对项目起关键作用场景所包含的风险因子是一项有意义的工作，

47、文献资料中已经有一些这方面的研究，将在后面叙述。2.5软件项目风险因子标识方法本节简单介绍标识软件项目风险因子的两种方法。基于项目成本驱动因子典型的例子是Madachy（1997）27使用COCOMO模型中的成本驱动因子，开发了一套专家系统，用来识别软件项目风险。Madachy将成本驱动因子看作是软件项目的风险因子，并评估它们的影响。Madachy在他的系统中使用的COCOMO模型中的成本驱动因子如表2-1所示。文献资料整理或问卷调查Boehm（1991）30调查了一些有经验的项目经理，整理出了软件项目的10个主要风险因子，如表2-2所示。Jones（1994）23以医学手册的方式对一些软件公

48、司项目进行诊断，总结出大约60种风险因子，并标识出了10种最严重的风险因子，如表2-3所示。表2-1 COCOMO模型成本驱动因子产品属性要求的可靠性数据库规模产品复杂程度要求的重用文档化人员属性分析人员能力程序员能力人员持续性应用领域经验平台经验程序语言及工具经验平台属性执行时间约束主要存储约束平台易变性项目属性软件工具的使用异地开发要求的开发进度表2-2 TOP 10风险因子表1人员不足2不现实的进度计划和预算3开发错误的功能4开发错误的用户界面5夸大软件的功效6持续不断的需求变化7外部购买组件的不足8外包开发的不足9实时性能的不足10计算机资源能力的限制表2-3 Jones的10大风险因

49、子1不精确的度量2度量不足3过多的进度压力4管理部门玩忽职守5不精确的成本评估6银弹综合症7迟缓的用户需求8质量低9生产率低10取消项目第三章 主要风险因子的潜在影响分析3.1实际软件项目的风险因子标识本文所研究的项目来自国内一家著名通讯软件公司，该公司的业务主要聚焦于数据通讯产品、业务与软件产品、网管软件产品等领域，目前有软件开发人员600名左右。本文选择分析的软件项目共有207个，包括了该公司近3年来的所有软件项目。所选择的软件项目大多数使用了V模型的软件开发过程，其他的如增量开发过程、原型演进开发过程等也有应用，对规模很小的项目则大多数使用了编码-测试的简化过程。图3-1 软件开发过程种

50、类分布图软件项目的开发周期长度大多集中在412个月，最长的为16个月，最短的为1个月。图3-2 软件项目开发周期长度分布图软件项目运作过程中的峰值人力投入根据项目的不同而有变化，最少投入在2个人，最多投入在48个人。图3-3 软件项目人力投入分布图根据业务领域的不同，各软件项目组在设计实现时，使用了不同的编程语言。图3-4 软件项目使用开发语言分布图 SCE：Service Construct Environment 业务生成环境，是基于特定平台的一种业务生成语言。在这207个软件项目中，产品规模（以开发工作量人月计算）也分布广泛。图3-5 软件项目产品规模分布图项目经理们的项目管理经验也各不

51、相同，有的仅有1年管理经验，而有的管理经验则在10年以上。图3-6 项目经理管理年限分布图3.1.1实际软件项目风险因子标识方法1、如果所选软件项目存在风险管理计划，则提取出风险管理计划中标识的所有风险；2、对提取出的风险，针对其风险描述进行分析，并归纳出相应的风险因子；3、如果所选软件项目存在项目结束总结报告，则提取出总结报告中所反映的影响项目质量、进度、工作量的所有项目问题；如果某问题已经在该项目的风险管理计划中提及，则去除该问题，以避免重复统计；4、对所提取出的项目问题，针对问题描述进行分析，并归纳出相应的风险因子（“今天的问题就是明天的风险”）；5、综合风险管理计划和项目结束总结报告中

52、出现的风险因子，并统计这些风险因子出现的数目。在所选择的207个软件项目中，有192份风险管理计划。该公司允许时间跨度在2个月以内的小型软件项目可以不做单独的风险管理计划，但有些小型项目做了单独的风险管理计划。所选择的每一个软件项目都有项目结束总结报告。从风险管理计划和项目结束总结报告中提取出的风险因子及其数目如图3-7所示，从中标识出的20种软件项目风险因子如表3-1所示。3.2主要风险因子原因结果图为了进一步研究这些风险因子对项目进度的影响，又从中选择了6个风险因子，通过问卷调查的方式，量化分析它们对项目进度的潜在影响。之所以选择这6个风险因子，主要是因为它们在项目风险因子标识过程中出现的

53、比例较高，以及它们对项目进度的影响较大。这6个风险因子如表3-2所示。图3-7 实际软件项目统计风险因子分布图表3-1 实际软件项目统计之20种风险因子列表序号风险因子1需求膨胀2缺乏关键人员3依赖几个关键人员4项目经理经验不足5项目成员流失或投入不稳定6项目成员士气低下7项目大、复杂8不正确的度量9缺乏高层管理的承诺10缺乏量化的历史数据11对项目平台/环境/方法不熟悉12工作量估计不准确13过度的进度压力14配置管理不充分15不熟悉产品使用环境/操作方法16过度依赖单个开发改进17过多的复杂外部接口18不成熟的技术19低生产率20关键资源不足表3-2 6种主要风险因子及其说明序号风险因子说

54、明1需求膨胀在已经确认的需求基线基础上，增加了新的需求，或者删除了已有的需求，或者是原有需求发生了变更2工作量估计不准确由于缺乏历史数据，或者是没有使用有效的估计方法，导致工作量估计值与实际值不一致3项目组成员流失项目组成员在其承诺的任务完成之前离开项目组，或者是其实际投入不能满足承诺的目标4对项目平台/环境/方法不熟悉对项目开发所依赖的平台/环境或者所使用的开发方法不熟悉5缺乏关键人员项目组缺少满足其特定要求的人员，如缺乏有经验的需求分析人员、测试人员等6缺乏高层管理的支持和承诺高级管理者对项目不支持或保持中立状态，表现为不能给项目足够的资源，在项目出现困难时，不能帮助项目度过难关在实施问卷

55、调查之前，为了帮助项目经理理解风险因子及其潜在的影响，特别准备了这些风险因子的原因结果图形。原因结果图形是Eden和Ackerman 在1992年提出的一种图形化描述系统原因与结果关系的建模方法，使用原因结果图形可以清楚地表示风险因子的潜在影响。原因结果图形由标签、标签之间的连结线段组成，这些线段带有箭头用以表示方向，在箭头的旁边还带有正（+）、负（-）号。每一个标签表示一个原因或者一个结果，当箭头指向某个标签时，则该标签表示一个结果，连接线段的另一端标签则表示一个原因，因此，原因结果图形中的一个标签既可能是一个结果，同时又可能是另一个结果的原因。箭头旁边的符号则表示结果变化的方向与原因的变化方向是否一致，当符号为正号时，则表示随着原因增长时，结果也相应地增长；当符号为负号时，则表示当原因增长时，结果却相应地减少。图3-8是原因结果图形的一个简单例子，当项目开发过程中需求持续膨胀时，设计返工的工作量随之增加。图3-9则表示了原因结果图形的另外两种特征，符号为负号的路径以及增强正反馈路径。过度的进度压力在短期内可以提高生产率，但同时也增加了员工的疲惫程度；疲惫程度加大后，导致生产率下降。正反馈路径出现在：由于疲惫程度加大，引发更多的缺陷，造成更多的返工，进而使得进度压力更大。图3-8 需求膨胀导致设计返工原因结果示意图图3