基于风险因子分析的软件项目管理模型

基于风险因子分析的软件项目管理模型

A Software Project Management Model

Based on Risk Factor Analysis

张宏书

指导老师：金志权、邵栋

二零零四年四月

南京大学硕士论文

摘要

软件项目开发过程中存在着大量不确定事件，这给项目的成功带来了风险。能否在规定的时间内交付软件产品，与项目进度计划是否合理、项目风险管理活动是否有效有很大的关系。这需要综合考虑软件项目进度计划与软件项目风险管理计划，提供工具用以标识、分析和管理软件项目风险，并在此基础上获得合理的软件项目进度计划。

本文提出了基于风险因子分析的软件项目管理模型。本文通过对文献著作的研究和某通讯公司软件项目的实际分析，标识出影响软件项目成功的20个风险因子，并根据其出现的比例，选择6个主要风险因子进行进一步地量化分析，分析它们各自对软件项目进度的影响，并使用蒙特卡罗模拟方法，模拟出所选择的风险因子对软件项目进度的总体影响，该影响以风险图的方式给出。同时，利用模型中识别出的主要风险因子，标识软件项目风险；综合考虑风险因子的潜在影响和项目进度的要求，制定出软件项目风险管理计划和合理的软件项目进度计划。

本文实现了基于风险因子分析的软件项目管理模型，并对模型本身进行了正确性验证，也在软件项目组进行了符合项目经理需要的确认。结果显示，该模型能够帮助项目经理制定风险管理计划和合理的进度计划。

关键词：风险因子；模型；风险管理计划；进度计划。

2

南京大学硕士论文

ABSTRACT

Many 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 required 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 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 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 project 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 project manager's 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

3

南京大学硕士论文

目录

第一章 绪论 ..................................................................................................................................... 1

1.1 本文研究的背景及问题 ........................................................................................... 1 1.2 软件估计常用方法 ................................................................................................... 3 1.3 风险管理过程框架 ................................................................................................... 5 1.4 常用的风险识别和风险评估方法 ........................................................................... 7 1.5 本文的工作 ............................................................................................................... 9 第二章 软件项目的风险因子 ....................................................................................................... 11

2.1 风险的定义 ............................................................................................................. 11 2.2 风险的影响纬度 ..................................................................................................... 11 2.3 风险的量化定义 ..................................................................................................... 12 2.4 风险因子的定义 ..................................................................................................... 14 2.5 软件项目风险因子标识方法 ................................................................................. 15 第三章 主要风险因子的潜在影响分析 ....................................................................................... 17

3.1 实际软件项目的风险因子标识 ............................................................................. 17 3.2 主要风险因子原因结果图 ..................................................................................... 19 3.3 风险因子影响调查 ................................................................................................. 25 3.4 风险因子影响图曲线 ............................................................................................. 26 3.5 软件主要风险因子对项目进度的总体影响 ......................................................... 42 第四章 基于风险分析的软件项目管理模拟模型 ....................................................................... 44

4.1 风险因子与不确定性 ............................................................................................. 44 4.2 软件项目风险因子 ................................................................................................. 45 4.3 模拟模型 ................................................................................................................. 46 4.4 基于风险分析的软件项目管理模拟模型介绍 ..................................................... 47 4.5 基于风险分析的软件项目管理模拟模型的实现 ................................................. 48 4.6 模拟模型使用案例 ................................................................................................. 52 4.7 模型验证 ................................................................................................................. 55 第五章 总结与展望 ....................................................................................................................... 56 参考文献 ......................................................................................................................................... 57 致谢................................................................................................................................................. 59

4

南京大学硕士论文

第一章 绪论

1.1 本文研究的背景及问题

软件已经成为基于计算机的系统及产品成功的关键因素，其重要作用已经得到了人们的普遍认同。在过去的50年中，软件已经从特殊的问题解决和信息分析工具演化为一门独立的产业，但在提供客户所需要的软件的能力方面取得的进展却非常缓慢。软件项目失控现象依然大量存在1。著名的CHAOS报告（2003）[28]中的一些统计数据如下：

66%的软件项目失败，15%的软件项目在完成前被取消；

82%的软件项目交付延期，43%的软件项目实际成本超过预算，48%的客户需求没有得到满足。

造成以上现象的原因有很多，Jones（1994）[23]针对交付延期和预算超支的现象，归纳出以下四个根本原因：

1、在项目初始估计时，进度/成本就是不可能达到的目标，但项目还是如期启动了； 2、在项目进度/成本确定后，项目范围发生了变化； 3、项目估计和计划的方法不合理； 4、企业没有收集有用的历史数据。

在软件业，学术界和企业界都越来越强烈地相信，没有一个独立的方法、技术、工具或过程能够解决软件项目失控问题，驾御项目失控最好的方法是从开始就管理项目的风险。[KPMG 1995][24]报告中列举的项目失控企业，55%的失控项目没有实行过任何风险管理，而在38%实行了风险管理(有些调查者不知道是否实行了风险管理)的项目中,有50%的项目在启动之后没有使用风险发现(Risk Finding)，缺少风险管理可能会导致项目失控的事件。管理项目风险的好处是明显的，Boehm（1989）认为，风险管理之所以重要，是因为它使得人们脱离灾难，避免返工，并促使软件项目取得双赢的局面。

Jones认为软件项目计划不合理是软件项目交付延期的主要原因。大多数人在做项目计划时比较乐观，倾向于忽视某些“可能需要做”的工作，而不是把“可能不需要做”的工作也计算在内。“可能需要做”与“可能不需要做”这种不确定性事件正是风险管理的内容。因此，在制定软件项目进度计划时，考虑风险对软件项目的潜在影响，并将这种影响落实到软件项目进度计划中，将避免过度的项目进度压力现象。Kemerer（1991）[8]认为进度压力常常在项目的后期出现，并对项目带来三个主要方面的影响： 1

失控项目的定义[KPMG 1995]：软件失控项目是显著未能实现目标和（或）至少超出原定预算30%的项目。KPMG在1995年对英国大约250个主要企业进行了软件项目调查，结果表明84%的企业经历过失控项目。

1

南京大学硕士论文

1、经济影响。后期发现项目无论如何也不能在接近计划范围内完成，常常导致项目被取消，同时到此为止的所有工作都将前功尽弃。

2、产品质量影响。当项目计划的成本或进度目标临近，但还剩余大量附加工作时，为了按照计划或接近计划完成项目，一般会缩减最终任务。当最终期限到来时，在无法确定交付产品质量的情况下，项目常常会停止测试而简单进行交货。

3、组织影响。当不切实际的最终期限临近时，为了尽快完成项目，全体开发人员可能要忍受被施加的附加压力。这种压力除了有可能会对工作质量产生短期不利影响之外，对士气的长期影响也是巨大的。如果在项目开发的后期，给项目组增加人力，又可能产生所谓的布鲁克斯（Brooks 1974）现象：给后期项目增加人力，会导致项目推迟完成。如果这样的问题遍布整个组织，那么，将产生一种“恐慌心理”。

在软件领域，关于项目风险管理和项目进度计划主题的文献著作很多。Boehm（1991）在他的《软件风险管理：原理和实践》[30]一文中提出一种软件项目风险管理的方法，他将风险管理划分为风险评估和风险控制，并对每一种分类提供了许多步骤。对每一个步骤都给出了一个简短的技术列表，并附有TRW一些实际项目的例子。一组有用的图表说明了这些技术，包括项目风险因子的Top Ten列表。Fairley（1994）在他的《软件项目的风险管理》[8]一文中验证了Boehm的方法在电信软件项目中的应用，他充分利用了COCOMO成本估算模型来估计风险因子对预算的影响，并且证明了人们可以利用统计学方法求出可能产生结果的预期范围。软件进度计划方面的研究主要体现在两个方面。一方面关注如何提高进度估算的能力，Boehm（1981）在他的《软件工程经济学》[32]一书中提出了COCOMO成本估计模型；Vicinaca等人（1991）在《软件投入估计中以案例为基础的论证》[8]中使用人工智能领域的技术开发了一个以知识为基础的成本估计系统；Abdel-Hamid（1989）在《从软件开发动力学的模拟中学习的课程》[8]中使用系统动力学开发了一个成本估计模型，该模型可以重复一些共同的现象，如布鲁克斯规则。进度计划研究的另外一个方面关注如何安排项目进度，主要的技术有关键路径法（Critical Path Method，CPM）、关键链进度计划（Critical Chain Schedule）以及计划评审技术（Program Evaluation and Technique，PERT）；McConnell （1996）在他的《快速软件开发：有效控制与完成进度计划》[14]一书中对导致乐观的软件项目进度安排的问题进行了深入讨论，并指出了你能为此做些什么；Brooks（1995）则在《人月神话》[6]一书中提出了著名的布鲁克斯规则。

不难发现，软件项目风险管理的研究与项目进度计划的研究是有交集的，在考虑项目风险时，进度风险通常是考虑的重点，在制定项目进度计划时，要考虑达到进度目标可能遇到的风险。但是，将软件项目风险管理与项目进度计划有机地结合起来的综合研究还鲜见于文献资料。本文提出一种基于风险因子分析的软件项目管理模型，能方便地帮助软件项目标识出主要的风险因子，并量化分析风险因子对项目进度的影响，最终给出合理的项目交付进度

2

南京大学硕士论文

计划。

1.2 软件估计常用方法

软件项目管理过程总是从项目计划开始。在项目可以开始前，管理者和软件小组必须估计将要完成的工作、所需要的资源以及从开始到完成所需要的时间。软件估计需要经验、以前项目的有用信息，以及当仅存在定性的数据时进行定量估计的勇气。

软件估计是一项预测未来的工作，天生具有某种程度的不确定性，Kemerer描述了由于估计不准而给项目造成的经济、质量和组织影响。为了解决这些估计不准的问题，软件业界对估计做了大量的研究，提出了许多软件估计方法和工具。由于软件进度估计总是依赖于软件工作量估计和可以投入的软件人力资源，在人力资源投入策略确定后，软件开发工作量与软件项目进度的对应关系就确定了。所以本文仅仅介绍常用的软件工作量估计方法。

1.2.1 算法模型估计方法

算法模型估计方法又称参数估计方法，它使用特定的数学公式进行软件工作量估计，该公式是经过一定的理论推导或者通过历史项目经验数据总结而得到的。参数估计方法的输入通常有软件代码行规模，软件功能点数，以及设定的工作量驱动因子。参数估计方法的准确度可以通过校正因子处理而得到提高。

参数估计方法的最大优点是能够重复进行估计，输入参数可以方便地进行调整，所使用的数学公式也可以进行优化。其最大缺点是不能处理意外情况。参数估计方法的例子有：

COCOMO（结构成本模型）

COCOMO方法是Boehm 1981年在其著名的《软件工程经济学》[32]中提出的一种软件估计方法，它实际上是一个包含三个详细程度（Basic，Intermediate，Advanced）逐渐增加的层次模型结构。COCOMO方法又根据待开发软件的特点，分为组织式、半分离式和嵌入式三种模式。

COCOMO估计模型具有以下形式：

MMa(KDSI)b*EAF TDEVc(MM)d

式中，MM是以人月为单位的工作量，TDEV是以月表示的项目持续时间，EAF是成本调整因子（对于Basic模型，EAF=1），a，b，c，d的取值与模式有关。

一个简单的例子：

一个飞行器控制系统，其代码规模为319KDSI，属于嵌入式模式。可靠性要求非常高，故a取1.40。计算结果如下：

3

南京大学硕士论文

工作量 Effort =1.40*3.6*(319)1.205093MM 进度 Schedule=2.5*(5093)0.3238.4Months 平均人力资源投入=5093MM/38.4Months133

SLIM（软件方程式模型）

SLIM方法是在20世纪70年代后期由QSM组织的Putnam开发的，它是一个动态的多变量模型。该模型假设在软件开发项目整个生命周期中存在一个特定的工作量分布曲线。该模型是从4000多个当代软件项目中收集的生产率数据中导出的。基于这些数据，估计模型具有以下形式：

E[LOC*B0.333/P]3*(1/t4)

式中，E为以人月或人年为单位的工作量，t为以月或年表示的项目持续时间，B为“特殊技能因子”，随着“对集成、测试、质量保证、文档及管理技能的需求的增长”而缓慢增加。对于较小的软件（5~15 KLOC），B=0.16，对于规模超过70KLOC的较大软件，B=0.39；P为“生产率参数”，对于实时嵌入式软件的开发，典型值是P=2000，对于电信及系统软件，P=10000，而对于商业系统应用，P=28000，当前项目的生产率参数可以通过从以前的开发工作中收集到的历史数据中导出。

1.2.2 专家评价法

专家评价法使用专家的知识和经验，对软件项目的工作量进行估计。专家估计方法在缺乏量化的历史数据时比较有用，而且专家估计方法可以根据项目的特点，识别出与以前项目的不同之处，并进行估计修正。专家估计方法的缺点就是估计结果完全依赖于估计专家。常用的专家估计方法有Delphi专家估计方法。

