软件项目风险的识别与风险的分析解读.docx

软件项目风险的识别与风险的分析摘自-项目管理技术 软件开发项目是一项复杂的工程，涉及的因素许多，风险的管理经过有：风险的识别、风险的管理规划的制定、风险追踪、风险控制。风险识别是风险管理的第一步，而有效的风险分析是进行风险管理的基础，因此做好这 2 个经过的工作是软件项目成功的关键。 软件风险的识别 风险识别经过的活动是将项目实施中的不确定性转变为明确的风险陈述。系统地识别风险是这个经过的关键，识别风险不仅要确定风险来源，还要确定何时发生、风险产生的条件,并描述其风险特征和确定哪些风险事件有可能影响本项目。风险识别不是一次性的活动，应当在项目执行经过中自始至终定期进行。 风险识别的依据 从项目管理角度讲,风险识别依据有:合同、项目规划、工作任务分解 WBS、各种历史参考资料(类似项目的资料)、项目的各种假设前提条件和约束条件. 从软件开发的生命周期看，每个阶段的输出（各种文档）都是下一阶段进行风险识别的依据，许多技术风险都可据此来分析。 风险识别方式和工具 识别方式适用情况风险识别的方式许多,不同的方式适用于不同的场合, 识别方式 适用情况 专家访谈法（ 专家访谈法（Delphi) 从定性方面动身进行初步风险识 别 历史纪录统计法 从定性方面对新项目的风险进行 猜测 现场调查法 对一些动态风险因素进行识别与 猜测 风险数据库 类似项目的风险识别 故障树分析法 直接阅历较少的风险识别 流程图法 分阶段进行的项目风险识别 聚类分析法 具有相同或相似属性的风险识别 模糊识别法 风险的形态或属性不确定 软件项目的风险识别通常采纳的工具为： 风险核对清单：将可能出现的问题列出清单，然后对比检查潜在的风险。 头脑风暴法：项目成员、外聘专家、客户等各方人员组成小组，依据阅历列出所有可能的风险。 专家访谈：向该领域的专家或有阅历人员认识项目中会遇到哪些困难。 风险数据库：一个已知风险和相关的信息的仓库，它将风险输入计算机，并分配下一个连续的号码给这个风险, 同时维持所有已经识别的风险历史纪录，它在整个风险管理经过中都起着很重要的作用。 在实际应用中，风险核对清单是一种最常用的工具， 它是建立在以前的项目中曾遇到的风险的基础上.该工具的优点是简单快捷,缺点是简单限制使用者的思路。 风险种类 风险识别出来后应该规整分类，分类可从多种角度定义和划分，一般可按风险引发的原因、项目开发阶段、风险严峻程度、风险区东引资等进行分类。下列介绍 2 种典型的软件风险分类方式。 （1）、SEI：1993 年 SEI 发表了基于分类的风险辨识方式 （TBQ）。该分类法把系统分为三个类（Class),每个类又分解为若干个因素(elements），每个因素经过其属性来体现特征。 (2）、美国空军软件项目风险管理手册：这种方式要求项目管理者依据项目实际情况影响软件风险因素的风险驱动因子， 这些因素包括以下几个方面。 性能风险：产品能够满足需求和符合使用目的的不确定程度. 成本风险：项目预算能够被维持的不确定程度. 支持风险：软件易于纠错、适应及增强的不确定程度. 进度风险：项目进度能够被维持且产品能按时交付的 不确定程度。 笔者借鉴 SEI 的思想，在大量调查和实践的基础上，结合已有的历史文献资料，对软件项目风险进行了分类和提炼,识别 出 8 类风险，共 48 个风险因素,如表所示： 类 风险因素 类 风险因素 型 型 需 项目的需求不明确，很难 计 缺少大量的历史数据作 求 界定 划 为参考 风 系统需求不准确 和 对项目进度估算的不够 险 控 充分 对系统需求识别得不够充分,有遗漏 相关人员对系统需求定义 制 风险 对项目资源估计的不够充分 没有完善、全面的项目 存在分歧 规划 系统需求变动 缺少严格的变更控制和 版本控制 对项目执行经过监控不 足 技 项目中需要购买未使用过 用 用户不重视项目管理 术 的设备 户 风 项目采纳的是以前未曾使 风 用户中部分人员对该项 险 用过的新技术 险 目比较抵触 使用不成熟的技术 缺乏用户参加 对单个开发工具过度依靠 用户对该项目的目标和 需求不清晰 项目需要开发大量的接口 以连接到其他系统 项目采纳的开发方式（如 螺旋模型、瀑布模型）不 合适。 团 团队内部人员的频繁流淌 外 缺乏与顾客的直接沟通 队 关键人员的离职 部 与合作方缺乏有效沟通 风 险 开发人员缺乏所需专业技 能 风 险 双方缺乏信任 开发人员不熟悉自己的任 外部供应商延迟交货 务 团队内部人员难以沟通 与合作方在进度上的冲 突 团队士气低落，工作效率 合作方的产品不符合要 低下 求 合作方中途终止合约 在某个关键领域依靠外 部供应商 双方的企业文化的差异 组 公司资源对项目产生了限 合 合同类型不合适 织 制 同 风 缺乏对项目成功标准的定 风 合同条款