《软件项目管理原理与实践》 课件第5章软件项目风险管理.pdf

第5章 软件项目风险管理内容提要；5 J概述o 5.1.1 项目风险的警示O 5.1.2 什么是风险管理 5.2风险管理模型O 5.2.1 玻姆模型o 5.2.2 持续风险管理模型o 5.2.3 李维特模型o 5.2.4 CMMI风险管理模型o 5.2.5 MSF风险管理模型 5.3风险管理计划O 5.3.1 风险管理计划的内容o 5.3.2 制定风险管理计划的工具与技术o 5.3.3 制定风险管理计划的输入、输出2内容提要 5.4风险识别O 5.4.1 风险识别o 5.4.2 用于风险识别的方法o 5.4.3 风险识别的输入、输出 5.5风险分析O 5.5.1 定性风险分析o 5.5.2 定量风险分析o 5.5.3 定量风险分析的输入输出o 5.5.4 应对风险的基本措施 5.6风险监控 5.7案例研究：风险管理实践O 5.7.1 公司背景简介o 5.7.2 实际项目分析o 5.7.3 实际的风险管理状况o 5.7.4 实施效果与总结分析)5,8小结3在博物馆陈列的瓦萨号战舰ANALYSISPLANEVALUATECONTROLREVIEWASSESSMENTRISK5a1风险概念 5.1.1 项目风险带来的警示O案例A 瓦萨号（Vasa）是瑞典国王古斯塔夫二世于1626年到1628年间 下令建造的一艘军舰。O案例B XX信息技术有限公司（CSAI）为某省某运营商建立一个商务 业务平台，并采用合作分成的方式。O案例C 国内一家省级电信公司（H公司）打算开发某项目，经过发布 RFP需求建议书，以及谈判和评估，最终选定XX信息技术有限 公司（吊AI）为苴襟供IP由珏设名.风险管理不再只是纸上谈兵，而应 有具体的量化评估体系675q风险概念 54.2 什么是风险管理。项目风险管理，实际上就是贯穿在项目开发过程中的一 系列管理步骤，其中包括风险识别、风险计划、风险分 析、风险解决和风险监控。8The Tr adit io nal QA Pr o ccessRel ying so l el y o n funct io nal t est ingThe Mo der n QA Pr o ccessLever aging aut o mat ed st r uct ur al qual it y gat e70%of defect s areFUNGIONAL30%ar tSTRUCTURAL1 UNDETECTABLEFIREFIGHTINGAverage 75 defect s rel eased per 100 funct ion point s70%of defect s ore FUNCTIONAL30%or e STRUCTUKALMo der n QA can del iver30%FEWER DEFECTS 喘、t han t r adit io nal QAPo wer ed By5.1.2 什么是风险管理主观学认为，风险是损失的不确定性；客观 学认为，风险是在给定情况下一定时期可能 发生的各种结果间的差异。O两个基本特征，是不确定性和损失。O IT行业中的软件项目开发是一项可能损失的活动，不管 开发过程如何进行都有可能超出预算或时间延迟。风险管理(RiskManagement)指如何在项 目或者企业一个肯定有风险的环境里把风险 减至最低的管理过程。10软件风险分类目前，风险管理已经发展成企业管理中一个具有相对独立 职能的管理领域，在围绕企业的经营和发展目标方面，风 险管理和企业的经营管理、战略管理一样具有十分重要的 意义。风险管理能增加项目成功的机率，使项目达到预期的结果 O由于软件生产的特殊性，软件风险包括软件项目风险、技术风险产品风险5.1.2什么是风险管理125q风险概念 PMP风险管理过 程包括:O风险管理计划O风险识别O风险定性分析O风险定量分析O风险应对计划O风险监控PMP13In t o F?FUnderest imat ing j Sit uat ions.在 0abi rl Lack of Real-TimeVisibil it y ut ure/Incompet ency in Priorit izing Maint aining TransparencyJ1Communicat ion)GapGGoodFirms企业风险管理和风险控制ENTERPRISE RISK MANAGEMENT(ERM)Business Strategy Business Management Business Platform15风险评估矩阵Risk Assessment Ma t rixImpact of Risk(Consequence)MajorMediumHighModerat eMediumMediu mHighMinorLo wMediu mMediumSeriousness of Risk=Probabil it y x ImpactUnl ikel y(0-33%)Moderat el yLikel y(33%-66%)Highl y Likel y(66%-100%)Probabil it y of Risk(Likel ihood)r16风险管理规划组件Level 1Level 2Level 3Business Risk Competitors Suppliers Cash flowAllProject RisksTechnical Risk Hardware Software NetworkOrganizational Risk Executive Support User Support Team SupportProject Management Risk Estimates Communication Resources175q风险概念Devel op Risk Management Pl anC-0ArcMect MrtConcept Eipiont ionI.D.Management RisksOpot ionsSMangt mt Sdt vrvCot fns Hardware Fabricat ionSyst em Venfl cat ioo PUi(Syst em AccepUmce)UM Test Pl anSub-Syst em Vert fkaibon Ran(Verify subfyfUrm)Subsyst em-A Irt t ffMiOA&VerH)cM6Risk Ident ificat ionrMonit oring004on GMt3 AssessmentSyt t t m Int egrMn&VinhcMxxiRisk Mit igat ionUM cyd t irm Nm18概念 CMMI风险管理域内容：O特定目标1:风险管理标准（对应风险计划）执行方法1.1:决定风险来源和类别 执行方法1.2：定义风险参数 执行方法1.3：建立风险管理策略O特定目标2：界定并分析风险（对应风险识别和分析）执行方法2.1：界定风险 执行方法2.2：评估、分类及排序风险o特定目标3:降低风险（对应风险应对和监控）执行方法3.1：开发风险降低计划 s lo idefitify pc JEg pnbiens bet t QMe irderse irrpjct s or act eg ot ect es,20风险流程管理图风险管理者的主要职责是在制订与评估规划时，从风险管 理的角度对项目规划或计划进行审核并发表意见，不断寻 找可能出现的任何意外情况，O试着指出各个风险的管理策略及常用的管理方法，以随时处理出现的风险，风险管 理者最好是由项目主管以外的人担任。21 521 玻姆模型美国著名的软件工程专家巴利玻姆(Barry Boehm)用公式RE=P(UO)*L(UO)对风险进行定义。RE表示风险或者风险所造成的影响O P(UO)表示令人不满意的结果所发生的概率O L(UO)表示糟糕的结果会产生的破坏性的程度。225J风险管理模型 Boehm思想的核心是10大风险因素列表，其中包括人员短 缺、不合理的进度安排和预算、不断的需求变动等。针对每个风险因素，Boehm都给出了一系列的风险管理策 略。o在实际操作时，以10大风险列表为依据，总结当前项目具体的风险因素，评估后进行计划和实施，在下一次定期召开的会议上再对这10大风险因素 的解决情况进行总结，产生新的10大风险因素表，依此类推。10大风险列表的思想，可以将管理层的注意力有效地集中 在高风险、高权重、严重影响项目成功的关键因素上，而 不需要考虑众多的低优先级的细节问题。O而且，这个列表是通过对美国几个大型航空或国防系统软件项目的深入调 查，编辑整理而成的，因此有一定的普遍性和实际性。23 522 SEI 的 CRM 模型 SEI的风险管理原则是：不断地评估可能造成恶劣后果的因 素，决定最迫切需要处理的风险，实现控制风险的策略，评测并确保风险策略实施的有效性。CRM模型要求在项目生命期的所有阶段都关注风险识别和 管理，它将风险管理划分为5个步骤，即风险识别、分析、计划、跟踪、控制。Soft ware Engineering Inst it ut eCamegieMelloii245J风险管理模型523李维特模型将形成各种系统的组织划分为4个组成部分，即 任务、结构、角色、技术。O这4个组成部分，和软件开发的各因素很好地对应起来。角色覆盖了所有的项目参与者，例如软件用户、项目经理和设计人员等；结构表示项目组织和其 它制度上的安排；技术则包括开发工具、方法、硬件软件平台；任务描述了项目的目标和预期结 果。O李维特模型的关键思路是：模型的各个组成部分是密切相关的，一个组成部分的 变化会影响其它的组成部分，如果一个组成部分的状态和其它的状态不一致，就 会造成比较严重的后果，并可能降低整个系统的性能。255J风险管理模型e 5.2.4 CMU/SEI的CMMI风险管理模型 软件能力成熟度模型集成(Capability Maturity Model Integration,CMMI)是由美国卡内基梅隆大学软件工程研究所(Software Engineering Institute,SEI)在CMM基础上发展而来。目前，CMMI是全球软件业界的管理标准。风险管理过程域在CMMI的 第三级，即已定义级中建立一个关键过程域(Key Practice Area,KPA)o26风险管理模型 CMMI风险管理模型目标1:准备风险管理目标2：识别、分 析风险维管 并险略 定风飙 制护理风 义数 定#,险种 风和 定源 确来类库 险 风该模型的核心是风险库，实现各个目标的每个活动都会更新这个风险库。其 中活动制订并维护风险管理策略与风险库的联系是一个双向的交互过程，即通过采集风险库中相应的数据并结合前一活动的输入来制订风险管理策略。72如何从CMMI成熟.Init ial5.Opt imized4.Measured2.ManagedCMMI Mat urit y l evel s28 5.2.5 微软的MSF风险管理模型管理原则：持续的评估。A培养开放的沟通环境:所有组成员应参与风险识别与分析,领导者应 鼓励建立没有责备的文化。从经验中学习：学习可以大大降低不确定性，强调组织级或企业级的 从项目结果中学习的重要性。A责任分担组中任何成员都有义务进行风险管理j Microsoft295.2.5 微软的MSF风险管理模型Microsoft SolutionsFramework Part 130MicrosoftMSF Risk Management ProcessRisk StatementIdentityMaster Risk ListCont rolPl an and Schedul eiI Risk-Knowledge Base;RisksTrack and、ReportConcepts,and Processes235.3风险管理计划 1,基本内容O风险管理计划的基本内容包括:(1)方法论(2)角色与职责(3)预算(4)计时法(5)风险分类325.3风险管理计划)(6)(7)，(8)风险概率和影响的定义 概率和影响矩阵 修改利害关系者承受度(9)汇报格式。3334RESOURCE BREAKDOWN STRUCTUREEnt er yo ur sub headl ine her e5.3风险管理计划 2.其他内容(1)应急计划(2)应急储备365.3风险管理计划 5.3.2 制定风险管理计划的工具与技术O(1)风险核对表法O(2)风险管理表格O(3)风险数据库模式37Sensit ivit yRel evanceChal l engesThe Schedul e Sensit ivit y Index(SSI)is t he best per fo r ming met r ict o measur e t ime sensit ivit yTimevThr ee ver s2ns o f t he Cr ucial i(y Index(CRI)ar e kno n t o measur e co st and r eso ur ce sensit ivit yResourcesThese mel r ics r eveal t hs mo st cr it ical co mpo nent s in t he Wo r k Br HAkdo wn St r uct ur e!-10-n;t esiForecast ingExt ending EVM fo r ecast ing t echniques wit h sensit ivit y info r mat io n impr o ves t he t ime and co t fo r ecast ing and st abil it y cKCur ncyBot t om-up cost cont rolThe t o po l o gical st r uct ur e o f t he pr o j ect nel wo r k is kno wn as t he main dr iver o f t he sel ect io n o f t he best per fo r ming t ime co nt r o l met ho d,but no such Kno wl edge is avail abl e fo r co s【co nir o lResource Const raint sReso ur ce co nst r ained Schedul e Rt$k Anal yisSRACont rolUsing t hr esho l ds o n sensit ivit y net ncs t o per fo r m a bo t t o fiMj p pr o j ect co nt r o lH W,Mnjrt rww acovocs m t roubl e*,i n，【y Big Dat a,Resear ch o n Ar t ificial Int el l igence met ho ds t o disco ver t r ends in dat a and dr iver s fo r pr o j ect co nt r o l per fo r mance t s gr o wing,and sho ul d be inco r po r at ed int o SHASOBe careful The aensHMt y met riaB give you a val ue beoeen 0%and 100%.but il is acMeed Io never report whal you dont underst and.These meiffcs require int erpceCabor before t heir rel evance and use n a forecast ing and corfrd envronmenl is useiul.385.3风险管理计划 5.3.3制定风险管理计划的输入、输 出制定风险管理计划的输入，包括:企业环境因素：组织及参与项目的人员的风险态度和风险承受度将影响项 目管理计划。风险态度和承受度可通过政策说明书或行动反映出来。组织过程资产：组织可能设有既定的风险管理方法，例如风险分类、概念 和术语的通用定义、标准模板、角色和职责、决策授权水平。项目范围说明书 项目管理计划制定风险管理计划的输出，包括风险管理39STRATEGYRISKANALYSISIDENTIFICATIONEVALUATIONPLANPERFORMANCEINPACTCOSTopportunity2 _PROCESS RISIOW*4/MAN AGEMENfsolution 警部般!l bBMANAGEMENT 意卧罐鳄雕惜sIMPORTANTCONTROLOSs4054风险识别，5 Al 风险识别 风险识别，就是企图采用系统化的方法，识别某 特定项目已知的和可预测的风险。软件风险包含两个特征官O不确定性：刻划风险的事件可能发生也可能不发生，没 有100%发生的风险。O损失：如果风险变成了现实，就会产生恶性后果或损失。5A1 风险阚风险识别，一方面可以通过感性认识和历史 经验来判断，另一方面，也可通过对各种客 观的资料和风险事故的记录来分析、归纳、整理，以及必要的专家访问，从而找出各种 明显和潜在的风险及其损失规律。O因为风险具有可变性，因而风险识别是一项持续性和系 统性的工作，要求风险管理者密切注意原有风险的变化,并随时发现新的风险。企业风险识别，指对企业面临的尚未发生的 潜在的各种风险进行系统的归类分析，从而 加以认识与辨别的过程。425A1 风险阚常用方法是建立“风险条目检查表”，利用 一组提问来帮助项目风险管理者了解在项目 和技术方面有些风险。在风险条目检查表中，列出了所有可能的与每一个风险 因素有关的提问，使得风险管理者集中来识别常见的、已知的和可预测的风险，如产品规模风险、依赖性风险、需求风险、管理风险及技术风险等。风险条目检查表可以以不同的方式组织，通过判定分析 或假设分析，给出这些提问确定的回答，就可以帮助管 理或计划人员估算风险的影响。43Risk event s and t heir rel at ionships are definedProbabil it ies and consequences of risk event s are assessedIdentify Risks1.Risk Ident ificat ionAAssess Probaility&ConsequenceReassess exist ing risk event s and ident ify new risk event slistedRisks2.RiskImpact AssessmentConsequences may incl ude cost schedul e,t echnical performance impact s,as wel l as capabil it y or funct ional it y impact sRisk TrackingAssess RiskCriticality 4.Risk Mit igat ion Pl anning.Impl ement at ion,and Progress Monit oringRisk Mitigation3,Risk Priorit izat ion Anal ysisDecision-anal yt ic rul es appl ied t o rank-order ident ified risk event s from*most t o l east*crit icalRisk event s assessed as medium or high crit ical it y might go int o risk mit igat ion pl anning and impl e ment at ion l ow crit ical risks might be t racked/monrt ored on awat ch l ist.5A1 风险阚4554风险谢 1.量化损失程度46量化损失程度(1)项目风险O项目风险是指潜在的预算、进度、人力(工作人员和组织)、资源、客户、需求等方面的问题以及它们对软件项目的影响。项目风险威胁项目计划,如果风险变成现实，有可能会拖延项目的进度，增加项目的成本。项目 风险的因素还包括项目的复杂性、规模、结构的不确定性。(2)技术风险O是指潜在地设计、实现、接口、验证和维护等方面的问题。此外规约的二 义性、技术的不确定性、陈旧的技术、以及“过于先进”的技术也是风险 因素。技术风险威胁要开发的软件的质量及交付时间。如果技术风险变成 现实，则开发工作可能变得很困难或者不可能。(3)商业风险O商业风险威胁到要开发软件的生存能力。商业风险常常会危害项目或产品O47量化损失程度主要的商业风险包括：O(1)开发一个没有人真正需要的优秀产品或系统(市 场风险)；O(2)开发的产品不再符合公司的整体商业策略(策略 风险)；O(3)建造了一个销售部门不知道如何去卖的产品(销 售风险)；O(4)由于重点的转移或人员的变动而失去了高级管理 层的支持(管理风险)；O(5)没有得到预算或人力上的保证(预算风险)。482.风险方式(1)已知风险。是通过仔细评估项目计划、开发项目的商业及技术环境、以及其它可靠的信息来源(如不现实的交付时间，没 有需求或软件范围的文档、恶劣的开发环境)之后可以 发现的那些风险。(2)可预测风险O能够从过去项目的经验中推测出来(如：人员调整，与 客户之间无法沟通，由于需要进行维护而使开发人员精 力分散)。(3)不可预测风险O可能、也会真的出现，但很难事先识别出它们来。492.风险方式风险分为以下方式：O(1)已知风险，是通过仔细评估项目计划、开发项目 的商业及技术环境、以及其它可靠的信息来源(如不现 实的交付时间，没有需求或软件范围的文档、恶劣的开 发环境)之后可以发现的那些风险。O(2)可预测风险，能够从过去项目的经验中推测出来(如：人员调整，与客户之间无法沟通，由于需要进行 维护而使开发人员精力分散)。O(3)不可预测风险，它们可能、也会真的出现，但很 难事先识别出它们来。503.识别风险识别风险是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。O通过识别已知和可预测的风险，项目管理者就有可能避免这些风险,且当必要时控制这些风险。每一类风险可以分为两种不同的类型，一般性风 险和特定产品的风险。O“一般性风险”，对每一个软件项目而言都是一个潜在地威胁。O”特定产品的风险”，只有那些对当前项目的技术、人员及环境非 常了解的人才能识别出来。O为了识别特定产品的风险，必须检查项目计划及软件范围说明，从 而了解本项目中有什么特殊的特性可能会威胁到项目计划。513.识别风险 一般性风险和特定产品的风险都应该被系统化地标识出来O识别风险的一个方法是建立风险条目检查表。该检查表可以用来识别风险，并可以集中来识别下列常见 子类型中已知的及可预测的风险：O(1)产品规模：与要建造或要修改的软件的总体规模相关的风险。O(2)商业影响：与管理或市场约束相关的风险。O(3)客户特性：与客户的素质以及开发者和客户定期通信的能力相关的 风险。O(4)过程定义：与软件过程被定义的程度以及它们被开发组织所遵守的 程度相关的风险。O(5)开发环境：与用以建造产品的工具的可用性及质量相关的风险。O(6)建造的技术：与待开发软件的复杂性以及系统所包含技术的新奇性 相关的风险。O(7)人员数目及经验：与参与工作的软件工程师的总体技术水平及项目 经验相关的风险。521)产品规模风险项目风险是直接与产品规模成正比的。下面的风 险检查表中的条目标识了产品(软件)规模相关 的常见风险：O(1)是否以LOC或FP估算产品的规模。o(2)对于估算出的产品规模的信任程度如何。o(3)是否以程序、文件或事务处理的数目来估算产品规模。o(4)产品规模与以前产品的规模的平均值的偏差百分比是多少。o(5)产品创建或使用的数据库大小如何。o(6)产品的用户数有多少。o(7)产品的需求改变多少？交付之前有多少？交付之后有多少?o(8)复用的软件有多少？532)商业影响风险销售部门是受商业驱动的，而商业考虑有时会直 接与技术实现发生冲突。下面的风险检查表中的条目标识了与商业影响相 关的常见风险：O(1)本产品对公司的收入有何影响。O(2)本公司是否得到公司高级管理层的重视。O(3)交付期限的合理性如何。O(4)将会使用本产品的用户数及本产品是否与用户的需要相符合O(5)本产品必须能与之互操作的其它产品/系统的数目。O(6)最终用户的水平如何。O(7)政府对本产品开发的约束。O(8)延迟交付所造成的成本消耗是多少。o(9)产品缺陷所造成的成本消耗是多少。543）客户相关风险 首先，客户有不同的需要。O 一些人只知道他们需要什么，而另一些人，知道他们不需要什么。O 一些客户希望进行详细的讨论，而另一些客户则满足于模糊的承诺。其次，客户有不同的个性。O 一些人喜欢享受客户的身份，而另一些人则根本不喜欢做为客户。O 一些人会高兴地接受几乎任何交付的产品，并能充分利用一个不好的产品,而另一些人则会对质量差的产品猛烈抨击。O 一些人会对质量好的产品表示赞赏，而另一些人则不管怎样都抱怨不休。然后，客户和供应商之间也有各种不同的通信方 式。O 一些人非常熟悉产品及生产厂商，而另一些人则可能素未谋面，仅仅通过 信件来往和电话与生产厂商沟通。553)客户相关风险 一个“不好的”客户，可能会对一个软件项目组 能否在预算内完成项目产生很大的影响。O对于项目管理者而言，不好的客户是对项目计划的巨大威胁和实际 的风险。下面的风险检查表中的条目，标识了与客户特征 相关的常见风险：O(1)你以前是否曾与这个客户合作过。O(2)该客户是否很清楚需要什么，他能否花时间把需求写出来。O(3)该客户是否同意花时间召开正式的需求收集会议，以确定项 目范围。O(4)该客户是否愿意建立与开发者之间的快速通信渠道。O(5)该客户是否愿意参加复审工作。o(6)该客户是否具有该产品领域的技术素养。(7)该客户是否愿意你的人来做他们的工作。564)过程风险(1)高级管理层是否有一份已经写好的政策陈述，该陈述 中强调了软件开发标准过程的重要性？(2)开发组织是否已经拟定了一份已经成文的、用于本项 目开发的软件过程的说明？(3)开发人员是否同意按照文档所写的软件过程进行开发 工作，并自愿使用它？(4)该软件过程是否可以用于其它项目？(5)管理者和开发人员是否接受过一系列的软件工程培训(6)是否为每一个软件开发者和管理者提供了印好的软件 工程标准？(7)是否为作为软件过程一部分而定义的所有交付物建立 了文档概要及示例？574)过程风险(8)是否定期对需求规约、设计和编码进行正式的技术复审？(9)是否定期对测试过程和测试情况进行复审？(10)是否对每一次正式技术复审的结果建立了文档，其中包括发现 的错误及使用的资源？(11)有什么机制来保证按照软件工程标准来指导工作？(12)是否使用配置管理来维护系统/软件需求、设计、编码、测试用 例之间的一致性？(13)是否使用一个机制来控制用户需求的变化及其对软件的影响？(14)对于每一个承包出去的子合同，是否有一份文档化的工作说明、一份软件需求规约和一份软件开发计划？(15)是否有一个可遵循的规程，来跟踪及复审子合同承包商的工作?58技术问题(1)是否使用方便易用的规格说明技术来辅助客 户与开发者之间的通信？(2)是否使用特定的方法进行软件分析？(3)是否使用特定的方法进行数据和体系结构的 设计？(4)是否90%以上的代码都是使用高级语言编写 的？(5)是否定义及使用特定的规则进行代码编写？(6)是否使用特定的方法进行测试用例的设计？59技术问题(7)是否使用配置管理软件工具控制和跟踪软件 过程中的变化活动？(8)是否使用工具来创造软件原型？(9)是否使用软件工具来支持测试过程？(10)是否使用软件工具来支持文档的生成和管 理？(11)是否收集所有软件项目的质量度量值？(12)是否收集所有软件项目的生产率度量值？605)技术风险(1)该技术对于你的公司而言是新的吗？(2)客户的需求是否需要创建新的算法或输入、输出技术？(3)待开发的软件是否需要使用新的或未经证实 的硬件接口？(4)待开发的软件是否需要与开发商提供的未经 证实的软件产品接口？(5)待开发的软件是否需要与功能和性能均未在 本领域得到证实的数据库系统接口？(6)产品的需求是否要求采用特定的用户界面？615)技术风险(7)产品的需求中是否要求开发某些程序构件，这些构件与你的公司以前开发的构件完全不同？(8)需求中是否要求采用新的分析、设计、测试 方法？(9)需求中是否要求使用非传统的软件开发方法?(10)需求中是否有过分的对产品的性能约束？(11)客户能确定所要求的功能是可行的吗？626)开发环境风险(1)是否有可用的软件项目管理工具？(2)是否有可用的软件过程管理工具？(3)是否有可用的分析及设计工具？(4)分析和设计工具是否适用于待建造产 品？(5)是否有可用的编译器或代码生成器？(6)是否有可用的测试工具？636)开发环境风险(7)是否有可用的软件配置管理工具？(8)环境是否利用了数据库或数据仓库？(9)项目组的成员是否接受过每个所使用 工具的培训？(10)是否有专家能够回答有关工具的问题(11)工具的联机帮助及文档是否适当？647)与人员数目及经验相关的风险(1)是否有最优秀的人员可用？(2)人员在技术上是否配套？(3)是否有足够的人员可用？(4)开发人员是否能够自始至终地参加整个项目 的工作？(5)项目中是否有一些人员只能部分时间工作？(6)开发人员对自己的工作是否有正确的期望？(7)开发人员是否接受过必要的培训？(8)开发人员的流动是否仍能保证工作的连续性?65风险管理6654风险识别 5.4.2 用于风险识别的方法o 1.分析识别的步骤O风险识别一般可分三步进行：收集资料 风险形势估计根据直接或间接的症状将潜在的风险识别 出来。6754风险识别Risk IdentificationPMI Pr act ice St andar d fo r Pr o j ect Risk Management(2009)Assumption AnalysisBrainstorming1Cause and Effect(Ishikawa)Diagr ams1Check Lists1Delphi TechniqueDocumentation Reviews1FMEA/Fault Tree Analysis1Force Field Analysis1Industry knowledge base1Influence diagramsInterviews1Nominal Group Technique1LessonsLearned1rPrompt ListsQuestionnaireRisk Breakdown Structure(RBS)1Root-Cause Analysis1SWOT Analysis1System Dynamics1WBS Review三城MAnidiens 2416854风险识别Bo wTiePl uginsBo wTie XPTABo wTieBo wTie e-Lear ningBo wTie Ser verRisk ident ificat io neva uaRisk anal、Audit XPRisk assessmeSco pe,co nt ext,cr it erRisk t r eat mentRecording&reporting。6954风险识别 2.风险识别的具体方法70SWOT分析法 SWOT分析法是一种环境分析方法。所谓的SWOT,是英文Strength（优势）、Weakness（劣势）、Opportunity（机遇）和 Threat（挑战）的简写71道斯矩阵III机会 列出现有的机会II优势vso战略 抓住机遇，发挥优 势战略VII劣势 具体列出弱点 VI WO战略 利用机会，克服劣 势战略 VIII挑战 列出正面临的威胁ST战略利用优势，减少威 胁战略WT战略 弥补缺点，规避威 胁战略72道斯矩阵(I)将内部优势与外部机会相组台，形成so策略,制定抓住机会、发挥优势的战略，填入道斯矩 阵的V区。(2)将内部劣势与外部机会相组合，形成W0策 略，制定利用机会克服弱点的战略，填入道斯矩 阵VI区。(3)将内部优势与外部威胁相组合，形成ST策略,制定利用优势减少威胁战略，填入道斯矩阵vn 区。(4)将内部劣势与外部挑战相组合，形成WT策 略，制定弥补缺点、规避威胁的战略，填人道斯 矩阵 vnilXc _73程 过 全念 概划 计今今今今今今行 执对一个或更多阶段的投入时间不够没有记录下重要的信息尚未结束一个或更多前期阶段就进入下一阶段没有书面记录下所有的背景信息与计划没有进行正式的成本收益分析没有进行正式的可行性研究不知道是谁首先提出项目创意准备计划的人过去没有承担过类似的项目没有写下项目计划的某些部分遗漏了项目计划的某些部分项目计划的部分或全部没有得到所有关键成员的批准指定完成项目的人不是准备计划的人未参加制定项目计划的人没有审查项目计划，也未提出任何疑问主要客户需求发生变化收集到的有关进度情况和资源消耗的信息不够完整或不够准确项目进展报告不一致一个或更多找到的项目支持者有了新的分配任务，项目成员就被分配到新的项目组 中在实施期间替换了项目组的成员市场特征或需求发生了变化结束 令一个或更多的项目驱使着没有正式批准项目的成果_一在尚未完成项目的所有工作下，项目成员被分配到新的项目组74因果图 因果图(Cause-and-Effect diagram)O又被称作石川图或鱼骨图，用于识别风险的成因工人疲劳人员原材料质量低劣过程缺乏培训生产方法单一工作条件恶劣研发不足设备维护不良技术老旧质量承诺低操作不当产品质量 不符合要求抵达延迟75Fishbone DiagramA Fishbo ne Diagr am is a st r uct ur ed br ainst o r ming t o o l using cat ego r ies t o expl o r e r o o t causes fo r an undesir abl e effect.Cat egoriesProbl emCausesRisk responseI n t e m a 一 c o n t r o l一 he environnient 07一s k0The continuous improveinent of risk management1205.7案例研究：风险管理实践M a n a g e m e n 一Bus-ness e x e c&-o nBma_ contr。-121需求阶段识别的主要风险阶段目标衡量标准出现的风险文字描述的清晰程度错误理解，开发错误的软件需求分析的完整性系统设计困难、实现的系统与 用户需求不一致、测试困难需求文档的易理解程度系统设计困难、实现的系统与 用户需求不一致、测试困难，理解错误需求的稳定性系统不稳定，编码困难122需求阶段风险定性分析风险项概率对本阶段目标 的影响力对其它阶段目标的影响力对软件开 发综合影 响力错误理解 需求分析高高高很高开发不符 合客户需 求一般高高很高设计困难一般一般高高对需求的 变动无法 做出调整一般高一般一般无法在规 定时间内 完成高一般高高1