软件项目风险的识别与风险的分析.doc_第1页
软件项目风险的识别与风险的分析.doc_第2页
软件项目风险的识别与风险的分析.doc_第3页
软件项目风险的识别与风险的分析.doc_第4页
软件项目风险的识别与风险的分析.doc_第5页
已阅读5页,还剩8页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

软件项目风险的识别与风险的分析摘自项目管理技术软件开发项目是一项复杂的工程,涉及的因素很多,风险的管理过程有:风险的识别、风险的管理计划的制定、风险追踪、风险控制。风险识别是风险管理的第一步,而有效的风险分析是进行风险管理的基础,因此做好这2个过程的工作是软件项目成功的关键。1 软件风险的识别风险识别过程的活动是将项目实施中的不确定性转变为明确的风险陈述。系统地识别风险是这个过程的关键,识别风险不仅要确定风险来源,还要确定何时发生、风险产生的条件,并描述其风险特征和确定哪些风险事件有可能影响本项目。风险识别不是一次性的活动,应当在项目执行过程中自始至终定期进行。1.1 风险识别的依据 从项目管理角度讲,风险识别依据有:合同、项目计划、工作任务分解WBS、各种历史参考资料(类似项目的资料)、项目的各种假设前提条件和约束条件。 从软件开发的生命周期看,每个阶段的输出(各种文档)都是下一阶段进行风险识别的依据,许多技术风险都可据此来分析。1.2 风险识别方法和工具风险识别的方法很多,不同的方法适用于不同的场合,下表给出了常用的方法的适用情况。识别方法适用情况专家访谈法(Delphi)从定性方面出发进行初步风险识别历史纪录统计法从定性方面对新项目的风险进行预测现场调查法对一些动态风险因素进行识别与预测风险数据库类似项目的风险识别故障树分析法直接经验较少的风险识别流程图法分阶段进行的项目风险识别聚类分析法具有相同或相似属性的风险识别模糊识别法风险的形态或属性不确定软件项目的风险识别通常采用的工具为:(1) 风险核对清单:将可能出现的问题列出清单,然后对照检查潜在的风险。(2) 头脑风暴法:项目成员、外聘专家、客户等各方人员组成小组,根据经验列出所有可能的风险。(3) 专家访谈:向该领域的专家或有经验人员了解项目中会遇到哪些困难。(4) 风险数据库:一个已知风险和相关的信息的仓库,它将风险输入计算机,并分配下一个连续的号码给这个风险,同时维持所有已经识别的风险历史纪录,它在整个风险管理过程中都起着很重要的作用。 在实际应用中,风险核对清单是一种最常用的工具,它是建立在以前的项目中曾遇到的风险的基础上。该工具的优点是简单快捷,缺点是容易限制使用者的思路。1.3 风险种类风险识别出来后应该规整分类,分类可从多种角度定义和划分,一般可按风险引发的原因、项目开发阶段、风险严重程度、风险区东引资等进行分类。下面介绍2种典型的软件风险分类方法。(1)、SEI:1993年SEI发表了基于分类的风险辨识方法(TBQ)。该分类法把系统分为三个类(Class),每个类又分解为若干个因素(elements),每个因素通过其属性来体现特征。(2)、美国空军软件项目风险管理手册:这种方法要求项目管理者根据项目实际情况影响软件风险因素的风险驱动因子,这些因素包括以下几个方面。 性能风险:产品能够满足需求和符合使用目的的不确定程度。 成本风险:项目预算能够被维持的不确定程度。 支持风险:软件易于纠错、适应及增强的不确定程度。 进度风险:项目进度能够被维持且产品能按时交付的不确定程度。笔者借鉴SEI的思想,在大量调查和实践的基础上,结合已有的历史文献资料,对软件项目风险进行了分类和提炼,识别出8类风险,共48个风险因素,如表所示:类型风险因素类型风险因素需求风险项目的需求不明确,很难界定计划和控制风险缺少大量的历史数据作为参考系统需求不正确对项目进度估算的不够充分对系统需求识别得不够充分,有遗漏对项目资源估计的不够充分相关人员对系统需求定义存在分歧没有完善、全面的项目计划系统需求变动缺少严格的变更控制和版本控制对项目执行过程监控不足技术风险项目中需要购买未使用过的设备用户风险用户不重视项目管理项目采用的是以前未曾使用过的新技术用户中部分人员对该项目比较抵触使用不成熟的技术缺乏用户参与对单个开发工具过度依赖用户对该项目的目标和需求不清晰项目需要开发大量的接口以连接到其他系统项目采用的开发方法(如螺旋模型、瀑布模型)不合适。团队风险团队内部人员的频繁流动外部风险缺乏与顾客的直接沟通关键人员的离职与合作方缺乏有效沟通开发人员缺乏所需专业技能双方缺乏信任开发人员不熟悉自己的任务外部供应商延迟交货团队内部人员难以沟通与合作方在进度上的冲突团队士气低落,工作效率低下合作方的产品不符合要求合作方中途终止合约在某个关键领域依靠外部供应商双方的企业文化的差异组织风险公司资源对项目产生了限制合同风险合同类型不合适缺乏对项目成功标准的定义合同条款内容不严谨缺乏高层管理的支持合同条款不全面项目经理缺乏经验,能力不足存在法律上的漏洞实施该项目需要大幅度改变组织结构实施该项目需要较大地改变业务流程或彻底改变部分流程该项目与企业的发展战略或政策不一致值得注意的是,尽管可以将风险进行分类,但风险之间总是互相关联的,单独的风险很少发生,因此不能孤立地考虑任何一个风险,因为一个风险类别的组成部分总是影响另一格类别。2 软件风险的分析 风险分析是在风险识别的基础上估计风险的可能性和后果,并在所有已识别的风险中评估这些风险的价值。这个过程的目的就是将风险按优先级别进行等级划分,以便制定风险管理计划,因为不同级别的风险要区别对待,以使风险管理的效益最大化。2.1 风险分析流程 根据风险分析的内容,可将风险分析过程细分为2个活动:风险估计和风险评价。通常项目计划人员与管理人员、技术人员一起,进行风险分析,该过程是一个不断重复的过程,在整个生命周期都要有计划、有规律地进行风险分析,分析流程如下图:2.2 风险的估计风险估计是估计已识别的风险发生的可能性和风险出现后将会产生的后果,并描述风险对项目的潜在影响和整个项目的综合风险。风险估计有以下4个环节:(1) 定义风险评估准则评估准则是事先确定的一个基准,作为风险估计的参照依据。准则有定性和定量两种,定性估计即将肯能性分成等级,如:很大、大、中、小、级小5个等级,一般以不超过9级为宜。定量估计则是给出一个具体的数值,如:0.7表示风险发生的可能性为70%,当然,定量估计还是有其它方法,用模糊数表示风险的可能性就是一种常用的方法。下表给出一个评估准则的例子:可能性的评估准则可能性说明等级80%(0.8)非常有可能性,几乎肯定很大60%80%(0.60.8)很有可能性,比较确信大40%60%(0.40.6)有时发生中20%40%(0.20.4)不易发生,但有理由可预期能发生小1%20%(0.010.2)几乎不可能,但有可能发生很小 风险损失的评估准则损失说明等级成本进度性能0.8成本增加20%项目延迟20%性能不能满足用户要求很大0.40.8成本增加10%20%项目延迟10%20%性能有较严重的缺陷大0.20.8成本增加5%10%项目延迟5%10%主要方面的性能不足中0.10.2成本增加1%5%项目延迟1%5%性能有缺陷,但基本满足用户的要求小0.1成本增加1%项目延迟=0.9很高.重点控制0.5,0.9高应对0.2,0.5中应对0.1,0.2低视成本,损失严重程度等因素,决定是否应对 0.1很低接受从表中可以看出,需求变动的风险很高,需求不明确和公司资源对项目产生了限制2个风险属于高风险,缺少严格的变更控制和版本控制属于中等风险,关键人员的离职属于中等风险,前3个风险必须采取措施应对,最后1个科根据项目具体情况而定。有时候也直接根据损失的大小来进行评价,但因为软件项目的评价具有多目标性,成本、进度、性能,可靠性和维护性都是典型的评判目标,所以风险评判标准就是这些单一目标的组合,不同的组合就构成了

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论