推荐SPM05软件项目风险管理

上传人:ni****g 文档编号:569189833 上传时间:2024-07-28 格式:PPT 页数:75 大小:929.50KB
返回 下载 相关 举报
推荐SPM05软件项目风险管理_第1页
第1页 / 共75页
推荐SPM05软件项目风险管理_第2页
第2页 / 共75页
推荐SPM05软件项目风险管理_第3页
第3页 / 共75页
推荐SPM05软件项目风险管理_第4页
第4页 / 共75页
推荐SPM05软件项目风险管理_第5页
第5页 / 共75页
点击查看更多>>
资源描述

《推荐SPM05软件项目风险管理》由会员分享,可在线阅读,更多相关《推荐SPM05软件项目风险管理(75页珍藏版)》请在金锄头文库上搜索。

1、第5章 软件项目风险管理5.1 概述5.2 风险识别5.3 风险分析、规划5.4 风险跟踪与应对5.5 风险管理验证15.1.1 风险nSEI将风险定义为损失的可能性。n风险具有两大属性:可能性和损失。可能性是指风险发生的概率,损失是指预期与后果之间的差异。n风险的根源在于事物的不确定性。2软件风险管理的相关概念1.目标:明确定义的目标界定了可接受的风险范围。2.不确定性:未知的因素。3.损失:没有潜在的损失,就没有风险4.时间 5.选择6.决策7.应对风险 3导致软件风险的原因n进度过分紧迫;n预算过分紧张;n性能过分的超群,软件可靠性要求过高;n人员缺乏经验,组织结构不适宜;n期望过高而不

2、现实;n没有明确或理解合同的条款;n软件规模估计不恰当;n管理部门缺乏经验;n风险分析和管理不恰当;n缺乏政策性支持;n不熟悉技术或过程;n不熟悉必要的硬件;n需求不一致(或定义不充分);n需求不断变动;n软件开发计划不恰当;n软件开发过程模型不适用;n缺乏软件工程技术和方法;n缺乏自动化工具的支持6.1 软件项目风险管理概述软件项目风险管理概述45.1.2 软件风险n软件风险由管理过程风险和技术过程风险组成55.1.3 软件项目风险管理n风险管理与项目管理的关系可归纳如下:1.从项目的成本、时间和质量目标来看,风险管理与项目管理的目标一致。2.从项目管理的计划职能来看,风险管理为项目计划的制

3、定提供了依据。3.从项目的成本管理职能来看,项目风险管理通过风险分析,指出有哪些可能的计划外费用。4.从项目实施过程来看,许多风险都在项目实施过程中由潜在变为现实。定出风险反应计划。6风险管理与项目管理的关系 n目标一致目标一致n为项目计划的制定提供了为项目计划的制定提供了依据依据n是成本管理的一部分是成本管理的一部分n许多分析都在项目实施过许多分析都在项目实施过程中由潜在变为现实程中由潜在变为现实6.1 软件项目风险管理概述软件项目风险管理概述采采购购 计计划划风风险险 计计划划沟沟通通计计划划人人力力 计计划划质质量量计计划划 成成本本 计计划划时时间间计计划划集集成成计计划划范范围围计计

4、划划 项项目目 结结束束项目项目执执 行控行控制制 项项目目 计计划划 项项目目 初初始始78风险管理的主要内容【概述中提到】【概述中提到】1、制定风险管理计划2、风险识别3、风险分析4、风险计划5、风险跟踪6、风险应对7、风险管理验证95.1.4 软件项目风险管理意义n141n通过风险分析,了解风险对项目的影响.为以后的规划与设计工作提供反馈,以便采取措施防止与避免风险损失。n可推动项目管理层和项目组织积累风险资料,以便改进将来的项目管理。 10风险管理n是指在项目进行过程中不断对风险进行识别、评估、制定策略、监控风险的过程。n通过风险识别、风险分析和风险评价去认识项目的风险,并以此为基础合