Delphi方法由Rand公司在1940年提出，各估计专家采用匿名的方式进行软件估计，相互之间保密各自的估计结果。Delphi方法鼓励参加者就问题相互讨论，要求有多种软件相关经验人的参与，互相说服对方。

Delphi方法的步骤是：

1、协调人向各专家提供项目规格和估计表格；

2、协调人召集小组会议，各专家讨论与成本相关的因素； 3、各专家匿名填写估计表格；

4、协调人整理出一个估计总结，当估计差异较大时，将估计结果返回专家； 5、协调人召集小组会议，讨论较大的估计差异； 6、专家复查估计、总结，并提交另一个匿名估计； 7、重复4-6，直到达到一个可以接受范围内的估计。

4

南京大学硕士论文

1.2.3 Top-Down（自上而下法）

根据软件产品的总体特性来估计项目的总成本。然后，将总成本分解到各组成部分。

1.2.4 Bottom-Up（自下而上法）

先分别估计软件项目每一组成部分的成本，再将它们综合起来得到整个项目的成本估计。

1.2.5 Estimation by Analogy（类比法）

该方法通过与一个以上已完成项目进行类比来进行推理，把实际成本与一类似新项目的成本估计联系起来。类比法估计方法基于有代表性的经验，但对项目之间的类似程度有多大缺乏量化的数值，并且在没有类似历史项目的情况下无法使用。

1.2.6 Price to Win Estimation（成功代价法）

这里，成本估计等同于被认为是工作成功所必要的代价（或者是新产品首次出现在市场上所必须的进度安排等等）。成功代价法估计结果经常能帮助取得契约合同，但常常会导致实际结果大大超出限度。

1.3 风险管理过程框架

本文提出的基于风险因子分析的软件项目管理模型中关于风险管理相关活动符合业界风险管理过程框架定义。Charette（1989）[22]、Boehm（1991）[30]、Higuera and Haimes（1996）[31]提出的风险管理框架如表1-1所示。

表1-1 典型的风险管理框架

Charette 风险分析与管理 风险分析 风险标识 风险估计 风险评估 风险管理 风险计划 风险控制 风险监控 Boehm 风险管理 风险评估 风险标识 风险分析 风险优先级分配 风险控制 风险管理计划 风险解决 风险监控 Higuera and Haimes SEI风险管理 风险标识 风险分析 风险计划 风险跟踪 风险控制 风险沟通 1.3.1 Charette风险管理框架

在Charette风险管理框架中，风险分析和风险管理各由三个可以重叠的过程组成。风险

5

南京大学硕士论文

分析包括风险标识、风险估计和风险评估三个过程：

风险标识是试图系统化地确定对项目计划的威胁，并将识别的风险分类。

风险估计从两个方面评价每一条已识别的风险——风险发生的可能性以及风险发生后所产生的后果。

风险评估就是进一步审查在风险估计阶段所做的估计的精确度，试图为所发现的风险排出优先次序，并开始考虑如何控制和/或避免可能发生的风险。

风险管理包括风险计划、风险控制和风险监控：

风险计划就是确定对项目中可能遇到风险的措施，并形成明确的计划。 风险控制就是根据既定的风险计划实施具体的活动。

风险监控就是在针对风险的措施落实后，观察其效果是否与计划的一致，这常常通过监控某些指标来实现，这些指标可以提供风险是否正在变高或变低的指示。风险监控提供了风险计划改进的机会。

1.3.2 Boehm风险管理框架

Boehm的风险管理方法包括两个主要步骤，每一步又各自包含三个小步骤。第一个主要步骤，即风险评估，包括风险识别、风险分析和风险优先级分配：

风险识别产生特定项目详细风险的列表，这些风险可能对一个项目的成功起阻碍作用。 风险分析评估每一条已识别风险的损失的概率和损失的大小，并评估风险互相作用时产生的综合风险。

风险优先级分配对已识别和分析过的风险进行排序。

第二个主要步骤是风险控制，包括风险管理计划、风险解决和风险监控。

风险管理计划有助于准备确定各种风险应对方式（如风险转移、风险规避、风险降低等），包括单个风险项计划之间的协调和与总体项目计划之间的协调。

风险解决，就是采用某种措施，使风险项得到消除或者由此得到了解决（比如通过降低要求来规避风险）。

风险监控，跟踪项目风险的状态，并在适当的时候采取纠正措施。

1.3.3 SEI1的风险管理框架

SEI的Higuera与Haimes提出的持续风险管理框架（CRM）包括风险识别，风险分析、风险计划、风险跟踪、风险控制和风险沟通。其中风险识别、分析、计划、跟踪、控制等活动以环型的方式组织，表明其持续的特征。另外，SEI将风险沟通置于模型的中心位置。这 1 SEI：Software Engineering Institute，美国Carnegie Mellon大学的软件工程研究所，发布过系列能力成熟度模型SW-CMM，SE-CMM，P-CMM，CMMI等。

6

南京大学硕士论文

是因为，如何没有有效的风险沟通，任何一种风险管理方法都是不可行的。除了该模型中标识出的几大风险活动之间需要互相沟通，还有其他层次的风险沟通需要考虑，如项目与组织之间，开发人员与客户或最终用户之间。正是由于风险沟通的普遍性，SEI将风险沟通置于模型的中心位置，而不是之外，或仅仅是其他风险活动的一种补充。

图1-1 SEI的持续风险管理模型图示

1.4 常用的风险识别和风险评估方法

1.4.1 风险识别方法

头脑风暴法

头脑风暴法是团队通过本能地、不加判断地汇集一些想法，产生新的主意，从而找出解决某一特定问题的方案。建立一份综合风险清单的时候可能用到这一方法。

Delphi方法

Delphi方法是从一组专家中得到一致的意见，来预测未来的发展。它是一种以互相独立的输入为基础，对未来事件进行预测的系统化、交互式程序。Delphi方法重复使用几个回合的提问，包括来自前几轮的反馈，从而发挥团组输入的优点，同时又可以避免面对面商议中可能出现的偏见效应。如果达不成一致的意见，组织者需要确定是否过程有问题。

访谈

访谈是通过面对面或电话讨论的方式，收集信息、寻求事实的一种技术，访谈也可以通过电子邮件和即时信息进行。与那些具有类似项目经历的人们进行面谈，是识别可能风险的重要工具。例如，如果一个新项目用到一种特殊类型的硬件和软件，那么近来使用过这种硬件或软件经验的人，可能会描述出他们在先前项目中所遇到的问题。

检查表

7

南京大学硕士论文

当检查表用来进行风险识别时，将项目可能发生的许多潜在风险列于一个表上，供识别人员进行检查核对，用来判别某项目是否存在表中所列或类似的风险。检查表中所列的内容都是历史上类似项目曾发生过的风险，是项目风险管理的结晶，对软件项目有开阔思路、启发联想、抛砖引玉的作用。此外，也可以通过使用Standish Group，SEI或其他组织开发的检查表，来帮助识别项目的风险。

流程图

流程图是一种风险识别的常用工具。借助于流程图可以帮助项目风险识别人员去分析和了解项目风险所处的具体项目环节、项目各个环节之间存在的风险以及项目风险的起因和影响。

1.4.2 风险评估方法

概率/影响图

概率/影响图是风险定性分析的方法。概率表示风险发生的可能性大小，而结果表示风险发生后所带来影响的程度。使用风险暴露值=发生概率*结果影响来评价风险。

10.7高风险风险概率中风险0.3低风险00.3影响严重程度0.71

图1-2 风险概率/影响示意图

专家判断法

专家判断法是依赖专家们的直觉和以往的经验来代替或补充数学分析技术，专家可以使用或不使用较为复杂的技术，例如，无须计算风险暴露值，直接把风险定为高、中和低三种。

决策树

决策树是一种图形化的风险量化分析方法，可以帮助在未来结果不确定的情况下，选择最好的行动路径。

模拟

8

南京大学硕士论文

模拟是指用系统的模型或表示法来分析系统的预期行为或绩效，也是一种量化分析方法。大多数模拟都以某种形式的蒙特卡罗（Monte Carlo）分析为基础。蒙特卡罗分析通过多次模拟一个模型的结果，从而提供计算结果的统计分布。

风险暴露P=0.36L=50万发现CEP=0.04L=2050万未发现CEP=0.6L=50万没有CEP=0.3L=0发现CEP=0.1L=2000万未发现CEP=0.6L=0没有CE18万82万30万总暴露按IV&V方案不按IV&V方案130万0200万0200万

图1-3 决策树风险分析方法示意图

蒙特卡罗法的基本原理

假定函数Y=f（X1，X2，… , Xn）,其中变量X1，X2，… , Xn概率分布为已知。但在实际问题中，f（X1，X2，… , Xn）往往是未知的，或者是一个非常复杂的函数方程式，一般难以用解析法求解有关Y的概率分布及其数字特征。蒙特卡罗法利用一个随机数发生器，通过直接或间接的方式抽样取出每一组随机变量（X1，X2，… , Xn）的值（X1t，X2t，… , Xnt），然后按Y对于（X1，X2，… , Xn）的关系式确定函数Y的值Yt,

Yt,=f（X1t，X2t，… , Xnt ）

反复独立抽样（模拟）多次，便可以得到函数Y的一批抽样数据Y1, Y2, … , Yn，当模拟次数足够多时，便可以给出与实际情况相近的函数Y的概率分布及其数字特征。

1.5 本文的工作

本文通过对文献著作的研究和某通讯公司软件项目的实际分析，标识出影响软件项目正常运作的20个风险因子，并根据其出现的比例，选择6个风险因子进行进一步的量化分析，分析风险因子对项目进度的影响程度，并使用Monte-Carlo方法，建立项目进度计划模型。该模型的主要功能有：

1、帮助软件项目标识项目风险 2、制定风险管理计划 3、制定项目进度计划

9

南京大学硕士论文

本文关注于软件企业软件开发项目的风险管理和项目进度计划制定，对于个人软件开发、维护项目等不涉及，软件项目风险对产品质量的影响也不涉及。

10

南京大学硕士论文

第二章 软件项目的风险因子

2.1 风险的定义

虽然对于软件风险的严格定义还存在很多争议，但在风险包含了如下两个特性这一点上已经达成共识：

不确定性——风险可能发生，也可能不发生；也就是说，没有100%发生的风险。 损失——如果风险变成了事实，就会产生恶性后果或损失。

Webster字典（1981）将“风险”定义为“可能的损失、损伤、缺点、破坏”。SEI接受了这个说法，并将风险定义为“可能的损失”。为了使风险的描述能够被理解，SEI规定风险的描述必须包括两个部分：1）可能导致损失的当前状况描述；2）损失的描述。一个符合要求的风险例子是：项目组成员缺乏面向对象技术的经验和培训，可能导致无法在规定的时间范围内推出满足客户性能需求或功能需求的产品。

Charette（1989）在他的《软件风险分析与管理》[22]一书中将隶属于某一活动、事件或事物的风险进一步定义为如下三个部分：

1）活动、事件或事物附带的损失。 2）损失在现有条件下发生的不确定性。

3）将影响到产出（如损失程度等）的一些行为选择。

Charette风险定义与其他定义的不同点主要在于第3）部分。行为选择给后续的风险管理活动提供了依据。项目组在风险被标识后，将根据这些选择做进一步的分析和决策，选择合理的措施，使得风险带来的损失最小，而该活动、事件或事物本身的效益则最大化。

2.2 风险的影响纬度

对一个软件项目实际状态的测量主要包括四个纬度：功能、质量、进度和成本，这与软件项目的目标是一致的，即在规定的时间和成本范围内，提供高质量的符合客户需要的产品。

功能（F）可以使用一组产品特性（pf）及其重要程度（fw）来定义，如下：

F≡{（pfi，fwi）| i=1，n}

质量的一种简单化表示是由软件项目所包含的缺陷来定义的。因此，质量（Q）可以使用一组缺陷（pd）及其严重程度（dw）来定义，如下：

Q≡{（pdi，dwi）| i=1，n}

对于进度，一般使用期望完成的日期来表示，如“2005-06-30”；对于成本，通常使用人力成本或开发工时来表示。如“￥50000”、“3000人时”。

11

南京大学硕士论文

根据风险的定义，风险是指“可能的损失”，因此，风险对软件项目的影响也主要体现在这四个纬度上，这四个纬度上的任何偏差或不确定性都是软件项目组要关心和控制的。特别地，进度纬度上的偏差和不确定性是所有四个纬度中最需要重点关注的。

2.3 风险的量化定义

通常“风险”被量化地定义为发生潜在损失的可能性与潜在损失两者的乘积。Boehm将之称为“风险暴露”（Risk Exposure）。风险暴露可以通过下面的关系式表现出来：

RE=P（UO）*L（UO）

