软件开发的风险分析与控制

第4卷第2期江南大学学报(自然科学版) Vol. 4　No. 2　　　　　　2005年4月Apr. 　2005Journal of Southern Yangtze U niversity(N atural Science Edition) 文章编号:1671-7147(2005) 02-0145-05　

软件开发的风险分析与控制

王敬昌, 　陈根才3

(浙江大学计算机科学与技术学院, 浙江杭州310027)

摘　要:为有效防范软件开发失败风险的发生, , 定义了风险的

种类. 提出了风险识别和风险分析的4个主要方面; ; 提出了风险的量化分析方法、, 法, 结合软件开发各阶段情况, . 关键词:软件开发; ; ; 中图分类号:文献标识码:A

Risk Analysis and Control in Soft w are Development

WAN G Jing 2chang , 　C H EN Gen 2cai 3

(College of Computer Science , Zhejiang University , Hangzhou 310027, China )

Abstract :There are a lot of risks in t he software developing process. To cont rol t he risk , t he sort s of risk are defined from t he software develop ment and project management. The paper p resent s four main part s of risk identification and risk analysis. The risks during software develop ment p rocess and possible solutions are analyzed while t he risk quantity met hod , parameter model and experience data are p resented. According to t hese risk identification met hods and every p hase sit uation of software develop ment , t he st rategy of risk cont rol is p

ropo sed. About eighty percent risk can be identified and cont rolled in t he statistic application. K ey w ords :software develop ment ;risk cont rol ;software p rocess ;risk model

　　当今社会信息化的程度越来越高, 软件需要实现的功能越来越复杂, 软件开发需要大量分工不同的人员协同完成. 软件开发协同化程度的提高, 带来了软件开发更高的风险. 风险是指任何可能发生的对项目的时间、成本、性能或者规模产生消极影响的事件[1]. 软件开发风险控制, 即为在风险成为影响软件开发成功的威胁之前, 去识别、处理并且消除风险, 保障软件项目开发成功.

　　收稿日期:2004-06-15; 　修订日期:2005-03-02.

现在软件企业在开发产品时, 总希望能很好地化解风险, 达到成功开发的目的. 但有一些软件项

目在开发过程中经常陷入混乱, 导致计划的屡屡推迟, 成本不断增加[1], 以至于不确定因素越来越多, 使整个项目开发组成员感到力不从心, 管理层也感到整个项目开发的风险越来越大. 这些情况的发生, 是由于对软件开发风险控制问题的不重视或认识不足造成的. 很多时候, 只有在问题发生时才意

　　作者简介:王敬昌(1977-) , 男, 浙江衢州人, 计算机应用专业硕士研究生.

　　3通讯联系人:陈根才(1950-) , 男, 教授, 博士生导师. 主要从事软件理论、CSCW 技术、协同虚拟环境、智能信息

处理(智能搜索引擎) 、数据挖掘等研究. Email :chengc@zju. edu. cn.

146

　　　江南大学学报(自然科学版) 　　　　　　　　　　　第3

卷　

2) 不可预知风险. 在软件开发的全过程中, 存

识到风险的存在, 所以软件开发的风险控制尤值关注. 目前, 国际上大部分软件企业和理论界都提出

了控制软件风险的要求, 很多企业甚至专门建立质量部门对风险进行分析和控制,CMM 软件成熟度模型也在很大程度上对风险控制提出了具体要求. 但是, 许多风险控制方法还都停留在经验或者定性分析层面上, 没有进入到量化的分析控制阶段.

风险控制即为依据实际情况, 对软件开发项目进行识别、分析和应对的过程. 经验表明, 需要按照风险识别确认、风险评估量化、计划应对解决这3个步骤来解决[2]. 在软件开发的各个不同阶段, 要采用不同方法控制风险. . 分析了开发实际情况, 数, .

在不可能人为预知的风险, 这种风险具有突发性与不可控制性.

风险的识别确认就是根据项目的具体情况, 确定风险可能的类别, 预测是何种风险以及将会产生的影响范围等, 然后进行风险分析, 为最后的风险控制提供依据. 风险预测是指试图从两个方面评估每一个风险发生的可能性或者概率, 以及风险发生以后可能产生的后果.

2, 主:①风险事件描述; ②风险后果和影响; ③风险发生的概率; ④风险的描述尺度能力. 从以上4个方面关注风险的各种属性及其会产生的影响, 以及它们之间的相互关系.

