原创力文档- 1、原创力文档（book118）网站文档一经付费（服务费），不意味着购买了该文档的版权，仅供个人/单位学习、研究之用，不得用于商业用途，未经授权，严禁复制、发行、汇编、翻译或者网络传播等，侵权必究。。
- 2、本站所有内容均由合作方或网友上传，本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺！文档内容仅供研究参考，付费前请自行鉴别。如您付费，意味着您自己接受本站规则且自行承担风险，本站不退款、不进行额外附加服务；查看《如何避免下载的几个坑》。如果您已付费下载过本站文档，您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等，请点击“版权申诉”（推荐），也可以打举报电话：400-050-0827(电话支持时间：9:00-18:30)。
- 4、该文档为VIP文档，如果想要下载，成为VIP会员后，下载免费。
- 5、成为VIP后，下载本文档将扣除1次下载权益。下载后，不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后，您将拥有八大权益，权益包括：VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传，每下载1次， 网站将根据用户上传文档的质量评分、类型等，对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
软件项目风险的识别与风险的分析摘自—项目管理技术
软件开发项目是一项复杂的工程，涉及的因素很多，风险的管理过程有：风险的识别、风险的管理计划的制定、风险追踪、风险控制。风险识别是风险管理的第一步，而有效的风险分析是进行风险管理的基础，因此做好这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个风险因素，如表所示：
类
风险因素
类
风险因素
型
型
项目的需求不明确，很难
计
缺少大量的历史数据作
界定
划
为参考
需
系统需求不正确
和
对项目进度估算的不够
求
控
充分
风
对系统需求识别得不够充
制
对项目资源估计的不够
险
分，有遗漏
相关人员对系统需求定义
风
险
充分
没有完善、全面的项目
存在分歧
计划
系统需求变动
缺少严格的变更控制和
版本控制
对项目执行过程监控不
足
项目中需要购买未使用过
用户不重视项目管理
的设备
项目采用的是以前未曾使
用户中部分人员对该项
技
用过的新技术
用
目比较抵触
术
使用不成熟的技术
户
缺乏用户参与
风
对单个开发工具过度依赖
风
用户对该项目的目标和
险
险
需求不清晰
项目需要开发大量的接口
以连接到其他系统
项目采用的开发方法（如
螺旋模型、瀑布模型）不
合适。
团队内部人员的频繁流动
缺乏与顾客的直接沟通
关键人员的离职
与合作方缺乏有效沟通
开发人员缺乏所需专业技
双方缺乏信任
团
能
外
队
开发人员不熟悉自己的任
部
外部供应商延迟交货
风
险
务
团队内部人员难以沟通
风
险
与合作方在进度上的冲
突
团队士气低落，工作效率
合作方的产品不符合要
低下
求
合作方中途终止合约
在某个关键领域依靠外
部供应商
双方的企业文化的差异
公司资源对项目产生了限
合同类型不合适
文档评论（0）