其中RE是风险暴露，P（UO）代表结果不令人满意的概率，L（UO）表示由于结果不令人满意而给被影响者造成的损失。

基于以上的基本定义，一种常见的风险量化定义为：

Risk≡{（Pi，Li）| i=1，n}

式中，Pi表示某种损失出现的可能性，Li表示损失的大小

Charette（1989）[22]认为对于每一个潜在的损失，必须相应地定义一个场景，该场景描述了风险的原因或者触发因素。他给风险定义了一个三元组：在什么场景下将会出现损失（Si），出现这种损失的可能性（Li），这种损失的大小（Xi），具体表示如下：

Risk≡{（Si，Li，Xi）| i=1…n}

Charette的定义还存在一个问题，即“低可能性，高损失”的风险与“高可能性，低损失”的风险在数值上的表现是一样的。很明显，对于能带来10万元收益而潜在损失为200元的风险与能带来1000元收益而潜在损失为200元的风险是不一样的。为了克服以上不足，Henley和Kumamoto（1996）加入了效益或产出（Oi）指标。这种风险定义的具体表示如下：

Risk≡{（Si，Oi，Li，Xi）| i=1…n}

上述几种风险的量化定义方式均是“以数字的形式考虑风险”。Demarco与Lister（2004）在他们的《与熊共舞：软件项目风险管理》[3]一书中提出了“用图形的方式考虑风险”——风险图的概念。

设想你是一个软件项目经理，你的项目计划在10月30日之前完工。你清楚地感觉到不可能在10月30日之前完成任务；但除此以外，你一无所知。你对项目的进度毫无把握，手下的员工也一样。于是，仲夏时节，离最后期限还剩4个月的时候，你找来了一名顾问——圈子里最好的顾问，就算他睡着了也能判断出项目的处境。经过几天的工作——阅读规格书、检查阶段性成果、会见团队成员和客户代表。之后，他告诉了你真相：

“听着，这个项目根本没有可能在明年1月之前完成。最有可能交付一个象样产品的时间是明年4月初，而且这个日期也不能打包票。你最好不要承诺在5月1日前的任何时间交付，至少应该承诺在5月以后，这样你成功的机会大概有一半。如果你想一个几乎不可能失败的日期，那大概会是明年的12月。”

12

南京大学硕士论文

之所以找来一名顾问，正是因为你不敢肯定项目什么时候能完成。但看起来这位顾问先生自己也多少有些不确定。你的不确定（完全盲目）与他的不确定之间的区别在于：他给不确定性画定了明确的界限。

可以用一幅图来表示这位顾问的估计。既然他谈到的都是可能性的问题，这幅图也就借助“某一日期交付的概率”来展现不确定性。用纵轴表示可能性，横轴表示时间，如图2-1所示：

4Ñ¿1ÅÒÔÜÐÉÄ¿1Ñ¿1ÅÒ5Ñ¿1ÅÒª¹Çä12Ñ¿31ÅÒ

图2-1 项目交付日期不确定性图

这幅描述不确定性的图形，就叫不确定性图。当不确定的东西与项目的成败休戚相关时，描述它的不确定性图就被称为风险图。

风险图最重要的特征有：

曲线下方的区域表示“在某一特定日期之前完工的”总的可能性。也就是说，如果有1/3的区域位于4月1日的左侧，就表示在4月1日当天或之前完成项目的可能性为33%。

整条曲线下方区域的面积为1.0，这就是顾问对项目的整体评估：项目一定会在明年1月1日至12月31日之间的某个时间完成。

上述风险图还可以等价地表示为另一种形式——累积风险图，如图2-2所示。累积风险图表示了在某一日期或之前完成项目的累积可能性，相应地，表示某一日期完成相对可能性的风险图则称为增量风险图。

基于风险图的观点，Demarco与Lister将风险量化地定义为：

风险是描绘所有可能结果及由其引发的相关后果的加权图。

13

南京大学硕士论文

100%ÔÜÐÉÄ¿50%1Ñ¿1ÅÒª¹Çä5Ñ¿1ÅÒ12Ñ¿31ÅÒ

图2-2 累积风险图示意图

Demarco与Lister给出了风险图和风险的定义，也指出了风险图必须基于历史项目数据得到。但对于如何有效得到这些风险图，并没有给出方法上的指导。本文试图从影响项目的关键风险因子研究出发，借助风险图的方法，量化地研究风险因子对项目进度的影响。

2.4 风险因子的定义

何文炯（1999）在他的《风险管理》[17]一书中对风险因子作了比较完整的定义。他认为风险因子是促使或引起风险事件发生的条件，以及风险事件发生时，致使损失增加、扩大的条件。风险因子是风险事件发生的潜在因素，是造成损失的间接的和内在的原因。关于风险因子的称呼有多种，有叫“风险因素”，有叫“风险源”的，英文叫“Hazard”。本文统一称为“风险因子”。软件项目开发过程中的需求膨胀，对项目进度延迟而言，就是风险因子。

根据其性质，通常把风险因子分成实质风险因子（Physical Hazard）、道德风险因子（Moral Hazard）和心理风险因子（Morale Hazard）三种。

实质风险因子是指增加风险事件发生机会或扩大损失严重程度的物质条件，它是一种有形的风险因子。例如，缺乏合适的开发、测试环境对于项目进度的危害，关键技术不熟悉对于生产率降低等，都是实质性风险因子。

道德风险因子是指与人的不正当社会行为相联系的一种无形的风险因子。常常表现为由于恶意行为或不良企图，故意促使风险事件发生或损失扩大，例如偷工减料引起质量事故就属于道德风险因子。

心理风险因子也是一种无形的风险因子，但与道德风险因子不同。它是指由于人的主观

14

南京大学硕士论文

上疏忽或过失，导致增加风险事件发生机会或扩大损失程度。例如，由于设计方案的错误选择导致软件项目失败，项目组成员的非正常退出而没有进行必要的分析和采取适当的措施等等，都属于心理风险因子。

风险因子、风险事件以及危害之间的关系可以通过图2-3来表示：

þʼÕ·ÏçÓÒ×Õò·Ï禣ºÎÏ«ù¢¸´ö¹Ñиư¸

图2-3 风险因子、风险事件、危害关系图

前面提到的Charette风险三元组（Si，Li，Xi）中，根据项目场景Si的定义，Si可以表示为一系列风险因子（记为rf）和时间（记为t）的函数，如下：

Si={（rfi1，rfi2，… rfin，ti）| i=1..n}

一个将导致项目进度延期风险事件的Si例子描述如下： {30%需求变更，没有变更控制，进度没有缓冲，编码阶段}

对于一个软件项目而言，存在着许多场景，其中某几个场景决定了项目的成败。标识对项目起关键作用场景所包含的风险因子是一项有意义的工作，文献资料中已经有一些这方面的研究，将在后面叙述。

2.5 软件项目风险因子标识方法

本节简单介绍标识软件项目风险因子的两种方法。

基于项目成本驱动因子

典型的例子是Madachy（1997）[27]使用COCOMO模型中的成本驱动因子，开发了一套专家系统，用来识别软件项目风险。Madachy将成本驱动因子看作是软件项目的风险因子，并评估它们的影响。Madachy在他的系统中使用的COCOMO模型中的成本驱动因子如表2-1所示。

文献资料整理或问卷调查

Boehm（1991）[30]调查了一些有经验的项目经理，整理出了软件项目的10个主要风险因子，如表2-2所示。

Jones（1994）[23]以医学手册的方式对一些软件公司项目进行诊断，总结出大约60种风险因子，并标识出了10种最严重的风险因子，如表2-3所示。

15

南京大学硕士论文

表2-1 COCOMO模型成本驱动因子

产品属性 人员属性 要求的可靠性 分析人员能力 数据库规模 程序员能力 产品复杂程度 人员持续性 要求的重用 应用领域经验 文档化 平台经验 程序语言及工具经验 平台属性 项目属性 执行时间约束 软件工具的使用 主要存储约束 异地开发 平台易变性 要求的开发进度 表2-2 TOP 10风险因子表

1 人员不足 2 不现实的进度计划和预算 3 开发错误的功能 4 开发错误的用户界面 5 夸大软件的功效 6 持续不断的需求变化 7 外部购买组件的不足 8 外包开发的不足 9 实时性能的不足 10 计算机资源能力的限制 表2-3 Jones的10大风险因子

1 不精确的度量 2 度量不足 3 过多的进度压力 4 管理部门玩忽职守 5 不精确的成本评估 6 银弹综合症 7 迟缓的用户需求 8 质量低 9 生产率低 10 取消项目

16

南京大学硕士论文

第三章 主要风险因子的潜在影响分析

3.1 实际软件项目的风险因子标识

本文所研究的项目来自国内一家著名通讯软件公司，该公司的业务主要聚焦于数据通讯产品、业务与软件产品、网管软件产品等领域，目前有软件开发人员600名左右。本文选择分析的软件项目共有207个，包括了该公司近3年来的所有软件项目。

所选择的软件项目大多数使用了V模型的软件开发过程，其他的如增量开发过程、原型演进开发过程等也有应用，对规模很小的项目则大多数使用了编码-测试的简化过程。

­¿ªë-°âÇÑ11%­ÍÑÊÙκ÷Á£ÍÊ18%ö¼Ñ¾Á£ÍÊ8%VÁ£ÍÊ63%图3-1 软件开发过程种类分布图

软件项目的开发周期长度大多集中在4~12个月，最长的为16个月，最短的为1个月。

图3-2 软件项目开发周期长度分布图 8-12Ñ¿16%12-18Ñ¿3%<2Ñ¿8%2-4Ñ¿12%4-6Ñ¿19%6-8Ñ¿42%

软件项目运作过程中的峰值人力投入根据项目的不同而有变化，最少投入在2个人，最多投入在48个人。 15~2015%20~503%¡5²13%

10~1525%5~1044%17

南京大学硕士论文

图3-3 软件项目人力投入分布图

根据业务领域的不同，各软件项目组在设计实现时，使用了不同的编程语言。

SCE14%Delphi7%PB20%SQL7%C17%ASM6%C++29%图3-4 软件项目使用开发语言分布图

1

在这207个软件项目中，产品规模（以开发工作量人月计算）也分布广泛。

150ÏÑÆÌ1%80-15011%40~8039%1~43%4~1215%12~4031%图3-5 软件项目产品规模分布图

项目经理们的项目管理经验也各不相同，有的仅有1年管理经验，而有的管理经验则在10年以上。

1

SCE：Service Construct Environment 业务生成环境，是基于特定平台的一种业务生成语言。

18

南京大学硕士论文

6~88~10>102%8%5%4~614%1~215%2~456%图3-6 项目经理管理年限分布图

3.1.1实际软件项目风险因子标识方法

1、如果所选软件项目存在风险管理计划，则提取出风险管理计划中标识的所有风险； 2、对提取出的风险，针对其风险描述进行分析，并归纳出相应的风险因子； 3、如果所选软件项目存在项目结束总结报告，则提取出总结报告中所反映的影响项目质量、进度、工作量的所有项目问题；如果某问题已经在该项目的风险管理计划中提及，则去除该问题，以避免重复统计；

4、对所提取出的项目问题，针对问题描述进行分析，并归纳出相应的风险因子（“今天的问题就是明天的风险”）；

5、综合风险管理计划和项目结束总结报告中出现的风险因子，并统计这些风险因子出现的数目。

在所选择的207个软件项目中，有192份风险管理计划。该公司允许时间跨度在2个月以内的小型软件项目可以不做单独的风险管理计划，但有些小型项目做了单独的风险管理计划。所选择的每一个软件项目都有项目结束总结报告。

从风险管理计划和项目结束总结报告中提取出的风险因子及其数目如图3-7所示，从中

450400350300250200150100500标识出的20种软件项目风险因子如表3-1所示。 3.2 主要风险因子原因结果图 为了进一步研究这些风险因子对项目进度的影响，又从中选择了6个风险因子，通过问卷调查的方式，量化分析它们对项目进度的潜在影响。之所以选择这6个风险因子，主要是因为它们在项目风险因子标识过程中出现的比例较高，以及它们对项目进度的影响较大。这6个风险因子如表3-2所示。 ¯ÍµÄªÅ´Â¥«ÊÒ½ÏÔ¶³½¹µ¹ÈÅöµªÑîÌîÌÔ¶¼Á¼Á¹Æ±­»ÈŪѳ½ªÑ¶¾­»§Ç°Î´¸¸°´Êã¬ÌîëżÁ¸°Æ±ÅËù¶ªÑ¨´­´¼ÇÁ³÷ÃÁËʳ³¿ÌǬ̾î̤¶¼Á¶¬µ²¿Í¢¡¸°²«µÃÐÑ­½Ê͸°ª¼ªÅùÒ«¢¥««ÅßµÁ³ã°Å´Ø¶¼¾³½Ñ´Á³î̪Åͱ¼ÁªÅ¥«³ÂºÃ¥«Ê¼¨É¼¾§¸/¶¯¸¤§ÓÁ³¶¬Ó±¸½«¸«Ç±»ùÇ/«ºÙ»¤¶¨«¶¬¸°¼¾²Ç½¶¤Ìùù¶¸°Å´¹¬Á³«Å¸°÷º¯ÍÅ´¸°ªÏ¶Î²ÇÁ³¥¾¤Ì¥¶ä¸°ØÁÀӫê¼Ø¶¶Ç¢«³½ÀÐù¶¸°«¸Å´ä±±»½ÏÓ«/°³½Õ¤³¶¬öµº«ù¶Á³¨«­´ª¼Á³¢«²µÁµÐÑ÷ºâʼ°¸°ÐºÆ±Ö¼²ÇÁ³¹õÇʳ¸ÆÔ¶¸°¹Ç¿Ç¬²Ñ¸°ã¬ 19 äÃøÈ南京大学硕士论文