根据实际经验, 文中假设了风险的量化参数模型, 这个参数模型源于一种失效模式分析(Failure Mode Effect s Analysis ) 的设计原则[1], 对风险的后3个方面分别抽象为发生的影响程度、概率、可检测描述尺度等模型, 然后进行风险估计, 定义5个级别的风险等级事件, 根据分析模型给出了在软件开发中常见风险的严重程度等级列表, 见表1.

表1　风险严重程度等级

T ab. 1　The grade of the risk serious degree 影响程度危险高中低小

标准

严重影响软件项目, 可能导致项目取消或者直接失败

影响软件项目进度, 导致延期, 客户严重抱怨

影响软件项目的预算或者软件性能, 客户不满意

开发受到影响, 但是能够很快解决, 客户有轻微不满

对开发有很小影响, 客户很难察觉, 或者能认同影响

等级

10～98～76～54～32～0

1　风险分类

风险识别确认是在风险成为开发问题前认真思考, 将其定义到软件开发计划和过程控制里, 使之成为开发计划和管理的一部分[3]. 在工作实践中, 识别和定义风险最常用的方法就是对风险进行分类. 根据实际开发经验, 风险可有2种分类方式. 1. 1　按风险的内容分类

1) 开发范围风险. 没有明确地描述开发项目的

范围, 将会导致软件开发风险, 甚至导致计划、进度、成本的不可控风险.

2) 质量风险. 没有确认相关的质量技术标准和开发规范、没有准确定义功能标准都可能导致质量风险, 使软件无法达到预期的质量标准[4].

3) 技术风险. 指潜在的设计、实现、接口、验证、和维护等方面的问题, 在技术上存在着未知的或者不确定的领域, 或者技术方案的变化都可能带来巨大的软件开发风险.

4) 组织风险. 组织内部如项目组、企业高级管理层等对项目目标范围存在不一致的理解, 组织战略目标的改变等导致资金、计划安排上带来风险.

5) 人员风险. 项目组成员的变动, 技术人员对业务不理解等, 都可能产生风险.

6) 外部风险. 来自市场的压力, 相关客户主体的变化, 国家政策等产生的风险, 外包项目组的风险等. 1. 2　按风险的可确定性分类

1) 可预知风险. 明确存在或者按照以往开发经验已知的风险, 这类风险往往可以控制和防范;

　　定义风险影响程度为S , 风险本身为x , 时间为t , 假定风险内容确定以后不再受其他因素的影响, 则S =f (x , t ) =x t , 实际经验标明在风险内容确定的条件下, 随时间的往后拖延, 会越来越严重. 定义风险发生的概率, 见表2. 　　定义风险发生的概率为P , 影响因素为x , 统计分析发现, 部分因素对风险发生产生影响的概率很高, 基本呈标准正态分布的形式

2

P =φ+e 20(x ) =

π

　第2期王敬昌等:软件开发的风险分析与控制147

如项目变更、技术和业务意见不统一等这些因素是发生风险概率极高的影响因素, 部分主要因素成了风险发生概率较高之处. 定义风险的检测尺度能力, 见表3.

表2　风险发生概率等级

T ab. 2　The grade of risk occur prob ability

　　根据上述方法进行风险识别、分析, 在项目实际开发过程中获得了良好的效果, 大部分开发风险

都能识别定义出来, 以引起重视并防范.

3　软件开发各阶段的主要风险

根据风险识别的定义, 分析在软件开发各个阶段可能发生的风险, 并在实践中表述对这些常见风险的应对方法.

对实际软件开发经验的分析表明:软件开发的, 风险发生, , , 随着. 由日常项目管理评估, 假设风险为y , 项目整个阶段为x , 风险影响结果(风险对项目的损失影响) 况假定02y 21, 02x 2

当02x 20.

75, f (y ) 当0. 75

为f (y ) , 根据时间情1, 则02f (y ) 21. 21, 并且单调递增. 21, 并且单调递减. 则随着x 的增大, 呈单

可能性极高高中低极低

概率

>50%50%～12%12%～2%0. 01%～0

范围

几乎可以肯定能发生的事情

可能会重复发生的事情偶尔会发生的事情等级

10～98～76～54～32～0

2%～0. 01%很少能发生

表3　T ab. 3　The risk 2degree

尺度标准等级

10～98～76～54～32～0

极高根本无法检测到风险会发生高中低极低

只要少量或者极细微的特征能够表示风险发生

有部分事实能够表示发生, 或者能够被人注意到

有很多证据表面风险发生, 并且被大部分人注意到

能够确定风险发生, 基本上大家都注意到了风险, 并且了解预防措施

调递减趋势, 可以假定为k (y ) =12x n (02x 21) . 得到曲线如图1.

