软件项目风险的识别与风险的分析

软件项目风险的识别与风险的分析 摘自—项目管理技术 软件开发项目是一项复杂的工程，涉及的因素很多，风险的管理过程有：风险的识别、风险的管理 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 的制定、风险追踪、风险控制。风险识别是风险管理的第一步，而有效的风险分析是进行风险管理的基础，因此做好这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个风险因素，如表所示： 类型 风险因素 类型 风险因素 需 求 风 险 项目的需求不明确，很难界定 计 划 和 控 制 风 险 缺少大量的历史数据作为参考 系统需求不正确 对项目进度估算的不够充分 对系统需求识别得不够充分，有遗漏 对项目资源估计的不够充分 相关人员对系统需求定义存在分歧 没有完善、全面的项目计划 系统需求变动 缺少严格的变更控制和版本控制   对项目执行过程监控不足 技 术 风 险 项目中需要购买未使用过的设备 用 户 风 险 用户不重视项目管理 项目采用的是以前未曾使用过的新技术 用户中部分人员对该项目比较抵触 使用不成熟的技术 缺乏用户参与 对单个开发工具过度依赖 用户对该项目的目标和需求不清晰 项目需要开发大量的接口以连接到其他系统   项目采用的开发方法（如螺旋模型、瀑布模型）不合适。   团 队 风 险 团队内部人员的频繁流动 外 部 风 险 缺乏与顾客的直接沟通 关键人员的离职 与合作方缺乏有效沟通 开发人员缺乏所需专业技能 双方缺乏信任 开发人员不熟悉自己的任务 外部供应商延迟交货 团队内部人员难以沟通 与合作方在进度上的冲突 团队士气低落，工作效率低下 合作方的产品不符合要求   合作方中途终止合约   在某个关键领域依靠外部供应商   双方的企业文化的差异 组 织 风 险 公司资源对项目产生了限制 合 同 风 险 合同类型不合适 缺乏对项目成功 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 的定义 合同条款内容不严谨 缺乏高层管理的支持 合同条款不全面 项目经理缺乏经验，能力不足 存在法律上的漏洞 实施该项目需要大幅度改变组织结构   实施该项目需要较大地改变业务流程或彻底改变部分流程   该项目与企业的发展战略或政策不一致           值得注意的是，尽管可以将风险进行分类，但风险之间总是互相关联的，单独的风险很少发生，因此不能孤立地考虑任何一个风险，因为一个风险类别的组成部分总是影响另一格类别。 2 软件风险的分析 风险分析是在风险识别的基础上估计风险的可能性和后果，并在所有已识别的风险中评估这些风险的价值。这个过程的目的就是将风险按优先级别进行等级划分，以便制定风险管理计划，因为不同级别的风险要区别对待，以使风险管理的效益最大化。 2.1 风险分析流程 根据风险分析的内容，可将风险分析过程细分为2个活动：风险估计和风险评价。通常项目计划人员与管理人员、技术人员一起，进行风险分析，该过程是一个不断重复的过程，在整个生命周期都要有计划、有规律地进行风险分析，分析流程如下图： 2.2 风险的估计 风险估计是估计已识别的风险发生的可能性和风险出现后将会产生的后果，并描述风险对项目的潜在影响和整个项目的综合风险。 风险估计有以下4个环节： （1） 定义风险评估准则 评估准则是事先确定的一个基准，作为风险估计的参照依据。准则有定性和定量两种，定性估计即将肯能性分成等级，如：很大、大、中、小、级小5个等级，一般以不超过9级为宜。定量估计则是给出一个具体的数值，如：0.7表示风险发生的可能性为70%，当然，定量估计还是有其它方法，用模糊数表示风险的可能性就是一种常用的方法。下表给出一个评估准则的例子： 可能性的评估准则 可能性 说明 等级 〉80%（0.8） 非常有可能性，几乎肯定 很大 60%~80%(0.6~0.8) 很有可能性，比较确信 大 40%~60%(0.4~0.6) 有时发生 中 20%~40%(0.2~0.4) 不易发生，但有理由可预期能发生 小 1%~20%(0.01~0.2) 几乎不可能，但有可能发生 很小       风险损失的评估准则 损失 说明 等级 成本 进度 性能 >0.8 成本增加>20% 项目延迟>20% 性能不能满足用户要求 很大 0.4~0.8 成本增加>10%~20% 项目延迟10%~20% 性能有较严重的缺陷 大 0.2~0.8 成本增加>5%~10% 项目延迟5%~10% 主要方面的性能不足 中 0.1~0.2 成本增加>1%~5% 项目延迟1%~5% 性能有缺陷，但基本满足用户的要求 小 <0.1 成本增加<1% 项目延迟<1% 性能有不明显的缺陷 很小           （2） 估计风险事件发生的可能性 根据评估准则对每个风险发生的可能性进行预测，预测的值应该是多人预测的综合结果。 （3） 估计风险事件发生的损失 风险对项目的影响是多方面的，因此损失的估计也应从多方面分别进行估计，通常对三个方面进行估计：进度、成本、性能。 （4） 计算风险值 根据估计出来的风险的可能性和损失，计算风险值（R） R=f(p,c) 式中，p是风险事件发生的可能性，c是风险事件发生的损失。 评估者可根据自身的情况选择相应的风险计算方法计算风险值。 下表是风险评估的例子： 风险 可能性 对进度的影响 对成本的影响 对性能的影响 影响值 需求不明确 0.5 0.3 0.3 0.4 0.5 需求变动 0.9 0.5 0.4 0.2 0.99 关键人员的离职 0.2 0.4 0.2 0.3 0.18 公司资源对项目产生了限制 0.6 0.4 0.2 0.3 0.54 缺少严格的变更控制和版本的控制 0.2 0.5 0.3 0.3 0.22             影响值=可能性*（对进度的影响+对成本的影响+对性能的影响） 对项目风险进行分析是处置风险的前提，是制定和实施风险计划的科学根据，因此，一定要对风险发生的可能性及其后果做出尽量准确的估计。但在软件项目中，要准确地估计却不是件易事，主要有以下几个原因： （1） 依赖主观估计。由于软件项目的历史资料通常不完整，因此，都是根据经验进行估计。而且主观估计常常存在着相互矛盾的问题，例如，某专家对一个特定风险发生的概率估计为0.6，然而，当问及不发生的概率时，回答可能性是0.5。因此许多学者将模糊数学理论引入到风险预测中，以解决预测的可能性和准确性问题。 （2） 人们认知的局限。由于人类自身认知客观事物的能力有限，所以不能准确地预知未来事物的发展变化，这也是导致风险估计主观性的主要原因。 （3） 项目环境多变。项目的一次性特征使其不确定性比其他经济活动达，因此，其预测的难度也较其他经济活动大。也正是这个原因，风险管理应该贯穿整个项目周期。 2.3 风险评价 风险评价是根据给定的风险评判标准（也称风险评价基准），判断项目是继续执行还是终止（出的问题太大）。对于继续执行的项目，要进一步给出各个风险的优先排序，确定哪些是必须控制的风险。 那么，要判断风险的高低，就需要一个标准，只有统一标准，才具有可比性，所以在做风险评价时，评判标准的设定应依据前面所确定的风险的可能性和损失的评估准则，不能自成一体。下表是依据上面几个表格得到的风险评判标准： 风险评判标准 风险值 等级 对应策略 >=0.9 很高. 重点控制 [0.5，0.9] 高 应对 [0.2,0.5] 中 应对 [0.1,0.2] 低 视成本，损失严重程度等因素，决定是否应对 <0.1 很低 接受       从表中可以看出，需求变动的风险很高，需求不明确和公司资源对项目产生了限制2个风险属于高风险，缺少严格的变更控制和版本控制属于中等风险，关键人员的离职属于中等风险，前3个风险必须采取措施应对，最后1个科根据项目具体情况而定。 有时候也直接根据损失的大小来进行评价，但因为软件项目的评价具有多目标性，成本、进度、性能，可靠性和维护性都是典型的评判目标，所以风险评判标准就是这些单一目标的组合，不同的组合就构成了一个参照区域，而某个组合就是其中的一个参照点。 风险评判标准与风险承受能力有关，例如有人认为成本超出10%属于中等风险，可以承受，而有的人认为是高风险，不能承受。个人的风险偏好是风险承受能力的主要影响因素。 3 总结  风险是项目固有的特性，如何及早发现风险、评价风险的大小，确定可接受风险和不可接受风险，是风险管理者亟待解决的问题。