图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种主要风险因子及其说明

序号 风险因子 1 需求膨胀 2 3 4 5 6 工作量估计不准确 项目组成员流失 对项目平台/环境/方法不熟悉 缺乏关键人员 缺乏高层管理的支持和承诺 说明 在已经确认的需求基线基础上，增加了新的需求，或者删除了已有的需求，或者是原有需求发生了变更 由于缺乏历史数据，或者是没有使用有效的估计方法，导致工作量估计值与实际值不一致 项目组成员在其承诺的任务完成之前离开项目组，或者是其实际投入不能满足承诺的目标 对项目开发所依赖的平台/环境或者所使用的开发方法不熟悉 项目组缺少满足其特定要求的人员，如缺乏有经验的需求分析人员、测试人员等 高级管理者对项目不支持或保持中立状态，表现为不能给项目足够的资源，在项目出现困难时，不能帮助项目度过难关 在实施问卷调查之前，为了帮助项目经理理解风险因子及其潜在的影响，特别准备了这些风险因子的原因——结果图形。原因——结果图形是Eden和Ackerman 在1992年提出的一种图形化描述系统原因与结果关系的建模方法，使用原因——结果图形可以清楚地表示风险因子的潜在影响。

20

南京大学硕士论文

原因——结果图形由标签、标签之间的连结线段组成，这些线段带有箭头用以表示方向，在箭头的旁边还带有正（+）、负（-）号。每一个标签表示一个原因或者一个结果，当箭头指向某个标签时，则该标签表示一个结果，连接线段的另一端标签则表示一个原因，因此，原因——结果图形中的一个标签既可能是一个结果，同时又可能是另一个结果的原因。箭头旁边的符号则表示结果变化的方向与原因的变化方向是否一致，当符号为正号时，则表示随着原因增长时，结果也相应地增长；当符号为负号时，则表示当原因增长时，结果却相应地减少。图3-8是原因——结果图形的一个简单例子，当项目开发过程中需求持续膨胀时，设计返工的工作量随之增加。

图3-9则表示了原因——结果图形的另外两种特征，符号为负号的路径以及增强正反馈路径。过度的进度压力在短期内可以提高生产率，但同时也增加了员工的疲惫程度；疲惫程度加大后，导致生产率下降。正反馈路径出现在：由于疲惫程度加大，引发更多的缺陷，造成更多的返工，进而使得进度压力更大。

¯Ä͵´ÒÊ+¯¹Æ볶¤图3-8 需求膨胀导致设计返工原因——结果示意图

³¶«¤¶´ùųÁº÷´Å¶¾Î¥++¸°Æ¸¿Ç-+£ªÃ¶+ªÙÅÌÏùÅë+图3-9 过度的进度压力原因——结果示意图

6种主要风险因子的原因——结果图形分别如下：

需求膨胀风险因子

21

南京大学硕士论文

¯Ä͵´ÒÊ +¸Ã°«¶æÁ£+—÷´ºÅÎбÕ+¯¹Æ볶¤—¸°Æ¸¿Ç图3-10 需求膨胀风险因子原因——结果图

当需求新增或者需求发生变更时，很可能带来新的工作任务和活动，工作产品规模随之变大；同样地，需求膨胀也会导致对原有需求的设计返工。无论是产品规模变大，还是设计返工增加，都将对项目的进度造成影响。

工作量估计不准确风险因子

工作量估计不准确，往往是指工作量估计偏少，这是由于人们在进行软件项目估计时，倾向于忽视某些“可能需要做”的工作，而不是把“可能不需要做”的工作也计算在内。当然也有项目组工作量估计偏多，偏多的结果之一就是项目组人力资源得不到充分发挥。当工作量估计偏少时，项目人力资源投入可能不足，或者项目计划完成时间点提前，这两点最终会导致项目组成员感受到过度的进度压力，从而导致项目延迟更多。

项目组成员流失风险因子

项目组成员流失或者投入不稳定，使得项目组缺乏有经验的人员，并在可能的情况下增加新人到项目组。由于缺乏有经验的人，将导致缺陷引入增加，缺陷也不能尽早发现，项目组的士气也有一定程度的下降，所有这些将会导致生产率的下降，最终引发进度延迟问题。增加新人到项目组，由于存在接手时间，并增加了项目组沟通的工作量，进度也会有延迟。

¤¶¶¬¾¼¶½¹Ã°¸¬¹Å« +Ⱦť¬ÇѲѤÈã°¸¬ã+îÁ̼º÷´Å¶½¹Ã°¸¬¹Å«++ù´¶Å³Áº÷´Åζ¾¥+—+ªÙÅÌÏùÅë—¸°Æ¸¿Ç÷ź´Îб՗£½ÃÊ图3-11 工作量估计不准确风险因子原因——结果图

22

南京大学硕士论文

îÁ̼¬°±ÆѪ¾¶Ç§¸´ÒßÊ´Åë°¸ËÅ´¨ +îÁ̼Ū«¥ÐÍ»­Î°³ÁÅÈѪ+¼ÃÇ÷º³³Ê—ªÌÅÙ¹²°â+——¸°Æ¸¿Ç+ªÌÅÙÏùÅë++ö¹ÑÐÍ¿ÅÈ+¿ÅÍȺÐÇÓ³¹Ó¿º÷´ÅÎбÕîÁ̼¶³Ê¨¶¤¬¶¾¼——÷´ºÅÎбÕ图3-12 项目组成员流失风险因子原因——结果图

对项目平台/环境/方法不熟悉风险因子

ÑÌ´îÁ¼ÃºÉ¨/¸«»±/«º«¨°¸Ç²Ì¤+­Î³——¸°Æ¸¿Ç+³Ê¶¨——÷´ºÅÎбÕ+³Ë²µÏùÅë

图3-13 对项目平台/环境/方法不熟悉风险因子原因——结果图

对项目平台/环境/方法不熟悉，将导致更多的正式培训或者边干边自学，也会导致更多的项目沟通时间，错误引入也会因为对平台/环境/方法的不熟悉而增加，所有这些将会降低项目组的生产率，从而使得进度延迟。

缺乏关键人员风险因子

23

南京大学硕士论文

îÁ̼¬°Åª«¥¶Ô¹ÅÈѪ+¶ÐÇÀ°¸»ßªµÌ­¶Ô¹ÁØÅȪÑ++Å̪ÙÏùÅë—¸°Æ¸¿Ç+—÷´ºÅÎб՗ªÌÅÙ¹²°â­Î³—图3-14 缺乏关键人员原因——结果图

项目组缺乏关键人员，将导致不具备相关技能的人员上岗。由于不具备技能，培训工作量上升，缺陷引入上升，而缺陷检测水平下降，所有这些，将导致生产率下降，从而使得进度延迟。

缺乏高层管理者的承诺和支持风险因子

ª«Å¥µß¹´¶Ø½³Òß³Á±Í³·ÊÓ§±Ó+¼ÃÇ÷³ÊÌ¿÷´ºÅζÈõ++ȾťʴÅë°¸¬ã+ÑÐö¹Í¿ËÅËñ¸´ÔÓ¶½Ã·¹µ¸°Áض³Òøº÷Å´+++ù´¶Å³Áº÷´Åζ¾¥+——£½ÃÊ—+ªÌÅÙÏùÅë÷ź´Îб՗¸°Æ¸¿Ç图3-15 缺乏高级管理者支持的风险因子原因——结果图

项目组缺乏高级管理者的支持和承诺，一般存在人为压缩进度、人力资源投入不足、或者在增加新任务的情况下不能调整进度的现象，这些将使得项目组成员在过度的进度压力环境下工作，最终导致项目进度的延迟。而且，如果项目组缺乏高层管理者的支持和承诺，项目组的士气则大为降低，影响了项目组成员能力的发挥，也降低了生产率。

24

南京大学硕士论文

3.3 风险因子影响调查

针对6个风险因子的问卷调查主要是用来测量风险因子对项目进度的潜在影响情况，参与调查的项目经理被请求按照其最近两三年间所完成的软件项目实际情况进行回答。调查问卷总共包括了17个问题。参与本次调查的项目经理共有83位，发放问卷83份，收回83份，且全部有效。项目经理的组成情况与图3-6完全一致。

针对软件项目“需求膨胀”风险因子，设计了如下问题： 1、需求新增或需求变更后，相应的软件规模变化有多大？

2、需求新增或需求变更后，造成的返工比例（规模或工作量）有多大？

3、对于需求新增或需求变更造成的返工，返工生产率与开发新产品的生产率是否大小一致？如否，返工生产率是新产品开发生产率的多少倍？

针对软件项目“工作量估计不准确”风险因子，设计了如下问题： 1、软件项目所估计的软件项目工作量是多少？ 2、项目结束后，实际投入的软件项目工作量是多少？ 3、项目实际投入与估计的偏差是多少？

针对软件项目“项目组成员流失”风险因子，设计了如下问题：

1、项目组共有多少名成员？有多少员工在没有完成分配的任务或者在既定的释放日期前就离开了项目组？

2、对于人员离开项目组的工作交接，平均多长时间接手员工就可以独立承当起该任务？ 3、综合考虑上述两点，项目组成员流失对项目进度的影响有多大？

针对软件项目“对项目平台/环境/方法不熟悉”风险因子，设计了如下问题： 1、对项目平台/环境/方法不熟悉，不熟悉的程度是“严重”、“一般”、或者是“轻微”？ 2、项目组是否针对平台/环境/方法不熟悉进行了正式的培训？人均培训工作量有多少？ 3、由于对项目平台/环境/方法不熟悉而导致的项目进度影响有多大？ 针对软件项目“缺乏关键人员”风险因子，设计了如下问题：

1、项目组是否“缺乏关键人员”？缺乏的程度是“严重”、“一般”、或者是“轻微”？ 2、缺乏关键人员对项目进度影响有多大？

针对软件项目“缺乏高层管理的支持和承诺”风险因子，设计了如下问题：

1、高级管理者对项目的成功作出承诺，并给项目组提供足够的资源（人力、工具、时间等等）和关心的程度是“非常不支持”、“不支持”、“中立状态”、“支持”还是“非常支持”？

2、在项目运作过程中，高级管理者能够容忍的项目进度扩展比例是多少？ 3、“缺乏高层管理的支持和承诺”对项目进度的影响有多大？

25

南京大学硕士论文

3.4 风险因子影响图曲线

3.4.1 工作量估计不准确风险因子影响图曲线

软件项目工作量估计不准确是一个非常普遍的问题。在去除掉需求膨胀对工作量的影响后，29%的项目经理汇报说他们项目的实际工作量超过了计划工作量的20%，工作量偏差的平均值是10.5%，有18%的软件项目其工作量偏差接近于0。工作量偏差的定义如下：

（实际工作量－估计工作量）/估计工作量

所有被调查项目的工作量偏差柱状图如图3-16所示。

181614121086420项目个数0%%%%%%%%800%0%0%0%10203040506070-4-3-2-1工作量偏差百分比图3-16 工作量偏差柱状图

从图3-16可以看出，工作量偏差分布基本上符合正态分布。使用非线性回归统计工具NLREG进行工作量数据拟合，得到工作量偏差分布符合正态分布N（10.8%，26.3%）。也就是说，大约有68%的软件项目，其工作量变化范围在(-15.8%，46.1%)之间。

软件项目工作量估计不准确的影响是明显的，当估计的工作量小于实际需要时，项目的人力投入会减少，或者进度时间点会提前，这两种情况都将会使项目的实际成本更高，项目组成员的士气降低。当估计的工作量大于实际需要时，项目的人力投入会增加，或者进度时间点会推迟；这将使项目组成员得不到充分的使用。

在人力资源投入情况确定后，“工作量估计不准确”风险因子对项目进度的潜在影响可以等同于工作量偏差分布。从而构造“工作量估计不准确“风险因子的风险图如下，图3-17为相对风险图，图3-18为增量风险图。

90%26

南京大学硕士论文

