软件开发的需求风险分析 摘要：随着软件开发技术的不断更新、软件数量的不断增多、软件复杂程度不断加大、客户对产品的要求也在不断的提高，随之而来的是市场对软件开发项目需求的不断变化，这便给软件开发企业和需求企业带来的巨大风险。市场对软件开发项目的需求会直接影响到公司的生存。这对软件开发企业来讲应该是更大的难题。本文通过对当前软件行业的需求风险状况进行分析，列举软件开发项目的需求风险来源，并进行分析，总结需求风险产生的原因和对项目成败的影响，最后给出软件开发项目在需求风险管理和控制方面的建议。 关键字：软件开发 需求风险 风险分析
一、对需求风险的理解
产品开发过程中，由于产品需求本身的隐含性、用户与开发者之间的沟通障碍，以及需求随着时间、用户的变化而变更等原因，可能使需求分析偏离实际需求而最终导致产品开发的失败，这种可能性称为需求风险。软件开发项目风险是指在软件生命周期中所遇到的所有的预算、进度和控制等各方面的问题，以及由这些问题而产生的对软件项目的影响。需求分析是软件开发过程中最初始、最基础的工作，也是最重要的工作之一，其成败将直接并最终决定软件开发的成败，并且呈倍增效应。需求分析的关键是使隐含的需求明确，使变更的需求可控，采用座谈会、需求调查表、需求启发、角色扮演等方法可以使需求明确化；采用面向对象的方法及UML工具、领域专家的全程参与、需求分级、二次开发接口等方法可以使需求变更处于可控范围内。实践证明，这些都是控制需求风险的有效方法。
二、需求的获取
（一） 产品前景和项目范围
应该在软件开发项目早期，编写一份包括业务需求在内的前景和范围文档，并将它作为添加新需求和修改现有需求的指导。
（二）需求开发所需的时间
将每个软件开发项目中需求开发所耗费的实际工作量记录下来，这样就可以判断出需求开发是否充分，并可以改进未来项目的工作计划。
（三）需求规格说明的完整性和正确性
为了确保需求是客户真正需要的，应该以用户任务为中心，应用用例技术来获取需求。
（四）创新产品的需求
对软件开发项目中的第1个产品，不太容易把握市场对软件产品的反映。
（五）定义非功能需求
由于我们一般都会强调产品的功能，所以很容易忽略产品的非功能性需求。
（六）客户对产品需求意见一致
确定那些主要的客户，并采用产品代言人的方法，保证有足够的客户代表的积极参与
（七）未加说明的需求
一般的客户会有一些隐含的期望要求，但并未以文档的方式说明出来。尽量识别客户可能做出的任何假设。
（八）把已有的产品作为需求基线来源
把通过逆向工程发现的需求编成文档，让客户来评审这些需求，确保其正确性和相关性。
（九）根据需要提出解决方案
软件产品分析人员必须提炼出隐藏在客户提出的解决方案背后的真正意图。
三、需求风险的来源
软件项目风险经常会涉及许多方面，如：缺乏用户的参与，缺少高级管理层的支持，含糊的要求，没有计划和管理等，这里我们主要分析需求的风险。
很多开发项目在确定需求时都面临着一些不确定性。当在开发项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就能对项目的成功造成非常大的威胁。如果不控制与需求相关的风险因素，就很有可能产生错误的软件产品或者拙劣地建造预期的软件产品。每一种情况对产品来讲都可能致命的。
需求风险的来源包括：没有足够用户参与、不断增加的用户需求 、模棱两可的市场需求 、不必要的特性、过于精简的规格说明 、被忽略的用户分类 、不准确的产品开发计划 。 软件开发项目风险中与客户相关的风险因素有：(一)对软件产品缺少清晰的认识，(二)对产品需求缺少认同，(三)开发者在做需求调查中客户参与不够，(四)市场中没有优先需求，
(五)不确定的需要导致出现新的市场，(六)不断变化市场需求，(七)缺少有效的需求变化管理过程，(八)对需求的变化缺少相关分析等。
四、需求风险的管理
软件开发项目管理人员可以运用对风险管理来提高对造成项目损失的条件的警惕，在市场需求获取阶段要有用户的积极参与。精明的产品开发管理者不但能认识到它能带来风险的条件，而且将它编入风险清单，并依据以往产品开发项目的经验估计其可能性和影响。如果用户一直没有参与，风险危害值将会扩大以至危害项目的成功。即使不能控制项目可能遇到的所有风险，风险管理也能使软件开发项目管理者看清形势，做出的决策是有所依据。
(一)制定风险管理计划
对于一个软件开发项目，你可以把控制风险的计划放在软件项目管理计划里面。但是一个大项目则需要有一份独立的风险管理计划，包括用于识别、评估、编写、跟踪产品开发风险的各种方法与途径。这份计划还应包括风险管理活动的角色和责任。通常情况下，项目小组为他们的关键活动制定了计划，但是在项目中并没有按计划去实施或者没能按实际情况进行及时的调整。一定要坚持按照所采取的风险管理活动计划去执行。项目的进度安排上也应该要给风险管理留出足够时间来确保项目并未浪费早期投资在风险计划制定上面。工程项目的工作分类细目结构中包括降低风险的活动、状态报告，与更新风险清单。和其它项目管理活动一样，需要建立起周期性的监控措施。保持对十来个有最大危害的风险的高度重视，并追踪降低风险措施的有效性。当完成一项活动后，重新评估那项风险的可能性和影响，更新风险清单和其它相关的计划。当控制住原本有很高优先级的风险后，必然有新条目会进入前十条。值得注意的是，不要仅仅因为完成了一项降低风险的活动而人为增加一条风险来进行控制。应当想想降低风险的方法是否真的减少了风险的危害，使它减少到了一个可以接受的水平。
周期性地进行需求风险跟踪可以使项目经理了解风险对软件产品开发项目的威胁，没有得到有效控制的需求风险应该上报高层管理人员，他们可能开始采取一些纠正措施，也可能不管风险，依旧按照原来的业务决策思路进行。即使不能控制项目可能遇到的所有风险，风险管理也能帮助我们看清形势，做出合理的决策。
（二）具体管理措施
1、首先要明确你当前软件开发项目面临的一些与需求有关的风险，不要把当前的问题当作风险，一定要是那些还未发生的事情。将风险的因素编写成文档，为每项需求风险推荐至少一种可能的降低风险的方法。
2、召集代表开发、市场、客户和管理各方面的涉众召开风险“集体研讨”会议。尽力找出更多与需求有关的风险因素。估计每项风险发生的可能性及其影响，两者乘积就是风险危害值。通过按风险危害值降序排列找到最高的五项风险。为每项风险安排一个负责人负责实施
降低风险的活动。
五、结束语
软件开发项目中的需求风险是所有风险中的一个不可忽视的组成部分，对其认识的必要性不言而喻，应该重视对它的分析，对需求风险的合理管理也是软件开发项目项目管理中不可或缺的部分。
参考文献：
[1]黄国光，周勇.软件需求工程,清华大学出版社,2008.(5).
[2]陶履彬.工程风险分析理论与实践，同济大学出版社,2006.(12).
第二篇：软件开发的风险分析与控制
第4卷第2期江南大学学报(自然科学版)Vol.4 No.2 20xx年4月Apr. 2005JournalofSouthernYangtzeUniversity(NaturalScienceEdition)
文章编号:1671-7147(2005)02-0145-05
软件开发的风险分析与控制
王敬昌, 陈根才3
(浙江大学计算机科学与技术学院,浙江杭州310027)
摘 要:为有效防范软件开发失败风险的发生,,定义了风险的种类.提出了风险识别和风险分析的4个主要方面;;提出了风险的量化分析方法、,法,结合软件开发各阶段情况,.
关键词:软件开发;;;中图分类号:文献标识码:A
RiskAnalysisandControlinSoftwareDevelopment
WANGJing2chang, CHENGen2cai3
(CollegeofComputerScience,ZhejiangUniversity,Hangzhou310027,China)
Abstract:Therearealotofrisksinthesoftwaredevelopingprocess.Tocontroltherisk,thesortsofriskaredefinedfromthesoftwaredevelopmentandprojectmanagement.Thepaperpresentsfourmainpartsofriskidentificationandriskanalysis.Therisksduringsoftwaredevelopmentprocessandpossiblesolutionsareanalyzedwhiletheriskquantitymethod,parametermodelandexperiencedataarepresented.Accordingtotheseriskidentificationmethodsandeveryphasesituationofsoftwaredevelopment,thestrategyofriskcontrolisp
roposed.Abouteightypercentriskcanbeidentifiedandcontrolledinthestatisticapplication.Keywords:softwaredevelopment;riskcontrol;softwareprocess;riskmodel
当今社会信息化的程度越来越高,软件需要实
现的功能越来越复杂,软件开发需要大量分工不同
的人员协同完成.软件开发协同化程度的提高,带
来了软件开发更高的风险.风险是指任何可能发生
的对项目的时间、成本、性能或者规模产生消极影
响的事件[1].软件开发风险控制,即为在风险成为
影响软件开发成功的威胁之前,去识别、处理并且
消除风险,保障软件项目开发成功.
收稿日期:2004-06-15; 修订日期:2005-03-02.现在软件企业在开发产品时,总希望能很好地化解风险,达到成功开发的目的.但有一些软件项目在开发过程中经常陷入混乱,导致计划的屡屡推迟,成本不断增加[1],以至于不确定因素越来越多,使整个项目开发组成员感到力不从心,管理层也感到整个项目开发的风险越来越大.这些情况的发生,是由于对软件开发风险控制问题的不重视或认识不足造成的.很多时候,只有在问题发生时才意
作者简介:王敬昌(1977-),男,浙江衢州人,计算机应用专业硕士研究生.
3通讯联系人:陈根才(1950-),男,教授,博士生导师.主要从事软件理论、CSCW技术、协同虚拟环境、智能信息
处理(智能搜索引擎)、数据挖掘等研究.Email:chengc@.
146
江南大学学报(自然科学版) 第3
卷
2)不可预知风险.在软件开发的全过程中,存
识到风险的存在,所以软件开发的风险控制尤值关注.目前,国际上大部分软件企业和理论界都提出
了控制软件风险的要求,很多企业甚至专门建立质量部门对风险进行分析和控制,CMM软件成熟度模型也在很大程度上对风险控制提出了具体要求.但是,许多风险控制方法还都停留在经验或者定性分析层面上,没有进入到量化的分析控制阶段.
风险控制即为依据实际情况,对软件开发项目进行识别、分析和应对的过程.经验表明,需要按照风险识别确认、风险评估量化、计划应对解决这3个步骤来解决[2].在软件开发的各个不同阶段,要采用不同方法控制风险..分析了开发实际情况,数,.
在不可能人为预知的风险,这种风险具有突发性与不可控制性.
风险的识别确认就是根据项目的具体情况,确定风险可能的类别,预测是何种风险以及将会产生的影响范围等,然后进行风险分析,为最后的风险控制提供依据.风险预测是指试图从两个方面评估每一个风险发生的可能性或者概率,以及风险发生以后可能产生的后果.
2,主:①风险事件描述;②风险后果和影响;③风险发生的概率;④风险的描述尺度能力.从以上4个方面关注风险的各种属性及其会产生的影响,以及它们之间的相互关系.
根据实际经验,文中假设了风险的量化参数模型,这个参数模型源于一种失效模式分析(FailureModeEffectsAnalysis)的设计原则[1],对风险的后3个方面分别抽象为发生的影响程度、概率、可检测描述尺度等模型,然后进行风险估计,定义5个级别的风险等级事件,根据分析模型给出了在软件开发中常见风险的严重程度等级列表,见表1.
表1 风险严重程度等级
Tab.1 Thegradeoftheriskseriousdegree影响程度危险高中低小
标准
严重影响软件项目,可能导致项目取消或者直接失败
影响软件项目进度,导致延期,客户严重抱怨
影响软件项目的预算或者软件性能,客户不满意
开发受到影响,但是能够很快解决,客户有轻微不满
对开发有很小影响,客户很难察觉,或者能认同影响
等级
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)=xt,实际经验标明在风险内容确定的条件下,随时间的往后拖延,会越来越严重.定义风险发生的概率,见表2. 定义风险发生的概率为P,影响因素为x,统计分析发现,部分因素对风险发生产生影响的概率很高,基本呈标准正态分布的形式
2
P=φ+e20(x)=
π
第2期王敬昌等:软件开发的风险分析与控制147
如项目变更、技术和业务意见不统一等这些因素是发生风险概率极高的影响因素,部分主要因素成了风险发生概率较高之处.定义风险的检测尺度能力,见表3.
表2 风险发生概率等级
Tab.2 Thegradeofriskoccurprobability
根据上述方法进行风险识别、分析,在项目实际开发过程中获得了良好的效果,大部分开发风险
都能识别定义出来,以引起重视并防范.
3 软件开发各阶段的主要风险
根据风险识别的定义,分析在软件开发各个阶段可能发生的风险,并在实践中表述对这些常见风险的应对方法.
对实际软件开发经验的分析表明:软件开发的,风险发生,,,随着.由日常项目管理评估,假设风险为y,项目整个阶段为x,风险影响结果(风险对项目的损失影响)况假定02y21,02x2
当02x20.
75,f(y)当0.75<x21,f(y)而风险发生的概率k(y)
为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 Tab.3 Therisk2degree
尺度标准等级
10～98～76～54～32～0
极高根本无法检测到风险会发生高中低极低
只要少量或者极细微的特征能够表示风险发生
有部分事实能够表示发生,或者能够被人注意到
有很多证据表面风险发生,并且被大部分人注意到
能够确定风险发生,基本上大家都注意到了风险,并且了解预防措施
调递减趋势,可以假定为k(y)=12xn(02x21).得到曲线如图1.
定义风险的检测尺度为M,对风险的可检测能力只能按概率统计的意义定义.假设分析以往被检测到的概率为y,则y服从日常的经验统计.那么
2
M=f(y)=1/y.
根据上述风险参数模型,结合实际的工作经验,定义了风险的严重程度计算方式,这里定义风险严重等级为R,则
R=f(S,P,M)=S×P×M
根据计算结果R的值,把风险分为5类:灾难性风险、严重性风险、中度风险、轻微风险和可忽略风险,形成风险分析列表,如表4所示.
表4 风险量化与严重程度对比
Tab.4 Riskquantitycontrastwithriskseriousdegree
图1 软件开发各阶段风险发生概率和对项目损失
影响曲线
Fig.1 Theeffectcurveinapiecephaseofriskoccur
probabilityandprojectexpenseinsoftwaredevelopment
以上定义了软件开发的风险分类,给出了风险
参数模型,结合软件开发的具体阶段讨论主要风险
及应对方法.此处的软件开发阶段基于RUP开发的标准模型设置[5],若具体软件的开发阶段有所不同,可参照讨论.
1)软件开发起始阶段.此阶段软件开发一般进行可行性分析、需求分析、部分的业务模型设计、编写软件开发计划等,此时发生的风险属于开发范围风险类别.它可能是:项目范围描述不清楚,界限和目标都不明确;对业务和需求不了解;对系统认识不清,进度和计划安排混乱.这些风险一般属于高级别的风险,有可能导致开发的失败甚至取消.
严重等级灾难性风险严重性风险中度风险轻微风险可忽略风险
R值的范围
1000～200200～5050～2020～22～0
148
江南大学学报(自然科学版) 第3卷
各阶段的情况,在软件开发计划中就应该加入对风险控制的计划,使风险识别控制成为整个开发工作
的一部分
.
具体风险级别可根据具体的项目情况,按照参数模
型进行分析.对这些风险的应对,可采用让客户参加需求分析、业务模型建设、请客户多方面交流、演示DEMO给客户提意见等方法,尽量避免软件项目本身的不清晰带来的风险.
2)软件开发设计阶段.本阶段主要是系统设计完善工作,包括软件架构、系统功能、系统约束、测试方案等,可能会有少量的编码,以验证部分设计.可能出现的风险表现为:对系统功能和架构考虑不周全,导致可能需要进行无数次修改;设计缺少客户或相关验证,导致需要再修改;缺少变更控制,任意按客户或系统的需要修改设计,坏了整体性.
,.认,进行变更控制等.,如设计上有些风险属灾难性的,其埋下的设计问题,可能导致整个项目全部无效,浪费了资源和时间.
3)实施阶段.该阶段进行编码实现工作,包括测试和部分的设计变更,设计补充等.可能存在的风险是:设计错误导致无法进行编码实现;开发团队本身的纪律约束和沟通成为开发障碍,所有成员对设计的理解不一致;模块无法集成;项目突然发生重大变更;开发人员本身的能力导致编码无法继续;测试不能保证良好的验证开发等.
此阶段的风险,大都属于中等风险,需要专业能力解决.如可进行编码培训防止编码混乱带来的风险,召开沟通会议消除对设计的理解不一致等.
4)产品化及结束(收尾)阶段.此阶段是进行产品化包装部署或客户实施安装维护等[6],发生风险的可能性较小,属中度或轻微风险.一般可能的风险有:客户不满意;维护性差等.这些情况可在前面的阶段进行更好的控制来减轻这里的风险,当然也可以进行升级修改的方式.但是这里发生的风险在开始的时候对开发和项目的成败影响达到最大化,然后开始减少.图2表示了在实施阶段测试发现各种问题的代价风险. 以上只是针对开发各阶段进行的各种常见的风险分析,每个开发项目应根据具体情况识别出真正有可能发生在该项目的风险事件,然后按照风险分析和处理的方法进行,达到控制风险的目的.
图2 发现问题的代价风险
Fig.2 Additionalcostoferrors
实践中风险往往会在各阶段的综合情况下发
生,除了在各阶段分析本阶段特征的风险外,在整体项目过程中,较容易发生的风险还有:软件开发失去控制;开发过程混乱,造成难以协调和维护;变更极其频繁;技术人员对技术方案或技术模型的过于自信等.针对这些风险和各阶段的风险情况,要注意风险的防范,做到在风险发生前控制风险,减少损失.风险防范一般遵循风险确认、风险分析量化、风险防范与处理等过程.在整体开发过程中,为了尽可能地减少风险发生,软件开发应尽可能预先定义各种开发纪律和开发规范,使开发活动得到标准检验,增加风险控制能力和识别机会[7].4.1 风险防范
一般在实际开发中,根据项目和风险的具体情况,列出风险列表[8],根据风险列表分析判断风险之后,采用大致4种策略进行风险防范控制:风险规避、风险转移、风险弱化、风险接受.
1)风险规避.通过变更软件项目计划消除风险或风险的触发条件,使目标免受影响.这是一种事前的风险应对策略.例如,采用更熟悉更成熟的技术、澄清不明确的需求、增加资源和时间、减少项目工作范围、避免不熟悉的分包商等.
2)风险转移.不去消除风险,而是将软件项目风险的结果连同应对的权力转移给第三方(第三方应知晓有风险并有承受能力).这也是一种事前的应对策略,例如签订不同种类的合同,或签订补偿性合同等.
3)风险弱化.将风险事件的概率或结果降低到一个可以接受的程度,当然降低概率更为有效.例如,选择更简单的开发流程、进行更多的系统测试、开发软件原型系统、增加备份设计等.
4 风险防范与控制
风险控制,是对风险进行防范或者降低风险损
失.根据风险的识别定义、风险分析以及软件开发
第2期王敬昌等:
软件开发的风险分析与控制149
4)风险接受.表示接受风险.不改变项目计划(或没有合适的策略应付风险),而考虑发生后如何
碑阶段都进行检查和评审,防止开发失去控制,产生风险;同时也可以尽可能早的发现潜在的风险,
并加以控制.
5)进行技术与业务交流.对技术人员对技术的过于依赖和迷恋,应该设法对技术人员的想法进行修正,同时用技术评审和技术模型验证的方式进行确认,让技术人员正确对待技术使用,避免技术偏执造成实际使用效果降低的风险.
6)合理评价技术、方法.规避对技术和方法把握不准的风险.
7),防止产生新的风险.,,可以由具体的情况进行分析应用.
应对.例如制定应急计划、风险应变程序,甚至仅仅进行应急储备和监控,待发生时随机应变.在实际中,如软件项目正在进行中,有一些人要离开项目组,可以制定应急计划,保障有后备人员可用,同时确定项目组成员离开的程序,以及交接的程序.4.2 风险控制
分析软件开发项目管理过程,针对常用的风险控制策略,可从7个方面防范、控制、应对风险.
1)定义合理的软件开发纪律.开发纪律可保障开发人员遵守合理的开发模式,序、标准等内容,.,,防止有,产生风险.
2)定义开发规范.可以定义一系列的开发规范,防止开发混乱,产生交流、沟通上的风险.
3)建立风险管理计划和应对程序.这样可以保证在有风险发生的时候,能够合理、快速的处理风险,避免风险发生时产生混乱的风险.
4)断点检查和里程碑检查.在固定的时间断点(一般建议为两个工作周)和软件开发的各里程
5 结 语
软件开发风险控制是一个重要的课题,计算机软件业的快速发展已将其提到极重要的地位.同时,也需要将风险控制意识贯穿于整个软件开发过程,重视风险、学会正确处理风险,合理规避风险,调整应变成本,将风险发生的可能性减小到最低,也将风险发生带来的损失尽可能降至最低.
参考文献:
[1]JamesP.LewisProjectPlanning,SchedulingandControl,3rded[M].NewYork:McGraw2HillCompanies,Inc.,2001.
163-172.
[2]BarryWBoehm.Softwareriskmanagement:principlesandpractices[J].IEEESoftware,IEEE,1991,8(1):32-41.[3]RichardFairley.riskmanagementforsoftwareproject[J].IEEESoftware,IEEE,1994,11(3):57-67.[4]IEEEStd,IEEE1961-1992,IEEEStandardforaSoftwareQualityMetricsMethodology[S].[5]RationalSoftwareCorporation 1997-2000,RUPStandardforaSoftwareDevelopment[S].
[6]GordonG.SchulmeyerJamesI.McManusHandbookofSoftwareQualityAssurance[M].北京:机械工业出版社,2003.
152-183.
[7]GrahamRobertJ,EnglundRandallL.CreatinganEnviromentforSuccessfulProjects[M].SanFrancisco:Jossey2Bass,
1997.203-289.
[8]MarvinJCarr.Taxonomy2Basedriskidentification[J].TechnicalReport,1993,(6):24.
(责任编辑:彭守敏)