　　定义风险的检测尺度为M , 对风险的可检测能力只能按概率统计的意义定义. 假设分析以往被检测到的概率为y , 则y 服从日常的经验统计. 那么

2

M =f (y ) =1/y .

根据上述风险参数模型, 结合实际的工作经验, 定义了风险的严重程度计算方式, 这里定义风险严重等级为R , 则

R =f (S , P , M ) =S ×P ×M

根据计算结果R 的值, 把风险分为5类:灾难性风险、严重性风险、中度风险、轻微风险和可忽略风险, 形成风险分析列表, 如表4所示.

表4　风险量化与严重程度对比

T ab. 4　Risk qu antity contrast with risk serious degree

图1　软件开发各阶段风险发生概率和对项目损失

影响曲线

Fig. 1　The effect curve in apiece ph ase of risk occur

prob ability and project expense in softw are development

　　以上定义了软件开发的风险分类, 给出了风险

参数模型, 结合软件开发的具体阶段讨论主要风险

及应对方法. 此处的软件开发阶段基于RU P 开发的标准模型设置[5], 若具体软件的开发阶段有所不同, 可参照讨论.

1) 软件开发起始阶段. 此阶段软件开发一般进行可行性分析、需求分析、部分的业务模型设计、编写软件开发计划等, 此时发生的风险属于开发范围风险类别. 它可能是:项目范围描述不清楚, 界限和目标都不明确; 对业务和需求不了解; 对系统认识不清, 进度和计划安排混乱. 这些风险一般属于高级别的风险, 有可能导致开发的失败甚至取消.

严重等级灾难性风险严重性风险中度风险轻微风险可忽略风险

R 值的范围

1000～200200～5050～2020～22～0

各阶段的情况, 在软件开发计划中就应该加入对风险控制的计划, 使风险识别控制成为整个开发工作

的一部分

.

具体风险级别可根据具体的项目情况, 按照参数模

型进行分析. 对这些风险的应对, 可采用让客户参加需求分析、业务模型建设、请客户多方面交流、演示DEMO 给客户提意见等方法, 尽量避免软件项目本身的不清晰带来的风险.

2) 软件开发设计阶段. 本阶段主要是系统设计完善工作, 包括软件架构、系统功能、系统约束、测试方案等, 可能会有少量的编码, 以验证部分设计. 可能出现的风险表现为:对系统功能和架构考虑不周全, 导致可能需要进行无数次修改; 设计缺少客户或相关验证, 导致需要再修改; 缺少变更控制, 任意按客户或系统的需要修改设计, 坏了整体性.

, . 认, 进行变更控制等. , 如设计上有些风险属灾难性的, 其埋下的设计问题, 可能导致整个项目全部无效, 浪费了资源和时间.

3) 实施阶段. 该阶段进行编码实现工作, 包括测试和部分的设计变更, 设计补充等. 可能存在的风险是:设计错误导致无法进行编码实现; 开发团队本身的纪律约束和沟通成为开发障碍, 所有成员对设计的理解不一致; 模块无法集成; 项目突然发生重大变更; 开发人员本身的能力导致编码无法继续; 测试不能保证良好的验证开发等.

此阶段的风险, 大都属于中等风险, 需要专业能力解决. 如可进行编码培训防止编码混乱带来的风险, 召开沟通会议消除对设计的理解不一致等.

4) 产品化及结束(收尾) 阶段. 此阶段是进行产品化包装部署或客户实施安装维护等[6], 发生风险的可能性较小, 属中度或轻微风险. 一般可能的风险有:客户不满意; 维护性差等. 这些情况可在前面的阶段进行更好的控制来减轻这里的风险, 当然也可以进行升级修改的方式. 但是这里发生的风险在开始的时候对开发和项目的成败影响达到最大化, 然后开始减少. 图2表示了在实施阶段测试发现各种问题的代价风险. 　　以上只是针对开发各阶段进行的各种常见的风险分析, 每个开发项目应根据具体情况识别出真正有可能发生在该项目的风险事件, 然后按照风险分析和处理的方法进行, 达到控制风险的目的.

图2　发现问题的代价风险

Fig. 2　Additional cost of errors

实践中风险往往会在各阶段的综合情况下发

生, 除了在各阶段分析本阶段特征的风险外, 在整体项目过程中, 较容易发生的风险还有:软件开发失去控制; 开发过程混乱, 造成难以协调和维护; 变更极其频繁; 技术人员对技术方案或技术模型的过于自信等. 针对这些风险和各阶段的风险情况, 要注意风险的防范, 做到在风险发生前控制风险, 减少损失. 风险防范一般遵循风险确认、风险分析量化、风险防范与处理等过程. 在整体开发过程中, 为了尽可能地减少风险发生, 软件开发应尽可能预先定义各种开发纪律和开发规范, 使开发活动得到标准检验, 增加风险控制能力和识别机会[7]. 4. 1　风险防范