0.160.140.12ÑØÍÆÁѼ­´Ì0.10.080.060.040.02050%60%70%80%90%100%110%120%130%140%150%160%170%180%190%³¹ÇÇǪä¹Ðë¹Ã¸®Çªä¹Ó®ªÅ图3-17 工作量估计不准确之相对风险图

1ÑØÍÆÁù¼×¸½0.80.60.40.20%%%0%0%0%0%50709011131517190%³¹ÇǺ÷´ÅÐë¹Ã¸®º÷´ÅÓ®ªÅ图3-18 工作量估计不准确之累积风险图

从图3-18可以看出，即使对以前的项目或者企业的历史数据一无所知，最初的工作量估计，不管是出自计算还是一个强制的命令推算而来，会导致项目延期至少10%以上。这是因为，累积可能性为0.5的水平线与曲线相交的一点，它的实际进度与计划之比大概为110%或者更多一些，也就是说，项目实际进度时间是计划时间110%的可能性至少有一半。

3.4.2 需求膨胀风险因子影响图曲线

对需求膨胀的调查问题主要集中在它的两个影响：（1）新增需求或者需求变更，将导致新的开发任务，并进而增加工作产品的规模；（2）新增需求或者需求变更，将导致针对原有需求的返工任务。

由于需求变更而导致新的开发任务

200%27

南京大学硕士论文

调查者被请求估计由于新增需求或者需求变更带来的工作产品规模变化有多大，调查结果如图3-19所示。

353025ù¼ÇîÁ¥Ì­ÐÌ20151050-5%5%010%15%20%25%30%35%40%45%50%55%60%65%55%70%60%-10%¯Ä͵´Òʳ¹Ó¿³Á¶æÁ£ªä¸¯图3-19 需求膨胀导致的规模变化柱状图

尽管有7个调查者报告说需求变更使得他们项目的产品规模减少了，但是需求变更还是引入了新的工作任务。大多数调查者报告显示需求变更都使得工作产品的规模变大了。从图上可以看出，新增需求或者需求变更导致工作产品规模变化的平均值为9%，变化范围主要集中在（0%，15%）之间；新增需求或者需求变更导致工作产品规模变化最大量为72%。

由于需求膨胀导致的返工

调查者被请求估计由于新增需求或者需求变更带来的软件工作产品返工百分比。调查结果如图3-20所示。

新增需求或者需求变更带来的软件工作产品返工百分比集中在（0，5%）区间之内，返工平均值为3%。

7060ùöǼµîÁ¥Ì­ÐÌ50403020100-10%-5%5%010%15%20%25%30%35%40%45%50%65%75%70%75%¯Ä͵´Òʳ¹Ó¿³ÁƯ¹Ã«³¶¤图3-20 需求膨胀导致设计返工的柱状图

28

南京大学硕士论文

关于返工生产率

对于需求膨胀而导致的新开发任务，可以认定其生产率与需求膨胀前项目的平均生产率一致。对于需求膨胀而导致的工作产品返工，其生产率与开发新产品的生产率则可能不同。问卷调查中设计了“返工生产率与开发新产品的生产率是否大小一致？如否，返工生产率是新产品开发生产率的多少倍？”这个问题，75%的项目经理报告说这两者的生产率一致，所有调查者的结果分布如图3-21所示。

7060ùöǼµîÁ¥Ì­ÐÌ504030201001/41/31/22/313/2234³¶«¤Æ¸°¸¿ÇÐëÍ¿¼ª«¢Æ¸°¸¿ÇªÅ¿Ç图3-21 返工生产率与新开发生产率比率对比图

关于需求膨胀的调查结果表明，项目由于新增需求或者需求变更导致了新开发任务或者返工，这些新开发任务或者返工给项目带来了额外的工作量，影响了项目正常开发的进度。从调查结果可以发现，新开发任务生产率与返工生产率基本一致，因此，可以通过简单的迭加方法，得到需求膨胀对项目进度的影响程度。根据图3-19和图3-20的结果，需求膨胀对项目进度影响如图3-22所示。

3530¼ùÁ¼ÇîÁ¥Ì­ÐÌ25201510500%-5%5%10%15%20%25%30%35%40%45%50%55%60%65%70%75%80%85%90%-10%95%100%¯Ä͵´Òʳ¹Ó¿³Áº÷´ÅЩ̲©Õ«ÓªÅ图3-22 需求膨胀导致的进度影响图

29

南京大学硕士论文

从图3-22可以看出，需求膨胀对项目进度的影响呈偏态分布，大量取值在左边，少量在右边，且比较分散，比较接近对数正态分布。使用非线性回归统计工具NLREG进行数据拟合，得到需求膨胀对进度影响分布符合对数正态分布LN（2.75%，1.5%）。可以简单地认为，需求膨胀对进度造成的影响符合特定的对数正态分布，从而构造“需求膨胀风险因子”的风险图如下。图3-23为相对风险图，图3-24为增量风险图。

0.30.25ÑØÍÆÁѼ­´Ì0.20.150.10.05090%100%110%120%130%140%150%160%170%180%190%190%³¹ÇǺ÷´ÅÐë¹Ã¸®º÷´ÅÓ®ªÅ图3-23 需求膨胀之相对风险图

10.90.80.70.60.50.40.30.20.10ÑØÍÆÁù¼×¸½90%100%110%120%130%140%150%160%170%180%³¹ÇÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ图3-24 需求膨胀之累积风险图

从图3-24可以看出，由于需求膨胀的原因，项目实际时间是计划时间的110%的可能性至少有一半。

3.4.3 人员流失风险因子影响图曲线

所有调查者被请求回答项目组成员流失的比例，调查结果整理如图3-25所示。 从图3-25可以看出，项目组成员流失比例呈偏态分布形状，大多集中在图形的左边，右边有一条长长的尾巴。有18%的软件项目没有发生人员流失情况，最经常出现的成员流失

200%200%30

南京大学硕士论文

比例在（5%，15%）之间，人员流失平均值为12.2%。

2520¼ùÁ¼ÇîÁ¥Ì­ÐÌ15105005%10%15%20%25%30%35%40%45%50%55%60%65%70%75%80%85%90%595%ÈÑŪ¾¶Ç§ªÅ½ù图3-25 人员流失比例柱状分布图

所有调查者被请求回答由于人员流失而导致的替换人员平均接手时间，有30%的项目经理报告显示，人员流失后没有进行相应的人员补充。对于有人员补充的项目，其交接人员平均接手时间的调查结果整理如图3-26所示。

3025¼ùÁ¼ÇîÁ¥Ì­ÐÌ20151050123ÐǺÓǪ¹ä(ÓØ)4图3-26 接手时间柱状分布图

从图3-26可以看出，接手时间分布比较集中，大多分布在3周以内。

为了了解由于人员流失而对项目进度造成的影响，在上述两个调查的基础之上，特地要求被调查人员根据人员流失比例和平均接手时间两个参数来估计人员流失对进度的影响，调查结果整理如图3-27所示。

从图3-27可以看出，人员流失对进度影响的曲线基本符合对数正态分布曲线。使用非线性回归统计工具NLREG进行数据拟合，得到人员流失影响分布符合对数正态分布LN（6.75%，2.2%）。可以简单地认为，人员流失对进度造成的影响符合特定的对数正态分布，

100%31

南京大学硕士论文

从而构造“项目组人员流失风险因子”的风险图如下。图3-28为相对风险图，图3-29为增量风险图。

2520¼ÁùÇ15¼ÁîÌ¥Ð10­Ì50%%%%%%%%%%%%%%505050505050500112233445566711111111111111÷º´ÅЩ̲©Õ«ÓªÅ图3-27 人员流失对项目进度影响柱状图

0.30.25ÑÍ0.2ØÁƼ0.15Ñ´­Ì0.10.050%%%%%%%%%%%%%%5050505050505001122334455667111111³Ç¹Ç1Ǫ¹ä1Ðë¹Ã¸®1Ǫ¹ä1ªÅ1111图3-28 人员流失之相对风险图

10.90.8ÑÍ0.7ØÁ0.6Ƽ0.5ù¸×½0.40.30.20.10%%%%%%%%%%%%%%505050505050500112233445566711111111111111³Ç¹ÇǪ¹äÐë¹Ã¸®Çª¹äªÅ图3-29 人员流失之累积风险图

32

南京大学硕士论文

从图3-29可以看出，人员流失对项目进度影响较大。由于人员流失的风险，一个项目实际时间是计划时间的125%的可能性至少有一半。

3.4.4 对项目平台/环境/方法不熟悉风险因子影响图曲线

软件项目组对项目平台/环境/方法不熟悉，将需要花费额外的工作量用于培训，或者需要花费额外的工作量用于项目组成员之间的沟通学习，这些对项目组的生产率都会有影响，进而影响项目的进度。

所有调查者被请求回答项目组是否针对项目平台/环境/方法进行了培训，培训的工作量有多少？调查结果显示，95%的项目组都进行了正式的培训，项目组人均培训学时的调查结果整理如图3-30所示。

181614ùöǼµîÁ¥Ì­ÐÌ121086420102030405060708090100Ȼŷ­γΧǪ图3-30 人均培训学时柱状分布图

从图3-30可以看出，人均培训工作量的分布基本没有什么规律。调查结果还发现，人均培训工作量与“项目组对平台/环境/方法不熟悉”的严重程度关联性较大，即不熟悉程度越严重，相应的人均培训工作量就越多。为了显示“项目组对平台/环境/方法不熟悉”严重程度与培训学时之间的关联度，将调查结果整理为如下趋势图3-31。

从图3-31可以明显看出，“项目组对平台/环境/方法不熟悉”程度为严重时，培训学时分布在（20小时，90小时）之间，最可能培训学时在60小时；当程度为一般时，培训学时分布在（0小时，50小时）之间，最可能培训学时在30小时；当程度为轻微时，培训学时分布在（0小时，20小时）之间，最可能培训学时在10小时。

为了了解由于项目平台/环境/方法不熟悉而导致的对项目进度影响有多少，特地要求被调查者根据自己项目的实际情况，来估计由于不熟悉而导致的进度影响。调查结果整理如图3-22、3-23、3-24所示，已经根据不熟悉的严重程度进行分类。

33

南京大学硕士论文

ÌÓÎÔ161412108642010203040¸©Ïã®ËÄ¢ùöǼµîÁ¥Ì­ÐÌ5060708090Ȼŷ­γΧǪ图3-31 按严重程度分之人均培训学时趋势图

876ùöǼµîÁ¥Ì­ÐÌ543210105%106%107%108%109%110%112%112%³¹ÇÇǪ¹äÐë¹Ã¸®Çª¹äªÅ图3-32 严重不熟悉之进度影响柱状图

1412ùöǼµîÁ¥Ì­ÐÌ1086420101%102%103%³¹ÇÇǪ¹äÐë¹Ã¸®Çª¹äªÅ104%105%图3-33 一般不熟悉之进度影响柱状图

从图3-32、3-33和3-34可以看出，“项目平台/环境/方法不熟悉”的程度不同，其对进度的影响程度也不相同；在同一种不熟悉程度的情况下，其对进度的影响明显呈三角形分布。

34

南京大学硕士论文

“项目平台/环境/方法不熟悉”对项目进度影响整理如表3-3所示。

1412ùÇ10öµ¼Á8îÌ6¥Ð­Ì420100%101%102%³ÇǹǪä¹Ðë¹Ã¸®ªÇ¹äŪ图3-34 轻微不熟悉之进度影响柱状图

表3-3 平台/环境/方法不熟悉对项目进度影响表 严重程度 最可能影响 最悲观影响 最乐观影响 严重 8% 12% 5% 一般 3% 5% 1% 轻微 1% 2% 0%

构造“对项目平台/环境/方法不熟悉风险因子”的累积风险图如下。

1.00.90.80.7ÑÍØÁ0.6Ƽ0.5ù¸0.4×½0.30.20.10.0104%106%108%110%112%114%³Ç¹ÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ图3-35 对平台/环境/方法不熟悉之累积风险图（严重）

35

南京大学硕士论文

1.00.90.80.70.60.50.40.30.20.10.0101%102%103%104%105%106%³¹ÇÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ图3-36对平台/环境/方法不熟悉之累积风险图（一般）

ÑØÍÆÁù¼×¸½1.00.90.80.70.60.50.40.30.20.10.0100%101%101%102%102%103%³¹ÇÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ图3-37 对平台/环境/方法不熟悉之累积风险图（轻微）

从图3-35可以看出，如果对项目平台/环境/方法不熟悉的程度为严重，项目实际时间是计划时间108%的可能性至少有一半。

3.4.5 缺乏关键人员风险因子影响图曲线

软件项目组缺乏项目所需要的“关键人员”，意味着项目组的一些工作任务缺少合适的人来完成，为此项目需要进行额外的培训，这会影响项目的进度；当培训不能满足要求时，项目会引入更多的缺陷，导致更多的返工，降低了项目的生产率。