5、理地使用各种风险应对措施、管理方法、技术和手段对项目的风险进行有效的控制,妥善处理风险事件造成的不利后果,以最小的成本保证项目总体目标的实现。115.2 风险识别n是试图通过系统化的方法寻找可能影响项目的风险(已知的和可预测的)以及确认风险特性的过程。n目标是:辨识项目面临的风险,揭示风险和风险来源,以文档及数据库的形式记录风险。n活动包括:风险识别方法的确定;风险定义及分类;风险文档编写。12项目识别的依据n项目计划n历时经验n外部制度制约n项目内部的不确定性13风险识别的输入、输出输入输入输入输入输入输入标识风险标识风险标识风险标识风险评审风险评审风险评审风险评审风险评审风险评审风险输出输

6、出输出输出输出输出风险列表风险列表项目的项目的WBS、工作的陈述(、工作的陈述(Statement Of Work,SOW)、项目相关信息、项目计划假设、历史项目数据,)、项目相关信息、项目计划假设、历史项目数据,其他项目经验文件、评审报告、公司目标等。其他项目经验文件、评审报告、公司目标等。14风险识别参与人员n项目组成员n风险管理人员n学科专家(组织内)n客户n项目的其他管理人员n外部专家n155.2.2常见软件风险【142-143】1.人力资源风险2.需求风险3.项目接口风险4.设计风险5.管理风险6.开发过程风险7.项目集成与测试风险165.2.3风险识别过程1.进行风险评估2.系统地

7、识别风险3.风险定义及分类4.确定风险驱动因素5.将风险编写为文档175.2.4风险识别方法n德尔菲方法n头脑风暴法n情景分析法n面谈法n会议法nSWOT分析法n风险条目检查表18头脑风暴法n召开项目组全体会议,进行关于项目风险的自由讨论,项目组成员在主持人的引导下完全自由地发言,不受限制,产生关于项目风险的概念。n坚持不进行过多讨论,不对别人的意见进行判断性评论,甚至明确不许使用身体语言表达评判意见,如:咳嗽、冷笑等。n险管理人员将会议结果进行分类整理,作为风险的基础和其他风险识别方法的结果一起提交风险分析。19情景分析法n通过对系统内外相关问题的系统分析,设计出多种可能的未来前景,然后用类

8、似于撰写电影剧本的手法,对系统发展态势做出自始至终的情景和画面的描述。n可用情景分析法来预测和识别其关键风险因素及其影响程度。20SWOT分析法n(Strength, Weakness, Opportunities, and Threats) 是综合分析项目内部优势、弱势和项目外部机会与威胁的技术。nSWOT作为一种系统分析工具,其主要目的是对项目的优势与劣势、机会与威胁各方面,从多角度对项目风险进行识别。21风险条目检查表n利用一组提问来帮助管理者了解项目在各方面有哪些风险。n检查表中,列出了所有可能的与每一个风险因素有关的提问,使得风险管理者集中来识别常见的、已知的和可预测的风险n条目检查

9、表一般根据风险要素进行编写,建立软件项目的风险条目列表,包括项目的环境、管理层的重视度、技术情况以及内部因素(如团队成员的技能或技能缺陷等)。 2223一、产品工程类1.Requirements(需求)a.Stability(稳定性)b.Completeness(完整性)c.Clarity(清晰)d.Validity(有效性)e.Feasibility(可行性)f.Precedent(案例)g.Scale(规模)242.Design(设计)a.Functionality(功能性)b.Difficulty(困难)c.Interfaces(接口)d.Performance(性能)e.Testabi

10、lity(可测试性)f.Hardware Constraints(硬件约束)g.Non Developmental software(非开发软件)253.Code and Unit test(编码和单元测试)a.Feasibility(可行性)b.Testing(单元测试)c.Coding/Implementation(编码/实现)4.Integration and Test(集成和测试)a.Environment(环境)b.Product(产品)c.System(系统)265.Engineering Specialties(工程特点)a.Maintainability(可维护性)b.Reli

