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

基于风险因子分析的软件项目管理模型基于风险因子分析的软件项目管理模型 A Software Project Management Model Based on Risk Factor Analysis 张宏书张宏书 指导老师 金志权 邵栋指导老师 金志权 邵栋 二零零四年四月二零零四年四月 南京大学硕士论文 2 摘摘要要 软件项目开发过程中存在着大量不确定事件 这给项目的成功带来了风险 能否在规 定的时间内交付软件产品 与项目进度计划是否合理 项目风险管理活动是否有效有很大 的关系 这需要综合考虑软件项目进度计划与软件项目风险管理计划 提供工具用以标识 分析和管理软件项目风险 并在此基础上获得合理的软件项目进度计划 本文提出了基于风险因子分析的软件项目管理模型 本文通过对文献著作的研究和某 通讯公司软件项目的实际分析 标识出影响软件项目成功的 20 个风险因子 并根据其出现 的比例 选择 6 个主要风险因子进行进一步地量化分析 分析它们各自对软件项目进度的 影响 并使用蒙特卡罗模拟方法 模拟出所选择的风险因子对软件项目进度的总体影响 该影响以风险图的方式给出 同时 利用模型中识别出的主要风险因子 标识软件项目风 险 综合考虑风险因子的潜在影响和项目进度的要求 制定出软件项目风险管理计划和合 理的软件项目进度计划 本文实现了基于风险因子分析的软件项目管理模型 并对模型本身进行了正确性验证 也在软件项目组进行了符合项目经理需要的确认 结果显示 该模型能够帮助项目经理制 定风险管理计划和合理的进度计划 关键词 关键词 风险因子 模型 风险管理计划 进度计划 南京大学硕士论文 3 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 南京大学硕士论文 4 目录目录 第一章 绪论 1 1 1本文研究的背景及问题 1 1 2软件估计常用方法 3 1 3风险管理过程框架 5 1 4常用的风险识别和风险评估方法 7 1 5本文的工作 10 第二章 软件项目的风险因子 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 南京大学硕士论文 1 第一章第一章 绪论绪论 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 的企业经历过失控项目 南京大学硕士论文 2 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 一书中提出了著名的布鲁 克斯规则 不难发现 软件项目风险管理的研究与项目进度计划的研究是有交集的 在考虑项目 风险时 进度风险通常是考虑的重点 在制定项目进度计划时 要考虑达到进度目标可能 遇到的风险 但是 将软件项目风险管理与项目进度计划有机地结合起来的综合研究还鲜 见于文献资料 本文提出一种基于风险因子分析的软件项目管理模型 能方便地帮助软件 南京大学硕士论文 3 项目标识出主要的风险因子 并量化分析风险因子对项目进度的影响 最终给出合理的项 目交付进度计划 1 2 软件估计常用方法软件估计常用方法 软件项目管理过程总是从项目计划开始 在项目可以开始前 管理者和软件小组必须 估计将要完成的工作 所需要的资源以及从开始到完成所需要的时间 软件估计需要经验 以前项目的有用信息 以及当仅存在定性的数据时进行定量估计的勇气 软件估计是一项预测未来的工作 天生具有某种程度的不确定性 Kemerer 描述了由 于估计不准而给项目造成的经济 质量和组织影响 为了解决这些估计不准的问题 软件 业界对估计做了大量的研究 提出了许多软件估计方法和工具 由于软件进度估计总是依 赖于软件工作量估计和可以投入的软件人力资源 在人力资源投入策略确定后 软件开发 工作量与软件项目进度的对应关系就确定了 所以本文仅仅介绍常用的软件工作量估计方 法 1 2 1 算法模型估计方法算法模型估计方法 算法模型估计方法又称参数估计方法 它使用特定的数学公式进行软件工作量估计 该公式是经过一定的理论推导或者通过历史项目经验数据总结而得到的 参数估计方法的 输入通常有软件代码行规模 软件功能点数 以及设定的工作量驱动因子 参数估计方法 的准确度可以通过校正因子处理而得到提高 参数估计方法的最大优点是能够重复进行估计 输入参数可以方便地进行调整 所使 用的数学公式也可以进行优化 其最大缺点是不能处理意外情况 参数估计方法的例子有 COCOMO 结构成本模型 结构成本模型 COCOMO 方法是 Boehm 1981 年在其著名的 软件工程经济学 32 中提出的一种软 件估计方法 它实际上是一个包含三个详细程度 Basic Intermediate Advanced 逐渐增 加的层次模型结构 COCOMO 方法又根据待开发软件的特点 分为组织式 半分离式和 嵌入式三种模式 COCOMO 估计模型具有以下形式 EAFKDSIaMM b d MMcTDEV 式中 MM 是以人月为单位的工作量 TDEV 是以月表示的项目持续时间 EAF 是成 本调整因子 对于 Basic 模型 EAF 1 a b c d 的取值与模式有关 南京大学硕士论文 4 一个简单的例子 一个简单的例子 一个飞行器控制系统 其代码规模为 319KDSI 属于嵌入式模式 可靠性要求非常高 故 a 取 1 40 计算结果如下 工作量 Effort MM5093 319 6 3 40 1 20 1 进度 Schedule Months 4 38 5093 5 2 32 0 平均人力资源投入 133 4 38 5093 MonthsMM SLIM 软件方程式模型 软件方程式模型 SLIM 方法是在 20 世纪 70 年代后期由 QSM 组织的 Putnam 开发的 它是一个动态的 多变量模型 该模型假设在软件开发项目整个生命周期中存在一个特定的工作量分布曲线 该模型是从 4000 多个当代软件项目中收集的生产率数据中导出的 基于这些数据 估计模 型具有以下形式 1 43333 0 tPBLOCE 式中 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 5 协调人召集小组会议 讨论较大的估计差异 6 专家复查估计 总结 并提交另一个匿名估计 7 重复 4 6 直到达到一个可以接受范围内的估计 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 典型的风险管理框架 CharetteCharetteBoehmBoehmHigueraHiguera andand HaimesHaimes 风险分析与管理 风险分析 风险标识 风险估计 风险评估 风险管理 风险计划 风险管理 风险评估 风险标识 风险分析 风险优先级分配 风险控制 风险管理计划 SEI 风险管理 风险标识 风险分析 风险计划 风险跟踪 风险控制 南京大学硕士论文 6 风险控制 风险监控 风险解决 风险监控 风险沟通 1 3 1 Charette 风险管理框架风险管理框架 在 Charette 风险管理框架中 风险分析和风险管理各由三个可以重叠的过程组成 风 险分析包括风险标识 风险估计和风险评估三个过程 风险标识是试图系统化地确定对项目计划的威胁 并将识别的风险分类 风险估计从两个方面评价每一条已识别的风险 风险发生的可能性以及风险发生后 所产生的后果 风险评估就是进一步审查在风险估计阶段所做的估计的精确度 试图为所发现的风险 排出优先次序 并开始考虑如何控制和 或避免可能发生的风险 风险管理包括风险计划 风险控制和风险监控 风险计划就是确定对项目中可能遇到风险的措施 并形成明确的计划 风险控制就是根据既定的风险计划实施具体的活动 风险监控就是在针对风险的措施落实后 观察其效果是否与计划的一致 这常常通过 监控某些指标来实现 这些指标可以提供风险是否正在变高或变低的指示 风险监控提供 了风险计划改进的机会 1 3 2 Boehm 风险管理框架风险管理框架 Boehm 的风险管理方法包括两个主要步骤 每一步又各自包含三个小步骤 第一个主 要步骤 即风险评估 包括风险识别 风险分析和风险优先级分配 风险识别产生特定项目详细风险的列表 这些风险可能对一个项目的成功起阻碍作用 风险分析评估每一条已识别风险的损失的概率和损失的大小 并评估风险互相作用时 产生的综合风险 风险优先级分配对已识别和分析过的风险进行排序 第二个主要步骤是风险控制 包括风险管理计划 风险解决和风险监控 风险管理计划有助于准备确定各种风险应对方式 如风险转移 风险规避 风险降低 等 包括单个风险项计划之间的协调和与总体项目计划之间的协调 风险解决 就是采用某种措施 使风险项得到消除或者由此得到了解决 比如通过降 低要求来规避风险 风险监控 跟踪项目风险的状态 并在适当的时候采取纠正措施 南京大学硕士论文 7 1 3 3 SEI1的风险管理框架的风险管理框架 SEI 的 Higuera 与 Haimes 提出的持续风险管理框架 CRM 包括风险识别 风险分析 风险计划 风险跟踪 风险控制和风险沟通 其中风险识别 分析 计划 跟踪 控制等 活动以环型的方式组织 表明其持续的特征 另外 SEI 将风险沟通置于模型的中心位置 这是因为 如何没有有效的风险沟通 任何一种风险管理方法都是不可行的 除了该模型 中标识出的几大风险活动之间需要互相沟通 还有其他层次的风险沟通需要考虑 如项目 与组织之间 开发人员与客户或最终用户之间 正是由于风险沟通的普遍性 SEI 将风险 沟通置于模型的中心位置 而不是之外 或仅仅是其他风险活动的一种补充 图 1 1 SEI 的持续风险管理模型图示 1 4 常用的风险识别和风险评估方法常用的风险识别和风险评估方法 1 4 1 风险识别方法风险识别方法 头脑风暴法头脑风暴法 头脑风暴法是团队通过本能地 不加判断地汇集一些想法 产生新的主意 从而找出 解决某一特定问题的方案 建立一份综合风险清单的时候可能用到这一方法 Delphi 方法方法 Delphi 方法是从一组专家中得到一致的意见 来预测未来的发展 它是一种以互相独 立的输入为基础 对未来事件进行预测的系统化 交互式程序 Delphi 方法重复使用几个 回合的提问 包括来自前几轮的反馈 从而发挥团组输入的优点 同时又可以避免面对面 商议中可能出现的偏见效应 如果达不成一致的意见 组织者需要确定是否过程有问题 1 SEI Software Engineering Institute 美国 Carnegie Mellon 大学的软件工程研究所 发布过系列能力成熟度模型 SW CMM SE CMM P CMM CMMI 等 南京大学硕士论文 8 访谈访谈 访谈是通过面对面或电话讨论的方式 收集信息 寻求事实的一种技术 访谈也可以 通过电子邮件和即时信息进行 与那些具有类似项目经历的人们进行面谈 是识别可能风 险的重要工具 例如 如果一个新项目用到一种特殊类型的硬件和软件 那么近来使用过 这种硬件或软件经验的人 可能会描述出他们在先前项目中所遇到的问题 检查表检查表 当检查表用来进行风险识别时 将项目可能发生的许多潜在风险列于一个表上 供识 别人员进行检查核对 用来判别某项目是否存在表中所列或类似的风险 检查表中所列的 内容都是历史上类似项目曾发生过的风险 是项目风险管理的结晶 对软件项目有开阔思 路 启发联想 抛砖引玉的作用 此外 也可以通过使用 Standish Group SEI 或其他组织 开发的检查表 来帮助识别项目的风险 流程图流程图 流程图是一种风险识别的常用工具 借助于流程图可以帮助项目风险识别人员去分析 和了解项目风险所处的具体项目环节 项目各个环节之间存在的风险以及项目风险的起因 和影响 1 4 2 风险评估方法风险评估方法 概率概率 影响图影响图 概率 影响图是风险定性分析的方法 概率表示风险发生的可能性大小 而结果表示风 险发生后所带来影响的程度 使用风险暴露值 发生概率 结果影响来评价风险 图 1 2 风险概率 影响示意图 专家判断法专家判断法 高风险 中风险 低风险 1 0 7 0 3 0 30 71 风险概率 影响严重程度 0 南京大学硕士论文 9 专家判断法是依赖专家们的直觉和以往的经验来代替或补充数学分析技术 专家可以 使用或不使用较为复杂的技术 例如 无须计算风险暴露值 直接把风险定为高 中和低 三种 决策树决策树 决策树是一种图形化的风险量化分析方法 可以帮助在未来结果不确定的情况下 选 择最好的行动路径 模拟模拟 模拟是指用系统的模型或表示法来分析系统的预期行为或绩效 也是一种量化分析方 法 大多数模拟都以某种形式的蒙特卡罗 Monte Carlo 分析为基础 蒙特卡罗分析通过 多次模拟一个模型的结果 从而提供计算结果的统计分布 图 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 的概率分布及其数字特征 P 0 3L 0 P 0 1 P 0 6 发现CE 未发现CE 没有CE L 2000万 L 0 P 0 36L 50万 P 0 04 P 0 6 发现CE 未发现CE 没有CE L 2050万 L 50万 按 IV V 方案 不按 IV V 方案 风险暴露 18万 82万 30万 0 200万 0 总暴露 130万 200万 南京大学硕士论文 10 1 5 本文的工作本文的工作 本文通过对文献著作的研究和某通讯公司软件项目的实际分析 标识出影响软件项目 正常运作的 20 个风险因子 并根据其出现的比例 选择 6 个风险因子进行进一步的量化分 析 分析风险因子对项目进度的影响程度 并使用 Monte Carlo 方法 建立项目进度计划 模型 该模型的主要功能有 1 帮助软件项目标识项目风险 2 制定风险管理计划 3 制定项目进度计划 本文关注于软件企业软件开发项目的风险管理和项目进度计划制定 对于个人软件开 发 维护项目等不涉及 软件项目风险对产品质量的影响也不涉及 南京大学硕士论文 11 第二章第二章 软件项目的风险因子软件项目的风险因子 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 对于成本 通常使用 南京大学硕士论文 12 人力成本或开发工时来表示 如 50000 3000 人时 根据风险的定义 风险是指 可能的损失 因此 风险对软件项目的影响也主要体现 在这四个纬度上 这四个纬度上的任何偏差或不确定性都是软件项目组要关心和控制的 特别地 进度纬度上的偏差和不确定性是所有四个纬度中最需要重点关注的 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 南京大学硕士论文 13 月初 而且这个日期也不能打包票 你最好不要承诺在5月1日前的任何时间交付 至少应该承诺在5月 以后 这样你成功的机会大概有一半 如果你想一个几乎不可能失败的日期 那大概会是明年的12月 之所以找来一名顾问 正是因为你不敢肯定项目什么时候能完成 但看起来这位顾问 先生自己也多少有些不确定 你的不确定 完全盲目 与他的不确定之间的区别在于 他 给不确定性画定了明确的界限 可以用一幅图来表示这位顾问的估计 既然他谈到的都是可能性的问题 这幅图也就 借助 某一日期交付的概率 来展现不确定性 用纵轴表示可能性 横轴表示时间 如图 2 1 所示 图 2 1 项目交付日期不确定性图 这幅描述不确定性的图形 就叫不确定性图 当不确定的东西与项目的成败休戚相关 时 描述它的不确定性图就被称为风险图 风险图最重要的特征有 曲线下方的区域表示 在某一特定日期之前完工的 总的可能性 也就是说 如果有 1 3 的区域位于 4 月 1 日的左侧 就表示在 4 月 1 日当天或之前完成项目的可能性为 33 整条曲线下方区域的面积为 1 0 这就是顾问对项目的整体评估 项目一定会在明年 1 月 1 日至 12 月 31 日之间的某个时间完成 上述风险图还可以等价地表示为另一种形式 累积风险图 如图 2 2 所示 累积风 险图表示了在某一日期或之前完成项目的累积可能性 相应地 表示某一日期完成相对可 能性的风险图则称为增量风险图 基于风险图的观点 Demarco 与 Lister 将风险量化地定义为 风险是描绘所有可能结果及由其引发的相关后果的加权图 风险是描绘所有可能结果及由其引发的相关后果的加权图 南京大学硕士论文 14 图 2 2 累积风险图示意图 Demarco 与 Lister 给出了风险图和风险的定义 也指出了风险图必须基于历史项目数 据得到 但对于如何有效得到这些风险图 并没有给出方法上的指导 本文试图从影响项 目的关键风险因子研究出发 借助风险图的方法 量化地研究风险因子对项目进度的影响 2 4风险因子的定义风险因子的定义 何文炯 1999 在他的 风险管理 17 一书中对风险因子作了比较完整的定义 他 认为风险因子是促使或引起风险事件发生的条件 以及风险事件发生时 致使损失增加 扩大的条件 风险因子是风险事件发生的潜在因素 是造成损失的间接的和内在的原因 关于风险因子的称呼有多种 有叫 风险因素 有叫 风险源 的 英文叫 Hazard 本文统一称为 风险因子 软件项目开发过程中的需求膨胀 对项目进度延迟而言 就是 风险因子 根据其性质 通常把风险因子分成实质风险因子 Physical Hazard 道德风险因子 Moral Hazard 和心理风险因子 Morale Hazard 三种 实质风险因子是指增加风险事件发生机会或扩大损失严重程度的物质条件 它是一种 有形的风险因子 例如 缺乏合适的开发 测试环境对于项目进度的危害 关键技术不熟 悉对于生产率降低等 都是实质性风险因子 道德风险因子是指与人的不正当社会行为相联系的一种无形的风险因子 常常表现为 由于恶意行为或不良企图 故意促使风险事件发生或损失扩大 例如偷工减料引起质量事 1 南京大学硕士论文 15 故就属于道德风险因子 心理风险因子也是一种无形的风险因子 但与道德风险因子不同 它是指由于人的主 观上疏忽或过失 导致增加风险事件发生机会或扩大损失程度 例如 由于设计方案的错 误选择导致软件项目失败 项目组成员的非正常退出而没有进行必要的分析和采取适当的 措施等等 都属于心理风险因子 风险因子 风险事件以及危害之间的关系可以通过图 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 种 南京大学硕士论文 16 风险因子 并标识出了 10 种最严重的风险因子 如表 2 3 所示 表 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 取消项目 南京大学硕士论文 17 第三章第三章 主要风险因子的潜在影响分析主要风险因子的潜在影响分析 3 1实际软件项目的风险因子标识实际软件项目的风险因子标识 本文所研究的项目来自国内一家著名通讯软件公司 该公司的业务主要聚焦于数据通 讯产品 业务与软件产品 网管软件产品等领域 目前有软件开发人员 600 名左右 本文 选择分析的软件项目共有 207 个 包括了该公司近 3 年来的所有软件项目 所选择的软件项目大多数使用了 V 模型的软件开发过程 其他的如增量开发过程 原 型演进开发过程等也有应用 对规模很小的项目则大多数使用了编码 测试的简化过程 图 3 1 软件开发过程种类分布图 软件项目的开发周期长度大多集中在 4 12 个月 最长的为 16 个月 最短的为 1 个月 图 3 2 软件项目开发周期长度分布图 罿 南京大学硕士论文 18 软件项目运作过程中的峰值人力投入根据项目的不同而有变化 最少投入在 2 个人 最多投入在 48 个人 图 3 3 软件项目人力投入分布图 根据业务领域的不同 各软件项目组在设计实现时 使用了不同的编程语言 图 3 4 软件项目使用开发语言分布图 1 在这 207 个软件项目中 产品规模 以开发工作量人月计算 也分布广泛 1 SCE Service Construct Environment 业务生成环境 是基于特定平台的一种业务生成语言 5 縵 5 0 0 C 十 M 敄 灬 楨 E 兓 南京大学硕士论文 19 图 3 5 软件项目产品规模分布图 项目经理们的项目管理经验也各不相同 有的仅有 1 年管理经验 而有的管理经验则 在 10 年以上 图 3 6 项目经理管理年限分布图 3 1 1 实际软件项目风险因子标识方法实际软件项目风险因子标识方法 1 如果所选软件项目存在风险管理计划 则提取出风险管理计划中标识的所有风险 2 对提取出的风险 针对其风险描述进行分析 并归纳出相应的风险因子 3 如果所选软件项目存在项目结束总结报告 则提取出总结报告中所反映的影响项目 质量 进度 工作量的所有项目问题 如果某问题已经在该项目的风险管理计划中提及 则去除该问题 以避免重复统计 4 对所提取出的项目问题 针对问题描述进行分析 并归纳出相应的风险因子 今 天的问题就是明天的风险 5 综合风险管理计划和项目结束总结报告中出现的风险因子 并统计这些风险因子出 现的数目 在所选择的 207 个软件项目中 有 192 份风险管理计划 该公司允许时间跨度在 2 个 月以内的小型软件项目可以不做单独的风险管理计划 但有些小型项目做了单独的风险管 縱 2 縲 4 縴 6 縶 8 縸 0 縱 縴 搥 南京大学硕士论文 20 理计划 所选择的每一个软件项目都有项目结束总结报告 从风险管理计划和项目结束总结报告中提取出的风险因子及其数目如图 3 7 所示 从 中标识出的 20 种软件项目风险因子如表 3 1 所示 3 2主要风险因子原因结果图主要风险因子原因结果图 为了进一步研究这些风险因子对项目进度的影响 又从中选择了 6 个风险因子 通过 问卷调查的方式 量化分析它们对项目进度的潜在影响 之所以选择这 6 个风险因子 主 要是因为它们在项目风险因子标识过程中出现的比例较高 以及它们对项目进度的影响较 大 这 6 个风险因子如表 3 2 所示 图 3 7 实际软件项目统计风险因子分布图 表 3 1 实际软件项目统计之 20 种风险因子列表 序号序号风险因子风险因子 1 需求膨胀 2 缺乏关键人员 3 依赖几个关键人员 4 项目经理经验不足 5 项目成员流失或投入不稳定 6 项目成员士气低下 7 项目大 复杂 8 不正确的度量 9 缺乏高层管理的承诺 10 缺乏量化的历史数据 11 对项目平台 环境 方法不熟悉 0 南京大学硕士论文 21 12 工作量估计不准确 13 过度的进度压力 14 配置管理不充分 15 不熟悉产品使用环境 操作方法 16 过度依赖单个开发改进 17 过多的复杂外部接口 18 不成熟的技术 19 低生产率 20 关键资源不足 表 3 2 6 种主要风险因子及其说明 序号序号风险因子风险因子说明说明 1 需求膨胀在已经确认的需求基线基础上 增加了新的需求 或者删 除了已有的需求 或者是原有需求发生了变更 2 工作量估计不准确由于缺乏历史数据 或者是没有使用有效的估计方法 导 致工作量估计值与实际值不一致 3 项目组成员流失项目组成员在其承诺的任务完成之前离开项目组 或者是 其实际投入不能满足承诺的目标 4 对项目平台 环境 方法 不熟悉 对项目开发所依赖的平台 环境或者所使用的开发方法不熟 悉 5 缺乏关键人员项目组缺少满足其特定要求的人员 如缺乏有经验的需求 分析人员 测试人员等 6 缺乏高层管理的支持和 承诺 高级管理者对项目不支持或保持中立状态 表现为不能给 项目足够的资源 在项目出现困难时 不能帮助项目度过 难关 在实施问卷调查之前 为了帮助项目经理理解风险因子及其潜在的影响 特别准备了 这些风险因子的原因 结果图