鉴于“关键人员”对项目的重要性，调查问卷中设计了一个问题“项目组是否缺乏关键人员？缺乏的程度是“严重”、“一般”、或者是“轻微”？”，调查结果显示，82%的软件项目在运作过程中“缺乏关键人员”。缺乏关键人员程度的调查结果如图3-38所示。

从图3-38可以看出，大多数项目处于“严重”缺乏项目关键人员。

为了解关键人员对项目进度的影响，所有调查者被请求回答“缺乏关键人员对项目进度影响有多大？”问题，调查结果整理如图3-39、3-40、3-41所示，已根据严重程度分类。

ÑØÍÆÁù¼×¸½36

南京大学硕士论文

504540ùÇ35öµ30¼ÁîÌ25¥Ð20­Ì151050ÌÎÓԸϩã®ÄË¢ªÅ«¥¶Ô¹ÅÈѪÎÌÓԱɴÅ图3-38 缺乏关键人员严重程度分布图

161412ùÇöµ10¼ÁîÌ8¥Ð6­Ì420105%106%107%108%109%110%111%112%113%114%115%³Ç¹ÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ图3-39 严重缺乏关键人员之进度影响柱状图

76ùÇ5öµ¼Á4îÌ3¥Ð­Ì210103%104%105%106%107%108%³Ç¹ÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ图3-40 一般缺乏关键人员之进度影响柱状图

37

南京大学硕士论文

4.543.5ùöǼµîÁ¥Ì­ÐÌ32.521.510.50101%102%103%104%³¹ÇÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ图3-41 轻微缺乏关键人员之进度影响柱状图

从图3-39、3-40和3-41可以看出，“缺乏关键人员”的程度不同，其对进度的影响程度也不相同；在同一种缺乏关键人员程度的情况下，其对进度的影响明显呈三角形分布。“缺乏关键人员”对项目进度影响整理如表3-4所示。

表3-4 缺乏关键人员对项目进度影响表

严重程度 严重 一般 轻微

最可能影响 10% 5% 2% 最悲观影响 15% 8% 4% 最乐观影响 5% 3% 1% 构造“缺乏关键人员风险因子”的累积风险图如下。

10.90.80.70.60.50.40.30.20.10104%ÑØÍÆÁù¼×¸½106%108%110%112%114%116%³¹ÇÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ图3-42 缺乏关键人员之累积风险图（严重）

38

南京大学硕士论文

10.90.80.70.60.50.40.30.20.10103%ÑØÍÆÁù¼×¸½104%105%106%107%108%109%³¹ÇÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ图3-43 缺乏关键人员之累积风险图（一般）

10.90.80.70.60.50.40.30.20.10101%ÑØÍÆÁù¼×¸½102%102%103%103%104%104%105%³¹ÇÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ图3-44 缺乏关键人员之累积风险图（轻微）

从图3-42可以看出，如果项目缺乏关键人员的程度为严重，项目实际时间是计划时间110%的可能性至少有一半。

3.4.6 缺乏高级管理者承诺和支持风险因子影响图曲线

软件项目组的成功，离不开高级管理者对项目的承诺、支持和关心。“缺乏高级管理者的支持和承诺”，软件项目组可能得不到足够的人力、工具和时间等资源，项目组成员的士气、项目的进度压力等问题将会凸现，进而影响项目按时交付。调查问卷设计了问题用以了解高级管理者对项目的支持程度，调查结果整理如图3-45所示。

从图3-45可以看出，46%的项目缺乏高级经理的支持和承诺，18%的项目获得了高级经理强有力的支持和承诺。

调查者被请求回答高级管理者能够容忍的项目进度扩展比例，调查结果整理如图3-46所示。

39

南京大学硕士论文

3530ùöǼµîÁ¥Ì­ÐÌ2520151050ı«£°¸Ó§±Ó¸Ó°§±Ó;Ӣ¬²É¬§±ÓÓı«£Ó§±Óß¹µ´¶Ø½³ÒßÓ§±Ó·Ê±Í³±É´Å图3-45 高级管理者对项目的支持态度柱状图

3530ùöǼµîÁ¥Ì­ÐÌ2520151050100%120%140%160%180%200%220%240%260%280%ضÁ¸ÅÙÅɳÁdz¹ÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ图3-46 高级管理者能够容忍的进度扩展比率柱状图

从图3-46中可以看出，28%的项目不允许有进度延迟，高级管理者允许进度延迟40%的项目占59%，没有项目被允许进度延迟超过100%。

为了了解高级管理者承诺和支持对项目进度的影响，所有调查者被请求回答“缺乏高级管理者对项目的承诺、支持和关心，对项目进度影响有多大？”问题，调查结果整理如图3-47、3-48所示，并且按承诺和支持程度进行了分类。

从图3-47和3-48可以看出，“缺乏高级管理者的承诺和支持”的程度不同，其对进度的影响程度也不相同；在同一种缺乏高级管理者承诺和支持程度的情况下，其对进度的影响明显呈三角形分布。“缺乏高级管理者承诺和支持”对项目进度影响整理如表3-5所示。

表3-5 缺乏高层管理对项目进度影响表

严重程度 非常不支持或者不支持 最可能影响 10% 最悲观影响 50% 最乐观影响 5% 40

南京大学硕士论文

76¼ùÁ¼ÇîÁ¥Ì­ÐÌ543210105%110%115%120%125%130%135%140%145%150%³¹ÇÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ中立状态 2% 4% 0% 图3-47高级管理者严重不支持或不支持对项目进度影响柱状图

109876543210100%101%102%103%104%³¹ÇÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ¼ùÁ¼ÇîÁ¥Ì­ÐÌ图3-48 高级管理者保持中立状态对项目进度影响柱状图

从图3-47和3-48可以看出，“缺乏高级管理者的承诺和支持”的程度不同，其对进度的影响程度也不相同；在同一种缺乏高级管理者承诺和支持程度的情况下，其对进度的影响明显呈三角形分布。“缺乏高级管理者承诺和支持”对项目进度影响整理如表3-6所示。

表3-5 缺乏高层管理对项目进度影响表

严重程度 非常不支持或者不支持 中立状态

最可能影响 10% 2% 最悲观影响 50% 4% 最乐观影响 5% 0% 构造“缺乏高级管理者的承诺和支持风险因子”的累积风险图如下。

41

南京大学硕士论文

10.90.80.70.60.50.40.30.20.10100%ÑØÍÆÁù¼×¸½110%120%130%140%150%³¹ÇÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ图3-49 缺乏高级管理者支持之风险图（严重）

10.90.80.70.60.50.40.30.20.10100%ÑØÍÆÁù¼×¸½101%102%103%104%105%³¹ÇÇǪ¹äÐë¹Ã¸®Çª¹äÓ®ªÅ图3-50 缺乏高级管理者支持之风险图（一般）

从图3-49可以看出，如果缺乏高级管理者承诺与支持的程度为严重，项目实际时间是计划时间120%的可能性至少有一半。

3.5 软件主要风险因子对项目进度的总体影响

影响软件项目进度的因素有很多，如项目运作过程中发生了需求膨胀，项目组人员流失或者投入不足，由于质量低下而导致的频繁返工等等，每一个因素对项目进度的影响程度也不一样。因此，选择对项目进度影响较大的因素进行分析，对理解项目进度的内在规律并运用此规律管理软件项目是有帮助的。

本文通过对计算机软件工程领域内相关文献著作的研究，并结合企业的实际项目分析，标识出了影响软件项目正常运作的6个主要风险因子，这6个主要风险因子对项目进度的影响也是显著的。通过进一步问卷调查和分析，得出了这6个风险因子对项目进度的影响曲线，由于在问卷调查过程中注意分离了各风险因子的交叉影响，可以认为影响曲线各自具有独立性。本文定义的项目进度总体影响就是由这6个独立的风险因子共同决定。

42

南京大学硕士论文

使用本文提供的基于风险因子分析的软件项目管理模型，输入几个项目参数，就可以得出主要风险因子对项目进度的总体影响。

43

南京大学硕士论文

第四章 基于风险因子分析的软件项目管理模型

基于风险因子分析的软件项目管理模型的主要目的，就是将制定软件项目风险管理计划与制定合理的软件项目进度计划有机地结合起来。在标识软件项目风险时，进度风险是考虑的重点，在制定软件项目进度计划时，要考虑达到进度目标可能遇到的风险及这些风险潜在的影响。本文提出的模型，通过标识软件项目的主要风险因子，分析这些风险因子各自对项目进度的潜在影响，并使用蒙特卡罗模拟方法，模拟出所选择风险因子对项目进度的影响。该模型可以用于标识、评估软件项目风险，制定风险规避、应急计划，以及制定合理的项目进度计划。

4.1 风险因子与不确定性

在软件项目开发过程中，充满了不确定性。管理软件项目，主要就是管理项目中的不确定因素。Gemmer（1997）将项目管理类的不确定性总结为表4-1所示的三种类型。

表4-1 项目管理不确定性分类表

类型 时间 控制 信息 定义 某事件什么时候发生及是否有能力去应对不确定 对过程决策或影响的权威性不够 决策所依赖的信息不充分或者不准确 项目经理都会经历表4-1中所列出的三种不确定性。比如，项目经理不知道某位项目组成员在什么时候会离开项目组（时间上不确定）；项目经理对项目组的实际需求变更过程能否符合既定的要求不确定（控制上不确定）；项目经理对产品质量能否满足发布要求不确定（信息上不确定）。

所有这些不确定性，当它与项目的成败休戚相关时，就成了项目的风险。根据Charette（1989）或者Henley和Kumamoto（1996）对于风险的量化定义，对于任何一个风险，必须相应地定义一个场景，该场景由风险因子组成。风险因子是促使或引起风险事件发生的条件，以及风险事件发生时，致使损失增加、扩大的条件。量化分析风险因子的不确定性，并将这种分析的结果传递到最终产品或者项目的输出，是一个有效地评估、管理项目风险的方法。

Demarco和Lister以风险图的形式来展示软件项目开发过程中的不确定性。本文使用了这种方法，对主要风险因子的潜在影响进行了分析。

44

南京大学硕士论文

4.2 软件项目风险因子

Madachy（1997）、Boehm（1991）以及Johns（1994）使用不同方法标识了软件项目的风险因子，本文主要通过对国内一著名通讯公司近3年来的207个软件项目进行研究和分析，标识出了影响项目运作和最终产品输出的20个风险因子。为了进一步研究这些风险因子对项目进度的影响，又从中选择了6个主要风险因子，通过问卷调查的方式，量化分析它们对项目进度的潜在影响。

需求膨胀风险因子

当需求新增或者需求发生变更时，将带来新的工作任务和活动，工作产品规模随之变大；同样地，需求膨胀也会导致对原有需求的设计返工。这些新开发任务或者返工给项目带来了额外的工作量，影响了项目正常开发的进度。问卷调查结果表明，新开发任务生产率与返工生产率基本一致，需求膨胀对项目进度的影响比较接近对数正态分布。使用非线性回归统计工具NLREG进行数据拟合，得到需求膨胀对进度影响分布符合对数正态分布LN（2.75%，1.5%），该分布表明，由于需求膨胀，项目实际时间是计划时间的110%的可能性至少有一半。

工作量估计不准确风险因子

软件项目工作量估计不准确是一个非常普遍的问题。问卷调查结果表明，在去除掉需求膨胀对工作量的影响后，工作量偏差分布基本上符合正态分布。使用非线性回归统计工具NLREG进行工作量数据拟合，得到工作量偏差分布符合正态分布N（10.8%，26.3%）。也就是说，大约有68%的软件项目，其工作量变化范围在(-15.8%，46.1%)之间。软件项目工作量估计不准确的影响是明显的，当估计的工作量小于实际需要时，项目的人力投入会减少，或者进度时间点会提前，这两种情况都将会使项目的实际成本更高，项目组成员的士气降低。当估计的工作量大于实际需要时，项目的人力投入会增加，或者进度时间点会推迟；这将使项目组成员得不到充分的使用。在人力资源投入情况确定后，“工作量估计不准确”风险因子对项目进度的潜在影响可以简单地等同于工作量偏差分布。因此，由于工作量估计不准确，项目实际进度时间是计划时间110%的可能性至少有一半。

人员流失风险因子

项目组成员流失或者投入不稳定，使得项目组缺乏有经验的人员，并在可能的情况下增加新人到项目组。由于缺乏有经验的人，将导致缺陷引入增加，缺陷也不能尽早发现，项目组的士气也有一定程度的下降，所有这些将会导致生产率的下降，最终引发进度延迟问题。增加新人到项目组，由于存在接手时间，进度也会有延迟。问卷调查结果表明，新人接手时间大多数在3周以内，人员流失对进度影响的曲线基本符合对数正态分布曲线。使用非线性回归统计工具NLREG进行数据拟合，得到人员流失对进度影响分布符合对数正态分布LN

45

南京大学硕士论文

（6.75%，2.2%）。该分布表明，人员流失对项目进度影响较大，由于人员流失的风险，一个项目实际时间是计划时间的125%的可能性至少有一半。

对平台/环境/方法不熟悉风险因子