11、ability(可靠性)c.Safety(安全性)d.Security(保密性)e.Human Factors(人的因素)f.Specification(特定性)27二、Development Environment(开发环境)1.Development process(开发过程)a.Formality(正规性)b.Suitability(适宜性)c.Process Control(过程控制)d.Familiarity(熟悉程度)e.Product control(产品控制)282.Development System(开发系统)a.Capacity(生产量)b.Suitability(适宜性

12、)c.Usability(可用性)d.Familiarity(熟悉度)e.Reliability(可靠性)f.System Support(系统支持)g.Deliverability(可交付性)293.Management Process(管理过程)a.Planning(计划)b.Project Organization(项目组织)c.Management Experience(管理经验)d.Program Interfaces(项目接口)304.Management Methods(管理方法)a.Monitoring(监控)b.Personnel Management(人事管理)c.Qual

13、ity Assurance(质量保证)d.Configuration Management(配置管理)315.Work Environment(工作环境)a.Quality Attitude(质量态度)b.Cooperation(合作)c.Communication(交流)d.Morale(士气)32三、Program Constraints(项目约束)1.Resources(资源)a.Schedule(进度)b.Staff(人员)c.Budget(预算)d.Facilities(设施)332.Contract(合同) a.Type of Contract(合同类型)b.Restriction

14、(约束)c.Dependence(依赖关系)343.Program Interfaces(项目接口)a.Customer(客户)b.Associate Contractors(联合承包方)c.Subcontractors(子承包方)d.Prime Contractor(主承包方)e.Corporate Management(共同管理)f.Vendors(供货商)g.Politics(策略)355.3 风险分析n提炼风险背景,确定风险来源,确定行动时间框架和确定前10相首要风险名单n5.3.1 风险分析过程365.3.1 风险分析过程1.定义风险度量准则2.预测风险影响3.评估风险4.对风险进行

15、排序5.制定风险计划【设想、应对】37q分析n风险发生的概率,确定发生的可能性(P)n风险后果,发生后对项目目标的影响(I)n风险值,风险的严重程度R=F(P,I)q确定优先次序n按风险的严重性排序n确定最需要关注的TOP 10风险38前10位首要风险列表39制定风险计划40风险列表示例415.3.2 风险分析技巧与工具n一般,在定性风险分析之后就可以进行定量风险分析。n定量风险分析量化分析每一个风险的概率及其对项目目标造成的后果,也分析项目总体风险的程度。n方法:访谈、因果关系分析、决策树分析、模拟法42因果关系分析43决策树分析n提供项目所有可供选择的行动方案,行动方案之间的关系,行动方案

16、的后果以及发生的概率n提供选择一个最佳的方案的依据n损益期望值(Expected Monetary Value,EMV)是决策树的一种计算值,根据风险发生的概率计算n例如:某行动方案成功的概率是50%,收益是10 EMV=1050%=544决策树分析风险值?EMV=0失败:失败:P=30%, outcome= -200000 成功:成功:P=70%EMV=9500070%=66500实施后:实施后:EMV=6500不实施不实施EMV=-20000030%=-60000低性能:低性能:P=70%, outcome=-100000EMV=-10000070%=-70000高性能:高性能:P=30%

17、, outcome=550000EMV=55000030%=1650006.3 风险评估风险评估45决策树分析例子6.3 风险评估风险评估46n差距分析法【151】n帕累托分析法n敏感度分析法【152】475.3.3 分析成果6.3 风险评估风险评估485.4 风险跟踪与应对n5.4.1 风险跟踪的目标和依据n5.4.2 风险跟踪的成果n5.4.3 风险跟踪的过程49n风险控制通过对风险的规划和对项目全过程的控制,保证风险管理能达到预期的目标。n其目的是核对风险管理的策略和实施的实际效果是否和预见相同,同时获取反馈信息,改善风险计划和管理。505.4.3 风险跟踪的过程1.监视风险设想2.对比

