软件项目管理(张聚礼)章 (8)
合集下载
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
第8章 软件项目风险管理
2. 软件项目风险管理模型 针对软件项目中的风险管理问题,不少专家、组织提出了 自己的风险管理模型。主要的风险管理模型有:Boehm模型、 CRM模型、SERIM模型和CMMI模型。 1) Barry Boehm模型 从风险管理步骤看,Boehm倾向于传统的项目风险管理理 论,它认为风险管理包括风险评估及风险控制两方面,风险评 估包括风险识别、风险分析、风险优先级三项活动,主要在项 目早期检查和识别项目潜在的风险,也可能发生在项目实施的 其他任何阶段;风险控制包括制定风险管理计划、风险化解和 风险监控三项活动,如图8.1所示。
第8章 软件项目风险管理
6) 多样性 因为项目和项目环境的复杂化和规模化,在一个项目中存 在着许多不同种类的风险,例如技术风险、经济风险、社会风 险、组织风险等。而且这些风险之间存在着交错复杂的内在联 系,它们相互影响,因此必须对项目风险进行系统识别和综合 考虑。
第8章 软件项目风险管理
8.1.2 软件项目风险来源及分类 1. 软件项目的风险来源 斯坦迪什集团(Standish Group)对“混沌”(Chaos)进行
了一项后续研究,该项研究被称作“未完成的航 行”(Unfinished Voyages)。在该项研究中60位信息技术专业 人员被召集在一起,详细讨论如何评价某一软件项目是否成功。 他们认为,软件项目是否成功有诸如“用户参与”、“高层管 理者的支持”等十项共同的判断标准。这些软件项目成功的判 断标准也是它们共同的风险来源,如表8-1所示。
第8章 软件项目风险管理
4) 相对性 一方面,人们对于风险都有一定的承受能力,这种能力往 往因活动、人和时间而异。一般而言人们的风险承受能力受到 收益的大小、投入的大小、拥有财富状况等因素的影响,例如 收益的大小,收益总是与损失的可能性相伴随,损失的可能性 和数额越大,人们希望为弥补损失而得到的收益也就越大;反 之,收益越大,人们愿意承担的风险也越大。另一方面,风险 和任何事物一样也是矛盾的统一体,一定的条件会引起风险的 变化。风险性质、风险后果等都存在可变性,例如随着科学技 术的发展,某些风险可以较为准确地预测和估计(例如,天气 预报等)。
3. 风险的特征 风险具有客观性、突发性、多变性、相对性、无形性、多 样性等特征。
第8章 软件项目风险管理
1) 客观性 风险的存在取决于决定风险各种因素的存在。也就是说: 不管人们是否意识到风险,只要决定风险的各种因素出现了, 风险就会出现,它是不以人们的主观意志为转移的。因此要减 少和避免风险,就必须及时发现可能导致风险的因素,并进行 有效管理。从另一方面看,在项目活动过程中产生风险的因素 又是多种多样的,要完全消除风险也是不可能的,很多因素本 身就是不确定的,例如:技术、环境、人员等。因此风险总是 客观存在于项目活动的各个方面。风险的客观性要求人们应充 分认识风险、重视风险,采取相应的管理措施,以尽可能降低 或化解风险。
第8章 软件项目风险管理
表8-2 软件项目中的36项风险因素
风险类别 需求定义风险 项目设计分析 项目实施风险 开发人员风险 产品外包风险 系统用户风险 过程管理风险
风险因素
(1) 需求定义不准确 (2) 成为项目基准以后需求还在继续变化 (3) 追加需求 (4) 需要更长的需求定义时间 (5) 缺少有效的需求变更管理
第8章 软件项目风险管理
5) 无形性 风险不像一般的物质实体,能够非常确切地描绘和刻画出 来。因此,在分析风险中应用系统理论、概率、弹性、模糊等 概念和方法进行界定或估计、测定,从定性和定量两个方面进 行综合分析。虽然风险的无形性增加了人们认识和把握风险的 难度,但只要掌握了风险管理的科学理论、系统分析产生风险 的内外因素、并恰当地运用技术方法和工具手段,就可以有效 地管理风险。
第8章 软件项目风险管理
风险评估 风险识别
风险分析 风险优先级
风险控制 风险管理计划
风险化解 风险监控
图8.1 Boehm模型的风险管理步骤(Boehm认为风险管理包括风险评估 及
风险控制两方面,风险评估包括风险识别、风险分析、风险优先级 三项活动,风险控制包括制定风险管理计划、风险化解和风险监控三
第8章 软件项目风险管理
软件风险管理的目标是:控制和处理项目风险,防止和减 少损失,减轻或消除风险的不利影响,以最低成本取得对项目 保障的满意结果,保障项目的顺利进行。
软件项目风险管理的基础是调查研究,调查和收集资料, 必要时还要进行实验或试验。只有认真地研究项目本身和环境 以及两者之间的关系、相互影响和相互作用,才能识别项目面 临的风险。
第8章 软件项目风险管理
软件项目风险按照可预测性,将其划分为已知风险、可预 测风险和不可预测风险。
根据软件项目风险按照能否管理,可将其划分为可管理风 险和不可管理风险。 8.1.3 软件项目风险管理概述
1. 软件项目风险管理的概念 软件项目风险管理是指通过风险识别、风险界定和风险评 价去认识风险,并合理运用各种风险应对措施、管理方法、技 术手段,对项目的风险实施有效地控制,以确保项目风险处于 受控状态,而且能妥善处理风险事故所造成的各种损失,最终 能够保证以最小的成本实现项目的总体目标。
第8章 软件项目风险管理
风险是可以控制和管理的。虽然风险客观存在,人们也难 以消灭风险,但并不意味着风险无法避免,只要运用科学的方 法,深刻认识到风险后果及风险根源并预先采取有效措施,至 少可以将风险控制到人们可接受的程度。
2. 风险的属性 风险具有两大属性:可能性和损失。可能性(Likelihood) 是指风险发生的概率(Probability),损失(Loss)是指预期与 后果(Consequence)之间的差异,那么把概率和后果(影响)的 乘积称为风险损失当量用来反映风险的负面影响程度。
PMBOK定义风险为:“不确定的事件或情况一旦出现,将 会对项目的目标产生积极或消极的影响。”
综上所述,风险可定义为“损失的可能性”。它包括三个 要素,即事件、事件发生的概率、事件的影响。
第8章 软件项目风险管理
因此,可以从以下几个方面理解风险的含义: 风险意味着可能出现损失,可能实现不了预期目标。损失 出现与否是一种不确定的随机现象,可以用概率表示损失出现 的可能性,但不能对出现与否做出确定性判断。 风险是与人们的决策有关的。人们的决策往往决定着人们 有目的的活动、未来的活动以及人们变化的行为,这种行为既 包括个人行为,也包括群体或组织行为。风险与人们的行为密 切相关,不与行为联系的风险只是一种危险。 风险是可以预测和评估的。客观条件的变化是风险的重要 成因。尽管人们无力控制引起风险的客观状态,却可以认识并 掌握这些客观状态变化的规律性,对相关的客观状态做出科学 的预测和评估,从而为风险管理提供科学依据。
第8章 软件项目风险管理
2) 突发性 风险的产生往往给人以一种突发的感觉。当人们面临突然 产生的风险时往往不知所措,其结果是加剧了风险的破坏性。 风险的这一特点要求:加强对风险的预警和防范研究,建立风 险预警系统和防范机制,完善风险管理系统。 3) 多变性 风险的多变性是指风险会受到各种因素的影响,在风险性 质、破坏程度等方面呈现动态变化的特征。例如企业在生产经 营管理中面临的市场就是一种处在不断变化过程之中的风险。 当市场容量、消费者偏好、竞争结构、技术资金等环境要素发 生变化时,风险的性质和程度也将随之改变,因而要求实施动 态、柔性的风险管理。
第8章 软件项目风险管理
第8章 软件项目风险管理
8.1 软件项目风险管理概述 8.2 风险管理规划 8.3 风险识别 8.4 风险评估 8.5 风险监控 8.6 小结
第8章 软件项目风险管理
8.1 软件项目风险管理概述 8.1.1 风险概述
1. 风险的定义 “风险”一词对于大多数人来说并不陌生,究其概念却有 多种不同的定义。 美国学者A.H.Willett认为:“风险是关于不愿发生的事 件发生不确定性的客观体现。” 美国词典编辑家Webster认为:“风险是遭受损失的一种 可能性。” 美国人John Charles Chicken和Tamar Posner认为:“风 险应是损害(Hazard)和对损害暴露度(Exposure)两种因素的综 合。”
在这10项影响软件项目成功的关键因素中权重最高的是 “用户参与”,其次是“高层管理者的支持”。如果在软件项 目建设过程中没有给予这些关键因素足够的重视和管理,则项 目将面临很高的失败风险。
2. 软件项目风险的分类 概括起来:软件项目风险主要来源于开发过程和开发环境, 在需求定义、项目设计、项目实施等不同开发阶段,以及开发 人员、产品外包、系统用户、过程管理等相应的开发环境中可 能存在如表8-2所示的7大类(共计36项)风险因素。而且它们在 不同的软件项目中有不同的表现形式和影响程度。
第8章 软件项目风险管理
风险识别活动是借助风险检查表、工作分解结构、情景分 析、以往的经验来寻找阻碍软件项目成功的风险。风险分析活 动是从成本、项目绩效、进度和质量等方面研究风险对项目的 影响,把风险数据转化为能够进行风险决策的信息。风险优先 级活动是按风险影响的大小排出一个风险优先级,帮助项目经 理在处理风险时优先解决最严重的风险。
产品生产周期的变更 (31) 用户提供的数据不达标,导致额外的测试、设计和集成工作 (32) 前期的质量保证行为不真实,导致后期工作量的增加 (33) 缺乏规范及对标准的遵循 (34) 过于教条地坚持软件开发策略和标准,导致过多耗时于无用的工作 (35) 向管理层撰写报告占用开发人员的时间比预期的多 (36) 风险管理粗心,导致未能发现重大的项目风险
(8L-R1) PR CR
式中:LR表示风险损失当量;PR表示风险发生的概率;CR表示 风险发生带来的后果(影响)。
第8章 软件项目风险管理
由此可见,评判风险不能单纯考虑是否发生或造成的影响, 而是要把两者结合起来。有的风险发生的概率很大,但造成的 影响却很小,例如:出门忘带伞,却遭遇了大雨,被淋成落汤 鸡;有的风险发生的概率不大,但其影响极其严重,像强地震 一类的自然灾害,一个地区可能几十年甚至上百年不发生,可 是一旦发生后果不堪设想。
第8章 软件项目风险管理
微软解决方案框架中定义风险为:“任何可能对项目结果 产生积极或消极影响的事件或条件,以及项目决策和预期结果 的不确定性都会造成风险。”
中国的杜端甫教授认为:“风险是指损失发生的不确定性, 是人们因对未来行为的决策及客观条件的不确定性而可能引起 的后果与预定目标发生多种负偏离的综合。”
第8章 软件项目风险管理 表8-1 软件项目的风险来源
风险来源 用户参与 高层管理者支持 需求说明书清晰 计划编制适当 预期切合实际 细化项目里程碑 技术能力足够 职责区分明确 前景和目标清晰 工作人员工作努力、专注 总计
相对重要程度 19 16 15 11 10 9 8 6 3 3 100
第8章 软件项目风险管理
(6) 客户、开期望状态” (8) 设计方案基于某一些特定的成员或技术,而特定的成员或技术有变化 (9) 产品规模比估计的要大 (10) 涉足不熟悉的产品领域,花费时间比预期的要多
(11) 设计方案的变更 (12) 低效的项目组织结构 (13) 管理层审查与决策的时间比预期的长 (14) 费用超支 (15) 管理层的变更 (16) 缺乏必要的规范,导致工作失误与重复 (17) 非技术的第三方的工作时间比预期的要长 (18) 前期任务(例如,培训及其他)没有按时完成 (19) 开发人员和管理层之间关系不佳 (20) 需要更多的时间适应开发工具和环境 (21) 开发人员沟通不畅,从而使工作效率降低 (22) 人员的变更 (23) 选择承包商失误 (24) 承包商没有按承诺交付组件 (25) 承包商提交的组件质量低下,必须花时间加以改进 (26) 承包商技术水平低,无法提供需要的性能水平 (27) 用户对最后交付的产品不满意,要求重新设计和重做 (28) 未采纳用户意见而使最终产品不能完全满足用户要求 (29) 用户对规划组、原型和规格的审核、决策时间比预期长 (30) 用户不能/没有参与规划、原型和规格阶段的审核,导致需求不稳定和