对项目平台/环境/方法不熟悉，将导致更多的正式培训或者边干边自学，也会导致更多的项目沟通时间，错误引入也会因为对平台/环境/方法的不熟悉而增加，所有这些将会降低项目组的生产率，从而使得进度延迟。问卷调查结果表明，对平台/环境/方法越不熟悉，所花费的培训时间越多，对项目进度的影响也越大；在同一种不熟悉程度的情况下，其对进度的影响呈三角形分布。如对平台/环境/方法不熟悉的程度为严重时，对进度最可能的影响是8%，最悲观的影响是12%，最乐观的影响是5%。

缺乏关键人员风险因子

项目组缺乏关键人员，将导致不具备相关技能的人员上岗。由于不具备技能，培训工作量上升，缺陷引入上升，而缺陷检测水平下降，所有这些，将导致生产率下降，从而使得进度延迟。问卷调查结果表明，82%的软件项目组缺乏关键人员，其中大多数又属于“严重”缺乏关键人员。缺乏关键人员的程度不同，其对进度的影响程度也不相同；在同一种缺乏关键人员程度的情况下，其对进度的影响呈三角形分布。如严重缺乏关键人员时，对进度最可能的影响是10%，最悲观的影响是15%，最乐观的影响是5%。

缺乏高级管理者支持和承诺风险因子

项目组缺乏高级管理者的支持和承诺，一般存在人为压缩进度、人力资源投入不足、或者在增加新任务的情况下不能调整进度的现象，这些将使得项目组成员在过度的进度压力环境下工作，最终导致项目进度的延迟。而且，如果项目组缺乏高层管理者的支持和承诺，项目组的士气则大为降低，影响了项目组成员能力的发挥，也降低了生产率。问卷调查结果表明，46%的项目缺乏高级管理者的支持和承诺；无论在什么情况下，87%的项目进度延迟不允许超过40%；缺乏高级管理者的支持和承诺的程度不同，其对进度的影响程度也不相同，在同一种支持程度的情况下，其对进度的影响呈三角形分布。如高级经理对项目非常不支持或者不支持时，对进度最可能的影响是10%，最悲观的影响是50%，最乐观的影响是5%。

4.3 模拟模型

模拟是建立系统或决策问题的数学或逻辑模型，并以该模型进行试验，以获得对系统行为的认识或帮助解决决策问题的过程。自古以来就有应用，普鲁士军队早年常通过举行野外演习来模拟战争，让士兵们按他们总参谋长的狂想作穿越中欧森林的全天候行军。再比如飞行员利用能显示飞机在特定条件下将对飞行员的动作作出何种反应的模拟器，使得飞行员不必体验受伤的危险就知道如何应付紧急情况。今天，模拟已被广泛接受，用于预测、解释问题、培训人员和帮助识别最优解决方案。

46

南京大学硕士论文

模拟与其他管理学方法一样，也是围绕着模型进行的。模型是对实际系统、思想或客体的抽象与描述。模拟模型对特定输入量集合直接评估系统性能或行为的各种量度，如图4-1所示。模型的输入量包括使用者指定的可控（决策）变量，及表述问题之环境的不可控变量或常数。

输入输出决策与不可控变量模拟模型图4-1 模拟模型示意图

性能或行为的量度蒙特卡罗模拟模型是一种典型的模拟模型，它基本上是抽验试验，其目的是估计由若干概率输入变量而定的结果变量的分布。

4.4 基于风险因子分析的软件项目管理模型介绍

一个将风险管理计划与合理的项目进度计划融为一体的模型必须能够满足三个基本要求：1）初步的估计；2）基于估计结果进行不确定性分析，并输出一幅风险图，图中展现一个有可能完成项目的时间段，以及与之相关的不确定性；3）相应的风险管理计划。该模型如图4-2所示。

风险因子基于风险分析的软件项目管理模拟模型风险计划风险因子…风险因子进度计划估计模型图4-2 基于风险因子分析的软件项目管理模型

鉴于软件估计模型的研究已经相对成熟，相关的工具也已经非常普及，本文提出的基于风险因子分析的软件项目管理模型中不再包括估计模型，但是，估计模型的输出结果就是本文提出的模型的一个重要输入。

基于风险因子分析的软件项目管理模型的设计思想如下：

47

南京大学硕士论文

1， 标识出软件项目的常见风险因子。

2， 选择主要的风险因子，进行量化分析，分析其对产品或项目输出的影响。本文仅分

析风险因子对项目进度的影响。分析结果以风险图的方式给出。

3， 使用蒙特卡罗模拟方法，模拟出所选择的风险因子对产品或项目输出的影响。该影

响以风险图的方式给出。

4， 利用模型中识别出的主要风险因子，标识软件项目风险；利用风险因子的潜在影响

和项目或产品输出的要求，标识软件项目风险。制定软件项目风险管理计划。 5， 根据项目的实际情况和既定的成功交付可能性，制定合理的软件项目进度计划。

4.5 基于风险因子分析的软件项目管理模型的实现

基于风险因子分析的软件项目管理模型已经在微软的Excel电子表格软件上得以实现。之所以选择Excel，是因为它所具有的灵活性及强大的统计功能。本模型使用到的Excel主要功能有：

随机数生成

蒙特卡罗模拟方法是一种统计试验方法，是用来解决非确定性问题（概率统计的或随机的）的数值方法，因此，随机数生成及相关处理是蒙特卡罗模拟方法关注的重点内容。本模型利用Excel提供的RAND函数，来生成随机数。RAND（）函数没有自变量，不需要在括号内填写什么，可以在任何单元格内生成随机数。除非自动重算特性受到抑制，否则，每当Excel电子表格中的任何一个单元被修改时，包含RAND（）函数的任何单元内的数值都将被改变。

特定分布生成

本模型中的风险因子对项目进度的影响曲线各不相同，有的是正态分布，有的是对数正态分布，还有的是三角形分布。Excel提供的LOGNORMDIST（）对数正态分布函数、LOGINV（）对数正态分布逆函数、NORMDIST（）正态分布函数、NORMINV（）正态分布函数可以很方便地生成正态分布、正态对数发布。

统计图表

Excel提供了强大的统计图表功能，方便用户进行自动统计，并将结果以表格或者图形的方式呈现，易于理解和沟通。本模型中的各主要风险因子影响曲线（散点图）、项目进度模拟模型图（柱形图）、风险管理计划表格、进度模拟数据汇总表格等图表均使用了Excel提供的图表功能。

宏

如果经常在 Microsoft Excel 中重复某项任务，那么可以用宏自动执行该任务。宏是存储在 Visual Basic 模块中的一系列命令和函数，当需要执行该项任务时可随时运行宏。 本

48

南京大学硕士论文

模型中录制了一些宏，用以自动执行某些任务。

4.5.1 模型的功能及结构

基于风险因子分析的软件项目管理模型由九个Excel工作页面组成，主要包括项目管理模拟模型页面、风险因子设定及风险管理计划页面和7个风险因子影响模拟页面。

风险因子影响模拟页面

风险因子影响模拟页面共包括6个主要风险因子对进度影响页面以及1个进度模拟数据汇总页面。在主要风险因子对进度影响页面中定义了风险因子对进度的缺省影响风险图以及蒙特卡罗模拟的结果，模拟的次数目前定义为500次。缺省影响风险图的数据全部来源于对某通讯公司83位项目经理问卷调查的结果。

为了提高本模型的灵活性，在这些风险因子影响模拟页面，还提供了一个功能，就是用户可以根据自己项目的实际情况以及历史项目经验，主动调节这些风险因子对项目进度影响的分布数据。

示例：对项目平台/环境/方法不熟悉因子页面主要内容如图4-3所示。

图4-3 对项目平台/环境/方法不熟悉风险因子影响模拟页面

风险因子设定及风险管理计划页面

49

南京大学硕士论文

在运行项目管理模型前，项目经理应该根据项目的实际情况，选择本项目组的主要风险因子。对于所选择的主要风险因子，结合其原因——结果图，并运用场景分析的方法，标识出软件项目组的主要风险。

项目组的主要风险因子确定后，就可以运行模型了。分析模拟的结果与客户期望的差距，有些时候，需要调整特定风险因子对进度的影响程度才能满足客户的需要。这时可能标识出新的项目风险，或者是调整原有风险的风险级别。

风险标识完成后，就要制定项目组的风险管理计划了，主要包括确定风险的措施，责任人，风险的起始日期和结束日期。

示例：风险因子设定及风险管理计划页面

图4-4 风险因子设定及风险管理计划页面

图4-4中风险管理计划的主要栏位及说明如下。

序号 风险风险当前风险责任开始结束执行描述 措施 状态 级别 人

日期 日期 结果 风险描述：描述项目组标识出的风险，通常采用“条件——结果”的方式进行描述。如：没有一个严格的变更控制过程用于协调所有受影响的相关组，测试用例可能不会随着需求变更做相应变化。

风险措施：描述风险的处理方法。风险措施与风险策略相呼应，风险策略一般有风险规

50

南京大学硕士论文

避、风险接受、风险转移和风险减轻这几种。

当前状态：描述风险当前所处的状态，如尚未发生、风险措施已启动、风险已关闭等等。 风险级别：根据风险的影响程度确定风险的等级，也就是风险关注度。应该把有限的资源投入到风险级别最高的风险措施中去。

责任人：风险跟踪以及风险措施的承担者。

开始日期：表明从哪天开始就需要关注该风险了，一般是监控风险的转化指标。 结束日期：表明从哪天开始就不再需要关注该风险了，无论其是否规避、减轻、转移，或者是根本就没有发生。

执行结果：针对该风险的处理结果及措施有效性评价。通常包括：关闭——措施有效、关闭——措施无效、关闭——风险没有发生等等。

项目管理模拟模型页面

项目管理模拟模型页面是本模拟模型的结果显示页面。点击“运行模拟模型”按纽，系统就会自动生成项目进度模拟模型统计图，该图既显示了每一种模拟结果出现的次数，也显示了累积可能性。图4-5显示9月5日前完成项目的可能性为60%。

图4-5 项目管理模拟模型页面

51

南京大学硕士论文

4.6 模型使用案例

项目经理小吴从产品经理那里接受到一项任务，开发一款宽带接入设备的软件系统，该系统主要支持：1）用户接入、认证和管理功能；2）业务配置功能；3）地址管理功能；4）5级QOS调度。产品经理在安排任务的同时，提出了对项目组的期望，希望项目组能够在4个月内开发完成，产品提供的人力资源在30人左右。小吴并没有当场拍胸脯说能够完成任务，而是说下去后计划一下，看看能否按时完成任务。产品经理同意了他的请求。

小吴在数据通讯领域工作了近10年，其中有6年项目管理经验，业务领域知识和项目管理知识都非常丰富。小吴下来后，仔细研读了由产品提供的需求文档。小吴认为，需求文档写得非常清楚、完整，可以作为下一步工作的输入。小吴根据自己对产品需求的理解，对产品进行了适当分解，初步估计出软件项目代码规模在95千行代码行左右。如果根据历史项目的生产率数据，以及可能得到的30个人力资源，小吴估计完成该项目需要103个工作日，基本能够满足产品经理的要求。

但是，小吴对于能否在103个工作日内交付该软件系统显得信心不足，因为这个项目存在一些不确定性，比如项目需求是否会发生变更？虽然有30个人力资源，但是否都具有项目所需要的技能尚不可知。后来，小吴通过其他人了解到有一种基于风险因子分析的软件项目管理模型，该模型量化分析了6种主要风险因子对软件项目进度的影响，可以模拟出比较合理的进度计划。于是，小吴决定使用该模拟工具，帮助自己制定项目进度计划。

小吴打开“基于风险因子分析的软件项目管理模型”，首先按照模型的提示，输入了项目的计划启动日期“2005-02-24”和初步估计的结束日期“2005-06-30”。之所以将结束日期设定为“2005-06-30”，是考虑了“五一”国际劳动节假期和每周6个工作日的工作制度。接着，小吴打开了“风险因子设定及风险管理计划页面”，仔细研究了6种风险因子及其描述内容，认为这6种风险因子在项目组都有可能存在，于是，他将这6种风险因子的状态全部设定为“打开”。对于“工作量估计不准确”、“需求膨胀”、“项目组成员流失”这三种风险因子，他决定使用缺省的风险图数据；对于“对项目平台/环境/方法不熟悉”、“缺乏关键人员”这两种风险因子，他决定使用严重程度为“一般”的缺省风险图数据；对于“缺乏高级管理者承诺和支持”风险因子，他选择的严重程度为“中立状态”。

设定完成后，小吴点击了“运行模拟模型”按纽。模拟模型经过500次模拟，输出了项目进度模拟风险图，从图上可以看出，项目在7月5日之前完成的可能性仅有10%左右，在9月5日前完成的可能性大概在50%，项目在2006年3月完成的可能性为100%。