18、项目状态与风险阈值3.风险信息的通知4.报告风险的度量51风险度量及定义6.5 风险控制风险控制52风险应对计划(top 10 清单)6.5 风险控制风险控制任务可能的风险产生的阶段产生的原因避免的措施后处理制定设计阶段的规范和标准时间风险项目准备需制定的规范和标准较多,而同时需完成其他工作,使得可使用的时间和资源有限开发环境确认资源风险系统设计由于设备未到位导致延误开发管理系统设计技术风险系统设计基于TeMIP平台开发SDH专网管理系统对于公司乃至国内都是全新的课题,由于技术的掌握程度和经验仍很欠缺在系统设计前请TeMIP专家进行相关培训l换成其他的技术实现53应对计划(top 10 清单)

19、实例(续)任务可能的风险产生的阶段产生的原因避免的措施后处理对功能规格和系统设计的调整时间风险0版本开发评测结果对功能规格和系统设计影响较大0版本开发时间风险0版本开发由于学习曲线过长延误时间系统测试资源风险0版本开发开发人员与SQA人员对工作站和服务器使用的争夺MD现场调试资源风险1版本开发由于设备问题延误现场调试现场运行环境确认资源风险2版本开发由于设备问题延误验收测试的进行54风险管理是一个连续的过程6.5 风险控制风险控制555.4.4 风险应对策略1.避免避免是指通过改变项目计划或条件完全消除项目风险或保护项目目标不受风险影响。2.转移转移是指风险转移给另一方去承担。3.缓解是指寻求

20、降低一个不利风险事件的发生概率或使它产生的后果达到一个可接受的水平4.接受是指有意识地选择承担风险后果,或者项目组找不出任何风险反应策略。5.风险研究是指通过调查研究以获得更多信息的风险应对策略。6.风险储备是指对项目意外风险预留应急费用和进度计划。7.假如风险影响巨大,或者采取的措施不完全有效,这种情况下就要开发风险退避计划。565.4.5 风险应对过程1.对触发事件作出反应【定期事件、时间、相对变化、阈值触发器】2.执行风险计划3.对照计划,报告进展4.修正与计划的偏差575.5风险管理验证1.评审风险计划:计划的质量一定程度上决定着结果的质量。计划应满足下列要素:完整性、可理解性、详细程

21、度、 一致性、现实性2.审计管理过程【三种标准:ISO9000、SEI-CMM和MIL-STD-498】3.风险管理回报585.6 风险管理实践n以一个教育管理系统项目为例。某教育管理系统项目是一个基于J2EE技术的Web应用项目。它主要为个公司或者一个部门的所有员工提供教育培训的管理。这个项目的需求来自一家大型公司,我们要在规定期限内提交产品,并保证软件的质量。n教育管理系统项目项目被划分成多个较小的模块或单元,分配给项目的各个小组的成员,每个小组成员承担一个或几个任务。59功能分解60风险分析n风险分析是在事前的一种估计,凭借一定的技术手段和丰富的经验,基本能够对项目的风险做出比较准确的估

22、计,经过慎重的考虑提出可行的风险回避措施。下面主要关注软件开发中的主要风险,但是这只是项目风险中的一部分,在资金、预算、合同等方面都存在风险。项目过程中在几乎每个阶段都会出现风险。n正确评估每个阶段可能的风险是保证项目按时按质完成的重要环节。61问题:n请分析软件开发各个阶段的风险62需求分析阶段的风险n以用户的需求开始,以书面的形式形成 用户需求。需求分析更多的是开发方确认需求的可行性和一致性的过程,在此阶段需要和用户进行广泛的交流和确认。需求和需求分析的任何疏漏造成的损失会在软件系统的后续阶段被一级级地放大,因此本阶段的风险最大本阶段的风险最大。63设计阶段的风险n需求分析的不完整和错误,