一般在实际开发中, 根据项目和风险的具体情况, 列出风险列表[8], 根据风险列表分析判断风险之后, 采用大致4种策略进行风险防范控制:风险规避、风险转移、风险弱化、风险接受.

1) 风险规避. 通过变更软件项目计划消除风险或风险的触发条件, 使目标免受影响. 这是一种事前的风险应对策略. 例如, 采用更熟悉更成熟的技术、澄清不明确的需求、增加资源和时间、减少项目工作范围、避免不熟悉的分包商等.

2) 风险转移. 不去消除风险, 而是将软件项目风险的结果连同应对的权力转移给第三方(第三方应知晓有风险并有承受能力) . 这也是一种事前的应对策略, 例如签订不同种类的合同, 或签订补偿性合同等.

3) 风险弱化. 将风险事件的概率或结果降低到一个可以接受的程度, 当然降低概率更为有效. 例如, 选择更简单的开发流程、进行更多的系统测试、开发软件原型系统、增加备份设计等.

4　风险防范与控制

风险控制, 是对风险进行防范或者降低风险损

失. 根据风险的识别定义、风险分析以及软件开发

4) 风险接受. 表示接受风险. 不改变项目计划(或没有合适的策略应付风险) , 而考虑发生后如何

碑阶段都进行检查和评审, 防止开发失去控制, 产生风险; 同时也可以尽可能早的发现潜在的风险,

并加以控制.

5) 进行技术与业务交流. 对技术人员对技术的过于依赖和迷恋, 应该设法对技术人员的想法进行修正, 同时用技术评审和技术模型验证的方式进行确认, 让技术人员正确对待技术使用, 避免技术偏执造成实际使用效果降低的风险.

6) 合理评价技术、方法. 规避对技术和方法把握不准的风险.

7) , 防止产生新的风险. , , 可以由具体的情况进行分析应用.

应对. 例如制定应急计划、风险应变程序, 甚至仅仅进行应急储备和监控, 待发生时随机应变. 在实际中, 如软件项目正在进行中, 有一些人要离开项目组, 可以制定应急计划, 保障有后备人员可用, 同时确定项目组成员离开的程序, 以及交接的程序. 4. 2　风险控制

分析软件开发项目管理过程, 针对常用的风险控制策略, 可从7个方面防范、控制、应对风险.

1) 定义合理的软件开发纪律. 开发纪律可保障开发人员遵守合理的开发模式, 序、标准等内容, . , , 防止有, 产生风险.

2) 定义开发规范. 可以定义一系列的开发规范, 防止开发混乱, 产生交流、沟通上的风险.

3) 建立风险管理计划和应对程序. 这样可以保证在有风险发生的时候, 能够合理、快速的处理风险, 避免风险发生时产生混乱的风险.

4) 断点检查和里程碑检查. 在固定的时间断点(一般建议为两个工作周) 和软件开发的各里程

5　结　语

软件开发风险控制是一个重要的课题, 计算机软件业的快速发展已将其提到极重要的地位. 同时, 也需要将风险控制意识贯穿于整个软件开发过程, 重视风险、学会正确处理风险, 合理规避风险, 调整应变成本, 将风险发生的可能性减小到最低, 也将风险发生带来的损失尽可能降至最低.

参考文献:

[1]J ames P. Lewis Project Planning ,Scheduling and Control ,3rd ed[M ].New Y ork :Mc Graw 2Hill Companies , Inc. , 2001.

163-172.

[2]Barry W Boehm. Software risk management :principles and practices[J].IEEE Softw are , IEEE, 1991,8(1) :32-41. [3]Richard Fairley. risk management for software project [J].IEEE Softw are , IEEE, 1994,11(3) :57-67. [4]IEEE Std ,IEEE 1961-1992, IEEE Standard for a Software Quality Metrics Methodology[S].[5]Rational Software Corporation 　1997-2000, RU P Standard for a Software Development [S].

[6]G ordon G. Schulmeyer J ames I. McManus Handbook of Software Quality Assurance[M ].北京:机械工业出版社, 2003.

152-183.

[7]Graham Robert J , Englund Randall L. Creating an Enviroment for Successf ul Projects [M ].San Francisco :Jossey2Bass ,

1997. 203-289.

[8]Marvin J Carr. Taxonomy 2Based risk identification[J].T echnical R eport ,1993, (6) :24.

(责任编辑:彭守敏)