小吴带着这些结果数据找到产品经理，并向产品经理介绍了模拟模型的原理和涉及的6个主要风险因子，以及这些风险因子对项目进度的影响。产品经理对模拟模型的思路表示肯定，也认同运行结果的可信度。然后，产品经理再一次强调了产品的战略意义，并指出，及

52

南京大学硕士论文

时在海外，尤其是欧洲市场推出这款设备，将使我们在激烈的竞争环境中占据主动权，对提升产品的品牌效应和市场占有率大有好处。

产品有市场进度压力，但按时完成又几乎不可能。如何解决这个矛盾？产品经理建议小吴与他一起分析这6个风险因子，并寻找一些降低风险影响程度的措施。首先，产品经理表示，鉴于产品的战略意义，公司高级管理者已达成共识，将不遗余力地支持和关注该项目，优先满足项目的各项资源需求。因此，产品经理建议，将“缺乏高级管理者承诺和支持”风险因子关闭。小吴接受了产品经理的建议。对于“工作量估计不准确”风险因子，小吴和产品经理一致认为，下来后需要邀请项目组骨干成员和部分业务领域专家，使用正式的软件估计方法，估计软件项目工作量；并且在后续的软件需求分析、软件设计等阶段结束时，重新估计项目所需要的工作量。对于“需求膨胀”风险因子，小吴向产品经理提出了如下要求：1）产品使用多种方法收集、确认客户需要，并详细地文挡化；2）对于客户提出的需求变更请求，产品需要认真分析，适当控制变更的规模和时间点；3）当需求变更时，要使用正式的方法通知到相关受影响的组和个人。产品经理接受了小吴的建议，并建议小吴将“需求膨胀”因子带来的风险写进项目组风险管理计划。对于“项目组成员流失”风险因子，产品经理建议小吴多组织一些团队活动，活跃项目组工作气氛，留住人才；产品经理同时也表示，如果有人在完成其承诺的任务之前离开了项目组，产品将及时补充人力，供项目组调配。小吴也向产品经理提出了一个请求，就是尽量避免项目组成员承担项目组之外的其他任务，产品经理表示明确支持。对于“对平台/环境/方法不熟悉”、“缺乏关键人员”两个风险因子，产品经理表示本产品的开发平台/环境与以前产品基本相同，开发方法也一致，产品也会按照项目组的需要，提供合乎要求的人力资源给项目组使用，因此，他建议将这两个风险因子的状态改为“关闭”，小吴经过一阵思考后，接受了产品经理的建议。

小吴下来后，召集了五名业务领域的专家，使用Delphi专家估计方法，估计软件系统的规模、工作量和进度。新的估计结果显示项目需要98个工作日才能完成，这与小吴的初始估计结果相差不大。小吴再一次运行了“基于风险因子分析的软件项目管理模型”，输入项目的计划启动日期“2005-02-24”和初步估计的结束日期“2005-06-24”，并将“对项目平台/环境/方法不熟悉”、“缺乏关键人员”、“缺乏高级管理者承诺和支持”这三种风险因子的状态设定为“关闭”。模拟模型经过500次模拟后，输出了项目进度模拟风险图，从图上可以看出，项目在7月5日之前完成的可能性为30%左右，在8月5日前完成的可能性大概在50%，项目在2006年1月完成的可能性为100%。

53

南京大学硕士论文

îÁ̼º÷´ÅÁ£ÁâÁ£ÍÊ120ùËÇÁ²Ó³öÌâ±£ÁÁ10.80.60.40.20May-May-Jun-Jul-Aug-Sep-Oct-Nov-Dec-Jan-05050505050505050506îÁ̼ʱ±ÆÅÒÃÖÑØÍÆÁù¼×¸½54

100806040200

小吴将模拟模型输出的结果向产品经理做了汇报，产品经理接受了小吴的估计结果，并要求小吴根据主要风险因子做好风险管理计划。小吴则向产品经理承诺在8月5日前交付软件系统，尽管存在风险，但还是有50%的把握。小吴随即输出了项目组的风险管理计划，主要内容如表所示。 风险描述 需求发生膨胀，影响项目组的开发任务并导致进度延迟 风险措施 1、产品使用多种方法收集、确认客户需要，并详细地文挡化 2、对于客户提出的需求变更请求，产品进行认真分析，适当控制变更的规模和时间点 3、当需求发生变更时，要使用正式的方法通知到相关受影响的组和个人 1、邀请项目组骨干成员和部分业务领域专家，使用Delphi专家估计方法，估计软件项目工作量 2、在软件需求分析、软件设计等阶段结束时，重新估计项目所需要的工作量 1、多组织一些团队活动，活跃项目组工作气氛，留住人才 2、如果有人在完成其承诺的任务之前离开了项目组，产品将及时补充人力，供项目组调配 3、尽量避免项目组成员承担项目组之外的其他任务， 工作量估计不准确，导致项目实际进度与计划进度有偏差 项目组成员在完成承诺的任务之前离开项目组，导致项目进度延迟 对于状态设定为“关闭”的另外三个风险因子，小吴决定将他们列入项目计划，看作是项目的假设条件，并进行跟踪。

对于小吴以及他的项目组而言，接下来的挑战是如何根据风险管理计划，跟踪监控项目风险，落实风险措施，使得风险对项目组的影响程度降低，从而完成产品交给的软件系统开发任务。

南京大学硕士论文

4.7 模型验证

基于风险因子分析的软件项目管理模型的验证主要从两个方面进行，一个是验证模型能否正常工作，并且满足它的设计思路；另一个就是确认它是否能够满足项目经理的需要，做出合理的项目进度计划和风险管理计划。

模型能否正常工作的验证内容主要包括： 1、 能否正确地生成模拟所需要的随机数？

2、 正态分布、对数正态分布、三角形分布的生成是否正确？各种分布所使用的源数据

是否与问卷调查的结果一致？ 3、 所使用的公式、宏是否正常运作？

经过验证，结果完全符合预期的设计思路，模型的实现没有问题

确认模型是否能够满足项目经理的需要，需要更多项目的实际运用，模型的推广和确认工作会一直持续下去。在模型原型输出后，曾邀请项目经理们做过评审，大家对模型的思路给予了肯定的评价，对6个主要风险因子的潜在影响模拟，除了可以使用缺省的参数外，项目经理也可以根据项目的实际情况进行调整的做法，也给予了肯定的评价。

55

南京大学硕士论文

第五章 总结与展望

本文研究如何制定合理的项目进度计划和风险管理计划，并将二者有效地融合起来。具体做了以下几个方面的工作：

研究了一些文献著作，内容包括软件估计方法、软件风险管理理论、风险因子影响分析、模拟模型。

对某通讯公司的207个软件项目风险管理计划、项目结束总结报告进行分析，标识出软件项目常见的20个软件项目风险因子。

选择6个主要风险因子，使用问卷调查的方法，调查了83位项目经理关于这6个风险因子对项目进度的潜在影响评价。使用统计分析的方法，得出这6个风险因子对进度影响的风险图。

本文提出、实现并验证了“基于风险因子分析的软件项目管理模型”。该模型可以帮助软件项目识别主要的项目风险，模拟主要风险因子对软件项目进度的潜在影响，从而指导项目经理制定出项目风险管理计划和合理的项目进度计划。

本文的主要贡献在于：

1、 通过文献的研究和多个实际项目的分析，给出了软件项目常见的20个风险因子。 2、 研究并调查了6个主要风险因子对项目进度的潜在量化影响。

3、 提出了“基于风险因子分析的软件项目管理模型”，模型的输出是以风险图形式表现

的项目进度。

4、 该模型能够使用在某种风险管理过程框架之下，即完成风险标识、风险评估以及风

险计划制定。 进一步的研究方向：

1、 本文提出的模型中所涉及主要风险因子，对于一般软件项目类型合适的。对一些特

定的软件项目类型，如维护项目、个人开发等，则需要进一步标识特定的风险因子，并进行风险因子影响分析。

2、 本文主要研究了风险因子对项目进度的影响。对于项目管理领域的项目成本、项目

质量管理可以使用同样的研究方法。集成研究和管理软件项目进度、成本、质量和风险，将极大提高软件项目成功的可能性。

56

南京大学硕士论文

参考文献

1、[美]Schwalbe, K.著，邓世忠等译 《IT项目管理》 机械工业出版社 2004年 2、[英]Hughes, B.著，周伯生等译 《软件项目管理》 机械工业出版社 2004年 3、[美]DeMarco, T., Lister, T.著，熊节等译 《与熊共舞——软件项目风险管理》 清 华大学出版社 2004年

4、[美]Pressman, R.S.著，梅宏译 《软件工程：实践者的研究方法》 机械工业出版 社 2002年

5、[美]Kan, S.H.著，吴明晖等译 《软件质量工程——度量与模型》 电子工业出版 社 2004

6、[美]Frederick P.Brooks著，汪颖译 《人月神话》 清华大学出版社 2004年 7、国际功能点用户组织编著，方德英译 《IT度量——专家实践》 清华大学出版 社 2003年

8、[美]Chris F.Kemerer著，李玉英等译 《软件项目管理：阅读与案例》 上海财经 大学出版社 2004年

9、[美]Peter Senge著，郭进隆译 《第五项修炼：学习型组织的艺术与实务》 上海 三联书店 2001年

10、[美]Glass, R.L.著，陈河南等译 《软件开发的滑铁卢——重大失控项目的经验与 教训》 电子工业出版社 2002年

11、[美]Weinberg, G.M.著，邓俊辉译 《质量·软件·管理——系统思维》 清华大学出 版社 2004年

12、[美]Brown, W.J., and McComick, H.W. and Thomas, S.W.著，杨晓燕，任树芳，王虹 等译 《项目管理反模式诊断：软件开发常见错误规避》 电子工业出版社 2004 年

13、[美]Evans, J.R.著，洪锡熙译 《模拟与风险分析》 上海人民出版社 2001年 14、[美]McConnell, S.著，席相霖等译 《快速软件开发——有效控制与完成进度计划》 电子工业出版社 2002年

15、邱箢华主编 《现代项目风险管理方法与实践》 科学出版社 2003年 16、姜青舫等著 《风险度量原理》 同济大学出版社 2000年 17、何文炯主编 《风险管理》 东北财经大学出版社

18、张珞玲，李师贤 软件项目风险管理方法比较和研究 计算机工程 2003年 19、方德英，李敏强 IT项目风险管理理论体系构建 合肥工业大学学报 2003年

57

南京大学硕士论文

20、Hall, Elaine M., \"Managing Risk: Methods for Software Systems Development\ Addison-Wesley, 1998

21、Martyn A. Ould, \"Strategies for Software Engineering: The Management of Risk and Quality\

22、Robert N. Charette, \"Software Engineering Risk Analysis and Management\ Multiscience Press, Inc., 1989

23、Capers Jones, \"Assessment and Control of Software Risks\24、Andy Cole, \"KPMG 1995: Runaway Projects – Causes and Effects\ (UK), Vol. 26, No. 3, 1995

25、John P.Kindinger, \"Risk Factor Analysis – A New Qualitative Risk Management Tool\ Proceedings of the Project Management Institute Annual Seminars & Symposium, September 7-16, 2000

26、Tim Menzies and Erik Sinsel, \"Practical Large Scale What-if Queries: Case Studies with Software Risk Assessmenth IEEE International Conference on Automated Software Engineering September 11-15, 2000

27、Raymond J.Madachy, \"Heuristic Risk Assessment Using Cost Factors\ 1997

28、Gerrit Klaschke, \"What the CHAOS Chronicles 2003 Reveal\29、Moshe Ayal, \"The Effect of Scope Changes on Project Duration Extensions\"

30、Barry W.Boehm, \"Software Risk Management: Principles and Practices\ 1991

31、Ronald P.Higuera and Yacov Y.Haimes, \"Software Risk Management\ Engineering Institute, 1996

32、Barry W.Boehm, \"Software Engineering Economics\

58

南京大学硕士论文

致谢

在本论文的选题、资料收集和论文写作过程中，自始至终受到了导师邵栋老师和金志权教授的亲切关怀和悉心指导，谨在此表示衷心的感谢。

在论文素材收集和问卷调查过程中，得到了公司诸多项目经理和同事们的帮助，抱歉在此不能一一写上你们的名字，千言万语化作四个字：谢谢你们。并请你们在后续的项目开发过程中使用、验证和优化该模型。

同时，我还要感谢南京大学软件学院的李宣东教授、骆斌教授、赵建华老师、赵志宏老师、顾庆老师等老师以及班主任方长泉老师，你们严谨的治学态度和诲人不倦的风范使我终生受益，也让我快乐地享受了久违的校园生活。

千里难寻是朋友，千金难买是亲情。南大三年，友情是我快乐的源泉和莫大的欣慰，亲情是我不倒的支柱和前进的动力。衷心感谢所有同窗好友在学习上给予的关心和鼓励！衷心感谢默默支持、无私关爱我的家人！谨以此文献给你们。

59