基于风险因子分析的软件项目管理模型.doc
基于风险因子分析的软件项目管理模型 摘要 软件项目开发过程中存在着大量不确定事件,这给项目的成功带来了风险。能否在规定的时间内交付软件产品,与项目进度计划是否合理、项目风险管理活动是否有效有很大的关系。这需要综合考虑软件项目进度计划与软件项目风险管理计划,提供工具用以标识、分析和管理软件项目风险,并在此基础上获得合理的软件项目进度计划。 本文提出了基于风险因子分析的软件项目管理模型。本文通过对文献著作的研究和某通讯公司软件项目的实际分析,标识出影响软件项目成功的 20 个风险因子,并根据其出现的比例,选择 6 个主要风险因子进行进一步地量化分析,分 析它们各自对软件项目进度的影响,并使用蒙特卡罗模拟方法,模拟出所选择的风险因子对软件项目进度的总体影响,该影响以风险图的方式给出。同时,利用模型中识别出的主要风险因子,标识软件项目风险;综合考虑风险因子的潜在影响和项目进度的要求,制定出软件项目风险管理计划和合理的软件项目进度计划。 本文实现了基于风险因子分析的软件项目管理模型,并对模型本身进行了正确性验证,也在软件项目组进行了符合项目经理需要的确认。结果显示,该模型能够帮助项目经理制定风险管理计划和合理的进度计划。 关键词:风险因子;模型;风险管理计划 ;进度计划。 第一章绪论 1.1 本文研究的背景及问题 软件已经成为基于计算机的系统及产品成功的关键因素,其重要作用已经得到了人们的普遍认同。在过去的 50 年中,软件已经从特殊的问题解决和信息分析工具演化为一门独立的产业,但在提供客户所需要的软件的能力方面取得的进展却非常缓慢。软件项目失控现象依然大量存在。著名的 CHAOS 报告( 2003) [28]中的一些统计数据如下: 66%的软件项目失败, 15%的软件项目在完成前被取消; 82%的软件项目交付延期, 43%的软件项目实际成本超过预算, 48%的 客户需求没有得到满足。 造成以上现象的原因有很多, Jones( 1994) [23]针对交付延期和预算超支的现象,归纳出以下四个根本原因: 1、在项目初始估计时,进度 /成本就是不可能达到的目标,但项目还是如期启动了; 2、在项目进度 /成本确定后,项目范围发生了变化; 3、项目估计和计划的方法不合理; 4、企业没有收集有用的历史数据。 在软件业,学术界和企业界都越来越强烈地相信,没有一个独立的方法、技术、工具或过程能够解决软件项目失控问题,驾御项目失控最好的方法是从开始就管理项目的风险。 [KPMG1995][24]报告中列举的项目失控企业, 55%的失控项目没有实行过任何风险管理,而在 38%实行了风险管理 (有些调查者不知道是否实行了风险管理 )的项目中 ,有 50%的项目在启动之后没有使用风险发现 (RiskFinding),缺少风险管理可能会导致项目失控的事件。管理项目风险的好处是明显的, Boehm( 1989)认为,风险管理之所以重要,是因为它使得人们脱离灾难,避免返工,并促使软件项目取得双赢的局面。 Jones 认为软件项目计划不合理是软件项目交付延期的主要原因。大多数人在做项目计划时比较乐观,倾向于 忽视某些“可能需要做”的工作,而不是把“可能不需要做”的工作也计算在内。“可能需要做”与“可能不需要做”这种不确定性事件正是风险管理的内容。因此,在制定软件项目进度计划时,考虑风险对软件项目的潜在影响,并将这种影响落实到软件项目进度计划中,将避免过度的项目进度压力现象。Kemerer( 1991) [8]认为进度压力常常在项目的后期出现,并对项目带来三个主要方面的影响: 1、经济影响。后期发现项目无论如何也不能在接近计划范围内完成,常常导致项目被取消,同时到此为止的所有工作都将前功尽弃。 2、产品质量影 响。当项目计划的成本或进度目标临近,但还剩余大量附加工作时,为了按照计划或接近计划完成项目,一般会缩减最终任务。当最终期限到来时,在无法确定交付产品质量的情况下,项目常常会停止测试而简单进行交货。 3、组织影响。当不切实际的最终期限临近时,为了尽快完成项目,全体开发人员可能要忍受被施加的附加压力。这种压力除了有可能会对工作质量产生短期不利影响之外,对士气的长期影响也是巨大的。如果在项目开发的后期,给项目组增加人力,又可能产生所谓的布鲁克斯( Brooks1974)现象:给后期项目增加人力,会导致项目推迟完 成。如果这样的问题遍布整个组织,那么,将产生一种“恐慌心理”。 在软件领域,关于项目风险管理和项目进度计划主题的文献著作很多。 Boehm( 1991)在他的《软件风险管理:原理和实践》 [30]一文中提出一种软件项目风险管理的方法,他将风险管理划分为风险评估和风险控制,并对每一种分类提供了许多步骤。对每一个步骤都给出了一个简短的技术列表,并附有 TRW 一些实际项目的例子。一组有用的图表说明了这些技术,包括项目风险因子的 TopTen 列表。 Fairley( 1994)在他的《软件项目的风险管理》 [8]一文中验证了 Boehm 的方法在电信软件项目中的应用,他充分利用了 COCOMO 成本估算模型来估计风险因子对预算的影响,并且证明了人们可以利用统计学方法求出可能产生结果的预期范围。软件进度计划方面的研究主要体现在两个方面。一方面关注如何提高进度估算的能力, Boehm( 1981)在他的《软件工程经济学》 [32]一书中提出了 COCOMO 成本估计模型; Vicinaca 等人( 1991)在《软件投入估计中以案例为基础的论证》 [8]中使用人工智能领域的技术开发了一个以知识为基础的成本估计系统; Abdel-Hamid( 1989)在《从软件 开发动力学的模拟中学习的课程》 [8]中使用系统动力学开发了一个成本估计模型,该模型可以重复一些共同的现象,如布鲁克斯规则。进度计划研究的另外一个方面关注如何安排项目进度,主要的技术有关键路径法( CriticalPathMethod, CPM)、关键链进度计划( CriticalChainSchedule)以及计划评审技术( ProgramEvaluationandTechnique, PERT); McConnell( 1996)在他的《快速软件开发:有效控制与完成进度计划》 [14]一书中对导致乐观的软件项目进度安排的 问题进行了深入讨论,并指出了你能为此做些什么; Brooks( 1995)则在《人月神话》 [6]一书中提出了著名的布鲁克斯规则。 不难发现,软件项目风险管理的研究与项目进度计划的研究是有交集的,在考虑项目风险时,进度风险通常是考虑的重点,在制定项目进度计划时,要考虑达到进度目标可能遇到的风险。但是,将软件项目风险管理与项目进度计划有机地结合起来的综合研究还鲜见于文献资料。本文提出一种基于风险因子分析的软件项目管理模型,能方便地帮助软件项目标识出主要的风险因子,并量化分析风险因子对项目进度的影响,最终给出合理 的项目交付进度计划。 1.2 软件估计常用方法 软件项目管理过程总是从项目计划开始。在项目可以开始前,管理者和软件小组必须估计将要完成的工作、所需要的资源以及从开始到完成所需要的时间。软件估计需要经验、以前项目的有用信息,以及当仅存在定性的数据时进行定量估计的勇气。 软件估计是一项预测未来的工作,天生具有某种程度的不确定性, Kemerer 描述了由于估计不准而给项目造成的经济、质量和组织影响。为了解决这些估计不准的问题,软件业界对估计做了大量的研究,提出了许多软件估计方法和工具。由于软件进度估计总是 依赖于软件工作量估计和可以投入的软件人力资源,在人力资源投入策略确定后,软件开发工作量与软件项目进度的对应关系就确定了。所以本文仅仅介绍常用的软件工作量估计方法。 1.2.1 算法模型估计方法 算法模型估计方法又称参数估计方法,它使用特定的数学公式进行软件工作量估计,该公式是经过一定的理论推导或者通过历史项目经验数据总结而得到的。参数估计方法的输入通常有软件代码行规模,软件功能点数,以及设定的工作量驱动因子。参数估计方法的准确度可以通过校正因子处理而得到提高。 参数估计方法的最大优点是能够重复进行 估计,输入参数可以方便地进行调整,所使用的数学公式也可以进行优化。其最大缺点是不能处理意外情况。参数估计方法的例子有: COCOMO(结构成本模型) COCOMO 方法是 Boehm1981 年在其著名的《软件工程经济学》 [32]中提出的一种软件估计方法,它实际上是一个包含三个详细程度( Basic, Intermediate, Advanced)逐渐增加的层次模型结构。 COCOMO 方法又根据待开发软件的特点,分为组织式、半分离式和嵌入式三种模式。 COCOMO 估计模型具有以下形式: 式中, MM 是以人月为单位的工作量, TDEV 是以月表示的项目持续时间, EAF 是成本调整因子(对于Basic 模型, EAF=1), a, b, c, d 的取值与模式有关。 一个简单的例子: 一个飞行器控制系统,其代码规模为 319KDSI,属于嵌入式模式。可靠性要求非常高,故 a 取 1.40。计算结果如下: SLIM(软件方程式模型) SLIM方法是在 20 世纪 70 年代后期由 QSM 组织的 Putnam 开发的,它是一个动态的多变量模型。该模型假设在软件开发项目整个生命周期中存在一个特定的工作量分布曲线。该模型是从 4000 多个当代软件项目中收集的生产率数据中导出的。基于这些数据,估计模型具有以下形式: 式中, E 为以人月或人年为单位的工作量, t 为以月或年表示的项目持续时间, B 为“特殊技能因子”,随着“对集成、测试、质量保证、文档及管理技能的需求的增长”而缓慢增加。对于较小的软件( 5~15KLOC), 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,直到达到一个可以 接受范围内的估计。 1.2.3Top-Down(自上而下法) 根据软件产品的总体特性来估计项目的总成本。然后,将总成本分解到各组成部分。 1.2.4Bottom-Up(自下而上法) 先分别估计软件项目每一组成部分的成本,再将它们综合起来得到整个项目的成本估计。 1.2.5EstimationbyAnalogy(类比法) 该方法通过与一个以上已完成项目进行类比来进行推理,把实际成本与一类似新项目的成本估计联系起来。类比法估计方法基于有代表性的经验,但对项目之间的类似程度有多大缺乏量化的 数值,并且在没有类似历史项目的情况下无法使用。 1.2.6PricetoWinEstimation(成功代价法) 这里,成本估计等同于被认为是工作成功所必要的代价(或者是新产品首次出现在市场上所必须的进度安排等等)。成功代价法估计结果经常能帮助取得契约合同,但常常会导致实际结果大大超出限度。 1.3 风险管理过程框架 本文提出的基于风险因子分析的软件项目管理模型中关于风险管理相关活动符合业界风险管理过程框架定义。 Charette( 1989) [22]、 Boehm( 1991) [30]、HigueraandHaimes( 1996) [31]提出的风险管理框架如表 1-1 所示。 1.3.1Charette 风险管理框架 在 Charette 风险管理框架中,风 险分析和风险管理各由三个可以重叠的过程组成。风险分析包括风险标识、风险估计和风险评估三个过程:风险标识是试图系统化地确定对项目计划的威胁,并将识别的风险分类。 风险估计从两个方面评价每一条已识别的风险 —— 风险发生的可能性以及风险发生后所产生的后果。 风险评估就是进一步审查在风险估计阶段所做的估计的精确度,试图为所发现的风险排出优先次序,并开始考虑如何控制和 /或避免可能发生的风险。 风险管理包括风险计划、风险控制和风险监控: 风险计划就是确定对项目中可能遇到风险的措施,并形成明确的计划。 风险控制就是根据既定的风险计划实施具体的活动。 风险监控就是在针对风险的措施落实后,观察其效果是否与计划的一致,这常常通过监控某些指标来实现,这些指标可以提供风险是否正在变高或变低的指示。风险监控提供了风险计划改进的机会。 1.3.2Boehm 风险管理框架 Boehm 的风险管理方法包括两个主要步骤,每一步又各自包含三个小步骤。第一个主要步骤,即风险评估,包括风险识别、风险分析和风险优先级分配: 风险识别产生特定项目详细风险的列表,这些风险可能对一个项目的成功起阻碍作用。 风险分析评估每一 条已识别风险的损失的概率和损失的大小,并评估风险互相作用时产生的综合风险。 风险优先级分配对已识别和分析过的风险进行排序。 第二个主要步骤是风险控制,包括风险管理计划、风险解决和风险监控。 风险管理计划有助于准备确定各种风险应对方式(如风险转移、风险规避、风险降低等),包括单个风险项计划之间的协调和与总体项目计划之间的协调。 风险解决,就是采用某种措施,使风险项得到消除或者由此得到了解决(比如通过降低要求来规避风险)。风险监控,跟踪项目风险的状态,并在适当的时候采取纠正措施。 1.3.3SEI 的风险管理框架 SEI 的 Higuera 与 Haimes 提出的持续风险管理框架( CRM)包括风险识别,风险分析、风险计划、风险跟踪、风险控制和风险沟通。其中风险识别、分析、计划、跟踪、控制等活动以环型的方式组织,表明其持续的特征。另外, SEI 将风险沟通置于模型的中心位置。这是因为,如何没有有效的风险沟通,任何一种风险管理方法都是不可行的。除了该模型中标识出的几大风险活动之间需要互相沟通,还有其他层次的风险沟通需要考虑,如项目与组织之间,开发人员与客户或最终用户之间。正是由于风险沟通的普遍性, SEI 将风 险沟通置于模型的中心位置,而不是之外,或仅仅是其他风险活动的一种补充。 1.4 常用的风险识别和风险评估方法 1.4.1 风险识别 方法 头脑风暴法 头脑风暴法是团队通过本能地、不加判断地汇集一些想法,产生新的主意,从而找出解决某一特定问题的方案。建立一份综合风险清单的时候可能用到这一方法。 Delphi 方法 Delphi 方法是从一组专家中得到一致的意见,来预测未来的发展。它是一种以互相独立的输入为基础,对未来事件进行预测的系统化、交互式程序。 Delphi 方法重复使用几个回合的提问,包括来自前几轮的反馈,从而发挥团组输入的优点,同时又可以避免面对面商议中可能出现的偏见效应。如果达不成一致的意见,组织者需要确定是否过程有问 题。 访谈 访谈是通过面对面或电话讨论的方式,收集信息、寻求事实的一种技术,访谈也可以通过电子邮件和即时信息进行。与那些具有类似项目经历的人们进行面谈,是识别可能风险的重要工具。例如,如果一个新项目用到一种特殊类型的硬件和软件,那么近来使用过这种硬件或软件经验的人,可能会描述出他们在先前项目中所遇到的问题。 检查表 当检查表用来进行风险识别时,将项目可能发生的许多潜在风险列于一个表上,供识别人员进行检查核对,用来判别某项目是否存在表中所列或类似的风险。检查表中所列的内容都是历史上类似项目曾发 生过的风险,是项目风险管理的结晶,对软件项目有开阔思路、启发联想、抛砖引玉的作用。此外,也可以通过使用StandishGroup, SEI 或其他组织开发的检查表,来帮助识别项目的风险。 流程图流程图是一种风险识别的常用工具。借助于流程图可以帮助项目风险识别人员去分析和了解项目风险所处的具体项目环节、项目各个环节之间存在的风险以及项目风险的起因和影响。 1.4.2 风险评估方法 概率 /影响图 概率 /影响图是风险定性分析的方法。概率表示风险发生的可能性大小,而结果表示风险发生后所带来影响的程度。使用 风险暴露值 =发生概率 *结果影响来评价风险。 专家判断法 专家判断法是依赖专家们的直觉和以往的经验来代替或补充数学分析技术,专家可以使用或不使用较为复杂的技术 ,例如,无须计算风险暴露值,直接把风险定为高、中和低三种。 决策树 决策树是一种图形化的风险量化分析方法,可以帮助在未来结果不确定的情况下,选择最好的行动路径。 模拟 模拟是指用系统的模型或表示法来分析系统的预期行为或绩效,也是一种量化分析方法。大多数模拟都以某种形式的蒙特卡罗( MonteCarlo)分析为基础。蒙特卡罗分析通过多次模拟一个模型的结果,从而提供计算结果的统计分布。 蒙特卡罗法的基本原理 假定函数 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、制定项目进度计划 本文关注于软件企业软件开发项目的风险管理和项目进度计划制定,对于个人软件开发、维护项目等不涉及,软件项目风险对产品质量的影响也不涉及。 第二章软件项目的风险因 子 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 人时”。 根据风险的定义,风险是指“可能的损失”,因此,风险对软件项目的影响也主要体现在这四个纬度上,这四个纬度上的任何偏差或不确定性都是软件项目组要关心和控制的。特别地,进度纬度上的偏差和不确定性是所有四个纬度中最需要重点关注的。 2.3 风险的量化定 义 通常“风险”被量化地定义为发生潜在损失的可能性与潜在损失两者的乘积。 Boehm 将之称为“风险暴露”( RiskExposure)。风险暴露可以通过下面的关系式表现出来: 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 月。” 之所以找来一名顾问,正是因为你不敢肯定项目什么时候能完成。但看起来这位顾问先生自己也多少有些不确定。你的不确定(完全盲目)与他的不确定之间的区别在于:他给不确定性画定了明确的界限。 可以用一幅图来表示这位顾问的估计。既然他谈到的都是可能性的问题,这幅图也就借助“某一日期交付的概率”来展现不确定性。用纵轴表示可能性,横轴表示时间,如图 2-1 所示: 这幅描述不确定性的图形,就叫不确定性图。当不确定的东西与项目的成败休戚相关时,描述它的不确定性图就被称为风险图。 风险图最重要的特征有: 曲线下方的区域表示“在某一特定日期之前完工的”总的可能性。也就是说,如果有 1/3 的区域位于 4 月 1 日的左侧,就表示在4 月 1 日当天或之前完成项目的可能性为 33%。 整条曲线下方区域的面积为1.0,这就是顾问对项目的整体评估:项目一定会在明年 1 月 1 日至 12 月 31 日之间的某个时间完成。 上述风险图还可以等价地表示为另一种形式 —— 累积风险图,如图 2-2 所示。累积风险图表示了在某一日期或之前完成项目的累积可能性,相应地,表示某一日期完成相对可能性的风险图则称为增量风险图。基于风险图的观点, Demarco 与 Lister 将风险量化地定义为: 风险是描绘所有可能结果及由其引发的相关后果的加权图。 Demarco 与 Lister 给出了风险图和风险的定义,也指出了风险图必须基于历史项目数据得到。但对于如何有效得到这些风险图,并没有给出方法上的指导。本文试图从影响项目的关键风险因子研究出发,借助风险图的方法,量化地研究风险因子对项目进度的影响。 2.4 风险因子的定义 何文炯( 1999)在他的《风险管理》 [17]一书中对风险因子作了比较完整的定义。他认为风险因子是促使或引起风险事件发生的条件,以及风险事件发生时,致使损失增加、扩大的条件。风险因子是风险事件发生的潜在因素,是造成损失的间接的和内在的原因。关于风险因子的称呼有多种,有叫“风险因素”,有叫“风险源”的,英文叫“ Hazard”。本文统一称为“风险因子”。软件项目开发过程中的需求膨胀,对项目进度延迟而言,就是风险因子。 根据其性质,通常把风险因子分成实质风险因子( PhysicalHazard)、道德风险因子( MoralHazard)和心理风险因子( MoraleHazard)三种。 实质风险因子是指增加风险事件发生机会或扩大损失严重程度的物质条件,它是一种有形的风险因子。例如,缺乏合适的开发、测试环境对于项目进度的危害,关键技术不熟悉对于生产率降低等,都是实质性风险因子。 道德风险因子是指与人的不正当社会行为相联系的一种无形的风险因子。常常表现为由于恶意行为或不良企图,故意促使风险事件发生或损失扩大,例如偷工减料引起质量事故就属于道德风险因子。 心理风险因子也是一种无形的风险因子,但与道德风险因子不同。它是指由 于人的主观上疏忽或过失,导致增加风险事件发生机会或扩大损失程度。例如,由于设计方案的错误选择导致软件项目失败,项目组成员的非正常退出而没有进行必要的分析和采取适当的措施等等,都属于心理风险因子。 风险因子、风险事件以及危害之间的关系可以通过图 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 所示。 第三章主要风险因子的潜在影响分析 3.1 实际软件项目的风险因子标识 本文所研究的项目来自国内一家著名通讯软件公司,该公司的业务主要聚焦于数据通讯产品、业务与软件产品、网管软件产品等领域,目前有软件开发人员 600 名左右。本文选择分析的软件项目共有 207 个,包括了该公司近 3 年来的所有软件项目。 所选择的软件项目大多数使用了 V 模型的软件开发过程,其他的如增量开发过程、原型演进开发过程等也有应用,对规模很小的项目则大多数使用了编码 -测试的简化过程。 软件项目的开发周期长度大多集中在 4~12 个月,最长的为 16个月,最短的为 1 个月。 软件项目运作过程中的峰值人力投入根据项目的不同而有变化,最少投入在 2 个人,最多投入在 48 个人。 根据业务领域的不同,各软件项目组在设计实现时,使用了不同的编程语言。 在这 207 个软件项目中,产品规模(以开发工作量人月计算)也分布广泛。 项目经理们的项目管理经验也各不相同,有的仅有 1 年管理经验,而有的管理经验则在 10 年以上。 3.1.1 实际软件项目风险因子标识方法 1、如果所选软件项目存在风险管理计划,则提取出风险管理计划中标识的所有风险; 2、对提取出的风险,针对其风险描述进行分析,并归纳出相应的风险因子; 3、如果所选软件项目存在项目结束总结报告,则提取出总结报告中所反映的影响项目质量、进度、工作量的所有项目问题;如果某问题已经在该项目的风险管理计划中 提及,则去除该问题,以避免重复统计; 4、对所提取出的项目问题,针对问题描述进行分析,并归纳出相应的风险因子(“今天的问题就是明天的风险”); 5、综合风险管理计划和项目结束总结报告中出现的风险因子,并统计这些风险因子出现的数目。 在所选择的 207 个软件项目中,有 192 份风险管理计划。该公司允许时间跨度在 2 个月以内的小型软件项目可以不做单独的风险管理计划,但有些小型项目做了单独的风险管理计划。所选择的每一个软件项目都有项目结束总结报告。 从风险管理计划和项目结束总结报告中提取出的风险因子及其数目如 图 3-7 所示,从中 图 3-7 实际软件项目统计风险因子分布图 在实施问卷调查之前,为了帮助项目经理理解风险因子及其潜在的影响,特别准备了这些风险因子的原因 —— 结果图形。原因 —— 结果图形是 Eden 和 Ackerman 在 1992 年提出的一种图形化描述系统原因与结果关系的建模方法,使用原因 —— 结果图形可以清楚地表示风险因子的潜在影响。 原因 —— 结果图形由标签、标签之间的连结线段组成,这些线段带有箭头用以表示方向,在箭头的旁边还带有正( +)、负( -)号。每一个标签表示一个原因或者一个结果,当箭头指向某个标签时,则该标签表示一个结果,连接线段的另一端标签则表示一个原因,因 此,原因 —— 结果图形中的一个标签既可能是一个结果,同时又可能是另一个结果的原因。箭头旁边的符号则表示结果变化的方向与原因的变化方向是否一致,当符号为正号时,则表示随着原因增长时,结果也相应地增长;当符号为负号时,则表示当原因增长时,结果却相应地减少。图 3-8 是原因 —— 结果图形的一个简单例子,当项目开发过程中需求持续膨胀时,设计返工的工作量随之增加。 图 3-9 则表示了原因 —— 结果图形的另外两种特征,符号为负号的路径以及增强正反馈路径。过度的进度压力在短期内可以提高生产率,但同时也增加了员工的疲惫程度;疲惫程度加大后,导致生产率下降。正反馈路径出现在:由于疲惫程度加大,引发更多的缺陷,造成更多的返工,进而使得进度压力更大。 6 种主要风险因子的原因 —— 结果图形分别如下: 需求膨胀风险因子 当需求新增或者需求发生变更时,很可能带来新的工作任务和活动,工作产品规模随之变大;同样地,需求膨胀也会导致对原有需求的设计返工。无论是产品规模变大,还是设计返工增加,都将对项目的进度造成影响。工作量估计不准确风险因子 工作量估计不准确,往往是指工作量估计偏少, 这是由于人们在进行软件项目估计时,倾向于忽视某些“可能需要做”的工作,而不是把“可能不需要做”的工作也计算在内。当然也有项目组工作量估计偏多,偏多的结果之一就是项目组人力资源得不到充分发挥。当工作量估计偏少时,项目人力资源投入可能不足,或者项目计划完成时间点提前,这两点最终会导致项目组成员感受到过度的进度压力,从而导致项目延迟更多。 项目组成员流失风险因子 项目组成员流失或者投入不稳定,使得项目组缺乏有经验的人员,并在可能的情况下增加新人到项目组。由于缺乏有经验的人,将导致缺陷引入增加,缺陷也不能尽 早发现,项目组的士气也有一定程度的下降,所有这些将会导致生产率的下降,最终引发进度延迟问题。增加新人到项目组,由于存在接手时间,并增加了项目组沟通的工作量,进度也会有延迟。 对项目平台 /环境 /方法不熟悉风险因子 对项目平台 /环境 /方法不熟悉,将导致更多的正式培训或者边干边自学,也会导致更多的项目沟通时间,错误引入也会因为对平台 /环境 /方法的不熟悉而增加,所有这些将会降低项目组的生产率,从而使得进度延迟。 缺乏关键人员风险因子 项目组缺乏关键人员,将导致不具备相关技能的人员上岗。由于不具备技能,培训工作量上升,缺陷引入上升,而缺陷检测水平下降,所有这些,将导致生产率下降,从而使得进度延迟。 缺乏高层管理者的承诺和支持风险因子 项目组缺乏高级管理者的支持和承诺,一般存在人为压缩进度、人力