23、在设计阶段被成倍地放大。设计阶段的主要任务是完成系统体系结构的定义,使之能够完成需求阶段的即定目标;另一方面也是检验需求的一致性和需求分析的完整性和正确性。n设计本身的风险主要来自于系统分析人员。分析人员在设计时过于定制,系统的可扩展性较弱,会给后期维护带来巨大的负担。 n设计阶段蕴涵的另一种风险来自于设计文档。文档的不健全,这不仅会造成实现阶段的困难,更会在后期的测试和维护造成灾难性的后果,例如根本无法对软件系统进行版本升级,甚至是发现的简单错误都无从更正。 64开发测试阶段的风险n软件的实现从某种意义上讲是软件代码的生产。代码本身也是文档的一部分,同时它又是将来运行于计算机系统之上的实体。

24、源代码书写的规范性,可读性是该阶段的主要风险来源。规范的代码生产会把属于程序员自身个性风格的成分引入代码的比例降到最低限度,从而减小了系统整合的风险。65维护阶段的风险n从软件工程的角度看,软件维护费用约占总费用的 55%-70%。对系统可维护性的轻视是大型软件系统的最大风险。在软件漫长的运营期内,业务规则肯定会不断发展,科学的解决此问题的做法是不断对软件系统进行版本升级,在确保可维护性的前提下逐步扩展系统。n在软件系统运营期间,主要的风险源自于技术支持体系的无效运转。科学的方法是有一支客户支持队伍不断收集运行中发现的问题,并将解决问题的方法传授给软件系统的所有使用者。66体系结构方面的风险n

25、本项目采用J2EE技术和三层结构,在技术的成熟度上来说,不存在风险。但是,在实现上,对开发人员的技术要求,以及在实现良好的软件构架和稳定的组件方面,也存在风险性。n软件体系结构影响到软件的如下质量因素:n软件的可伸缩性: n软件的可维护性: n软件易用性: 67项目管理中的风险 1.软件是否能够按工期的要求完成2.软件需求的调研是否深入透彻3.软件的实现技术手段是否能够同时满足性能要求4.软件质量体系是否能够被有效地保证 68风险分级n风险管理贯穿于整个项目生命周期。和其他的软件项目一样,在教育管理系统项目中也存在着许多风险。n我们将风险影响划分为四级,从高到低为:一级、二级、三级、四级,级别

26、越高,表示风险发生后带来的影响越大;同时我们也将风险发生率分为四级,一级最高,级别越高,表示风险发生的概率越大。n下表显示了本项目一部分风险的风险分析表格。 69风险分析表6.6 风险管理实践风险管理实践70例:人员风险控制1、保证开发组中全职人员的比例:且项目核心部分的工作应该尽量由全职人员来担任,以减少兼职人员对项目组人员不稳定性的影响。2、建立良好的文档管理机制:包扩项目组进度文档,个人进度文档,版本控制文档,整体技术文档,个人技术文档,源代码管理等。一旦出现人员的变动,则替补组员能尽早接手工作。6.6 风险管理实践风险管理实践71例:人员风险控制-c3、加强项目组内技术交流:比如定期开技术交流会,或根据组内分工建立项目组内部的开发小组,是开发小组内的成员能够相互熟悉对方的工作和进度,能够在必要的时候顶替对方工作。4、对于项目经理,可以从一开始就指派一个副经理在项目中协同项目经理管理项目开发工作,如果项目经理退出开发组,副经理可以很快接手。高度重要的岗位采用冗余复制的策略来预防人员风险,否则将大大增加项目成本。6.6 风险管理实践风险管理实践725、为项目开发提供尽可能好的开发环境,包括工作环境,待遇,工作进度安排等等,同时一个优秀的项目经理应该能够在项目组内营造一种良好的人际关系和工作氛围。73作业5:n请分析常见的软件风险。n请分析风险的应对策略。74

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 医学/心理学 > 基础医学

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号