软件风险评估

软件风险评估（共12篇）

软件风险评估 篇1

摘要：本文主要针对软件开发涉及到的风险, 包括在软件开发周期过程中可能出现的风险以及软件实施过程中外部环境的变化可能引起的风险等进行评估。在文中对所提到的风险都一一做了详细的分析, 并提出了相应的风险回避措施。由于风险是在项目开始之后才开始对项目的开发起负面的影响, 所以风险分析的不足, 或是风险回避措施不得力, 都很有可能造成软件开发的失败。风险分析是在事前的一种估计, 凭借一定的技术手段和丰富的经验, 基本能够对项目的风险做出比较准确的估计, 经过慎重的考虑提出可行的风险回避措施, 是避免损失的重要环节。

关键词：企业信息化,项目管理,管理变革,风险管理,软件项目风险管理

一、软件项目风险管理

软件项目管理从某种意义上讲, 就是风险管理。我们尽量去定义明确不变的需求, 以便进行计划并高效管理, 但商业环境总是快速变化的, 甚至是无序的变化。所以, 软件企业在进行项目管理的过程中, 必须采用适合自己的风险管理方法进行风险管理, 以确保软件项目在规定的预算和期限内完成项目。

软件项目的风险主要来自于以下三个方面:一是技术风险。包括项目的技术结构、项目的规模以及项目实施方的技术能力和经验。二是管理风险。管理风险主要来自于项目人员的组织有效性, 项目时间、资源的计划确定性和可控性, 以及项目质量监控的力度和立场。三是系统风险。系统在这里指的是由软件开发相关要素组成的动态联系的有机体系。

二、风险评估

风险评估表中所提到的风险是一般项目在开发过程中都客观存在的, 表中所列出的风险系数是指在不对风险进行深入的分析和有效的规避的情况下, 该风险项发生的概率。比如软件产品的设计目标是运行十年, 体系结构不合理的风险是40%的含义是, 如果不对系统进行深入的分析, 未采用最合理的软件技术进行设计, 则生产出一个不具备可扩展性的软件系统的概率是40%。由于客户公司是仍将不断发展的, 在十年内, 该软件系统都能满足公司运营要求的可能性极低。由此而可能产生的灾难性后果是公司在业务发展的时候, 必须重新开发新系统。

向客户提供风险评估, 是按照国际惯例进行的例行操作, 一方面让客户对潜在的风险有更充分的了解, 表明公司诚信为本的态度, 另一方面也用以鞭策和激励全体开发人员严格执行开发标准, 共同监督项目开发过程, 努力避免风险的发生。

多数控制方法的实质是加强开发活动的灵活性, 提高灵活性也提出了软件项目参与各方对软件项目风险大小的认识问题。同样的软件项目风险影响后果, 当参与方, 比如说开发方, 有灵活的手段控制它时, 那么对此软件项目风险的感觉就不是那样的强烈。对需求方也是同样的道理。

由于软件项目风险影响的后果有强弱之分, 所以可以据此设计不同的软件项目风险控制策略。而由基于模糊数学的软件项目评估方法所得出的矩阵见图1可以得出, 根据软件项目风险的影响程度和发生的可能性的大小简单地把软件项目风险划分为4个象限, 并且与软件项目生命周期相对应, 通过这样粗略的划分, 则能看出不同象限中不同策略的特点。

第I象限, 软件项目的初始阶段, 涉及到实际实施软件项目中的风险, 软件项目风险影响的后果不大, 软件项目风险发生的可能性又较高。典型的软件项目风险如不良的软件项目管理习惯、软件项目度量不准确和任务分配不当等。正常情况下这类风险不会威胁软件项目的生存, 至多影响到软件项目质量、进度和成本。即对应的软件项目风险控制的基本策略为软件项目风险缓解策略和软件项目风险接受策略。

第II象限, 软件项目的设计阶段, 软件项目风险影响的后果和软件项目风险发生的可能性程度均较大。

第III象限, 软件项目的实施阶段, 这类软件项目风险通常认为存在于软件项目之外, 但可能在企业外、也可能在企业内。不过有合约总比没合约要强, 有应急的准备总比暂时应付要好。而这种类型的软件项目风险所对应的软件项目风险控制的基本策略只能是风险接受策略。

第IV象限, 软件项目的收尾阶段, 其中软件项目风险影响的后果较大, 但软件项目风险发生的可能性程度不高, 往往软件项目风险控制队列中的前几项也落在这个象限中, 这类软件项目风险的典型例子有:缺乏用户的参与和缺乏高层领导的支持等, 参与各方都因为涉及到外部因素而难以控制。

以上各种应对方案和方法现实中也有交叉使用的情况, 这里所述只能说明在此情况下的主流应对方法。实际上还有不少软件项目风险控制措施基本上没有自接成本, 也就是说, 只要识别到了软件项目风险的存在, 通过及时的沟通、交流就可以避免软件项目风险转变为问题。还有研究表明, 大量的有效沟通和交流甚至不需要文字资料, 当然这更属于有效的软件项目风险控制方法。软件项目风险评估对于软件项目管理是十分重要的组成部分, 它关系了软件项目的成败。本文只是介绍了简单的基于模糊集合的软件项目风险评估方法, 而更深入的研究还有很大的探索空间。

参考文献

[1]、陈和兰, 龚少文.大型软件项目中的组织环境[J].项目管理技术, 2oo4 (12) :65一71

[2]、陈蔚力.估算软件项目周期[J].中国计算机用户, 2003 (4) :19

软件风险评估 篇2

信息技术飞速发展,计算机软件交易市场日趋成熟规范, 我方参照《软件开发和服务项目价格构成及评估方法》，以及,目前国际上通行的也比较科学的估算方法是采用功能点分析方法,使用此方法能够真实、准确地计算出计算机软件的价值以作为市场交易价格的参照依据.价格评估公式:

项目建设费Q=咨询服务费P+项目建设费M(软件开发费D+实施费S+维护费W)+验收测试费C+工程监理费G 项目建设费计算公式:

软件开发费D=工作量(人月)*软件人员月人工费用

=(项目功能点*开发成本系数/7.5/22)*(3.23B)

开发成本系数:3000个功能以下3.5人工时/FP-4.0人工时/FP 3000-8000个功能以下4.0人工时/FP-4.5人工时/FP 实施费S =工作量(人月)*软件人员月人工费用

=(项目功能点*实施成本系数/7.5/22)*(3.23B)分布式实施项目的系数

实施成本系数=开发成本系数*(0.2+(n-1)*k)

比例因子K:0.08<=k<=0.15具体按项目实施难度而定

维护费W=工作量(人月)*软件人员月人工费用

=(项目功能点*维护成本系数/7.5/22)*(3.23B)维护成本系数=(开发成本系数+实施成本系数)*p 比例因子P一般为15%-20%

软件人员月人工费用=(工资+奖金+福利+办公成本+资源储备+基础建设+税收利润)*(1+管理费用百分比)=3.23B

软件开发费D:

软件开发费用指对项目进行详细需求分析,系统设计,编码,测试等方面的工作而需支出的费用,取费主要依据项目规模(功能点),开发成本系数和软件人员月人工费,我方根据(附录四:软件功能说明表),对软件的功能进行分析认为:软件项目难度一般,由于各单位对报表的需求不一,所以编制报表的工作量较多,按照软件规模的大小,我们设定软件开发成本系数为4.软件功能点计算

复杂加权因子表(Complexity weights Factor)

用户输入数EI 用户输出数EO 用户查询表EQ 系数范围 采用系数 3-6 4-7 3-6 5 5 12 6 内部逻辑文件数ILF 7-15 外部接口文件数EIF 5-10 软件功能表

功能 数据表 接口文件 外部查询 逻辑表 报表数 22 5 6 30 5 120

0 12 0

231 5 1155 复杂系数 4 功能点数 88 合计UFC 1393 软件开发费用计算表

计算公式 开发成本系数

UFC*开发成本系数/7.5/22*3.23B 4.0 软件人员平均工资B(上海地区)5000元 软件开发估算价格 实施费S

由于软件项目的实施范围因项目而异,(有些项目只实施一个单位,有些需要实施多个单位),所以实施阶段的费用也会有很大的差异,本项目涉及多家单位,属于分布式实施的项目,实施成本系数与“实施单位数”有关,考虑到单位较多,我们设定比例因子为0.13% 实施费公式S UFC*实施成本系数/7.5/22*3.23B

1393*4.0/7.5/22*3.23*5000=545380.60 实施成本系数公式 开发成本系数*(0.2+(n-1)*k)用户数n 比例因子K 实施成本系数 实施费估算价格 维护费W

软件维护费根据软件工程理论和实际情况,比例因子我们设定为18% 维护费公式S UFC*维护成本系数/7.5/22*3.23B 431 0.13% 4.0*(0.2+(431-1)*0.13%=3.036 1393*3.036/7.5/22*3.23*5000=413943.88 维护成本系数公式 维护成本系数=(开发成本系数+实施成本系数)*p 比例因子P 维护成本系数 维护费估算价格 项目建设费

项目建设费公式 软件开发费D+实施费S+维护费W 项目总费用评估 1132002.89 需求变更费评估

由于软件开发工程中，用户的需求有可能不断变化，从而导致开发工作量的变化，费用的追加，故在立项阶段申请出足够的应付需求变更的经费。

需求变更费=（项目建设费+验收测试费+工程监理费）*需求变更风险系数

本评估书只涉及到软件建设费用的评估,其他费用如咨询服务费,验收测试费,工程监理费都未评估,此软件项目价格评估仅供参考。

参考文献

《软件开发和服务价格构成及评估办法》

《基于COCOMOII模型的软件评估软件-系统设计及实现》

《软件成本估算COCOMOII模型方法》

《通讯软件开发成本评估系统研究》

附录一:软件项目功能点估算方法

附录二:软件人员月人工费用计算方法 18%(4.0+3.036)*18%=1.26648 1393*1.26648/7.5/22*3.23*5000=172678.40 附录三:用户数据统计表

北明软件:规避整合风险 篇3

历时两年，“北明软件2011年的合同额已经达到18亿元，2012年的合同额将超过20亿元。”北明软件董事会秘书何长青介绍说。从业务发展的角度来看，北明软件已经克服了整合当中的重重阻碍，取得了1+1+1+1+1+1>6的效果。并且，在6家公司或团队整合之后，北明软件的整合步伐并没有停止，对新的企业的收购还在进行。

灵活的整合方式

整合从来都是一把双刃剑。整合成功会如虎添翼，整合不好甚至会拖垮原有业务。为了规避整合带来的风险，北明软件采取了灵活和循序渐进的整合方式。

在整合过程里，北明软件将原来的北大青鸟、北大明天、杭州源合、武汉网软的组织结构完全打散，进行了业务和人力资源的整合。对另外两家公司上海艾融、珠海震兴则未进行彻底整合，他们还保持着相对的独立性。以往业内同类企业就曾有过收购之后整合过于激进而导致失败的教训，北明软件吸取其他公司的教训，让整合循序渐进地进行。

“将6家公司重组的难度非常大，但是北明解决得非常好，应该说运作得很成功。”何长青不无自豪地说，“原本也想过用同样的方式整合上海艾融和珠海震兴，但是发现不行，过于激进会适得其反，于是就还让这两家公司作为子公司独立运行。4家公司整合得相对容易，原因是这几家公司的业务比较接近，主要是做系统集成，业务集中在电力、金融、政府等行业。上海艾融和珠海震兴的业务相对独立，其产品形态是软件，与系统集成的销售行为、做事方法有很大不同。艾融的管理体系也已经很清晰，这时候把它整合进来，再套上北明的管理体系，就显得不伦不类，还不如让其自身先发展，只不过在市场层面，大家彼此照应。整合的进度不要过于急迫，不应该以控制为第一目的，而应该把业务发展放在第一位。合并了之后，到底采用什么样的管理体制，是彻底融合，还是独立运作，应该以市场、以业务为重，看哪种方式对业务发展更有利。”

在第一步整合了6家公司之后，北明软件后续的收购更加稳健——先联盟、后收购，这种方式看起来更像是试婚。北明软件先并购目标企业很少量的股权，使两家公司在一起磨合一段时间后，双方确定了共同的发展目标，再进行大规模的股权置换。这种“试婚制度”让北明在全国的整合布局每一步都走得很稳。

克服业务整合的难题

以软件和集成为主的企业，业务整合的难点在哪里？何长青介绍说：“我们整合的几家公司都有系统集成业务，但合作的上游厂商不同。比如，北大青鸟与思科合作，杭州源合与H3C合作，思科和H3C是竞争对手。整合之后，北明软件要同时与两家有竞争关系的上游厂商合作，这很容易产生冲突。最后的解决方式是划分地域，一部分地域做思科，一部分地域做H3C，并与上游厂商充分沟通，得到厂商的理解。”

对组织机构整合和业务整合，何长青积累了多年的经验，“业务整合最大的难题是业务线的重合，如果业务线重合，就会有怎么分、以谁为主的问题。如果原来两家公司做的产品、解决方案差不多，就有可能要放弃一个，以另一个为主。或者整合一下，吸收双方的优点，形成新的解决方案。在北明软件整合的过程里，原来几家公司都做电子政务，那就以原来一家的解决方案为主，另外的就放弃了。”

整合不是一味地做加法，在业务整合的过程里，恰到好处的减法也是必不可少的。

规避最大的风险——人才流失

“软件和集成企业的整合，最大的风险在于人。”何长青指出，“因为这个行业的收购买的不是公司，也不是业务，其实买的就是人，也就是人心。如果在人心这个环节上出了问题，就什么都谈不上了。在软件和集成企业的整合过程中，人的因素最为重要。因为，它不同于传统的制造业，有一些人带不走的东西。但在IT服务行业，人可以带走一切。”

为规避骨干员工流失的风险，北明软件建立了为大家认可的股权分配机制，没有绝对控股的大股东，而是将股权分散在管理层，同时，技术骨干和销售骨干也都持有股份。并且，北明软件还建立了持续的激励措施，这使得整合之后骨干员工相对稳定，在一定程度上保证了整合的顺利进行。

此外，为了防止企业并购之后人才流失给企业带来损失，在知识管理方面也要提前做好准备，及早建立档案管理和技术文档管理，避免出现人走了业务和核心技术也被带走的情况，做到“人走了，业务不走”，这也是非常重要的。

“整合就是要达到1+1>2的效果；但如果仅仅是1+1=2，这样的整合不做也罢。”何长青的态度清晰明确，“北明软件的整合和并购都是在全国范围内进行的，比如，过去一家企业的能力只能将产品和服务在华南销售，整合之后就可以扩大销售范围到华北和华东，这样才能做到1+1>2。但是要真正做到1+1>2，必须将整合的风险防范于未然。也恰恰是这样，北明软件的业务才得以在两年时间内快速增长。”

冠军档案

成立时间：1998年

公司定位：是一家面向多行业的全国性综合IT信息技术服务提供商。

员工人数：1000+

注册资本：6625万元

雷电风险评估软件的设计与实现 篇4

雷电风险评估是根据雷击可能导致人员、财产损失程度来确定防雷保护等级、类别的综合计算、分析方法,是我国雷电业务轨道建设的重要发展环节。目前国内已逐渐形成一套完整的雷击风险评估体系,评估内容涉及大气雷电环境评价、雷击损害风险评估、安全允许距离和环境影响评价、雷电危害识别、防雷安全技术评价、防雷安全管理评估等内容。雷击风险评估的对象除了建筑物及其服务设施,还可以应用到城市分区规划、城市控制性详细规划。

2、风险评估软件的需求分析

雷电风险评估标准技术方法比较复杂,结构庞大,雷击风险评估方法涉及建筑物年预计雷击次数、建筑物入户设施年预计雷击次数以及建筑物电子信息系统因直击雷和雷电电磁脉冲损坏可接受的年平均最大雷击次数等众多参数的分析计算,而这些参数量的计算由于缺乏一个综合的软件处理系统,大多在人工筛选的基础上进行计算,工作量大而繁琐,容易造成误差,从而影响评估结果的准确性和科学性。

3、雷电风险评估软件的设计方法

雷电风险评估软件按如图1所示,主要由建筑物电子信息系统雷电防护等级评估、雷击损害风险评估相关数据、损害概率相关系数评估、可能损失平均数评估、雷电灾害易损性分析五个子模块组成。如图2所示每个模块主要按雷击风险评估类型设定、雷击风险因子设定、雷击风险评估数据处理、雷击风险评估报表输出四种功能设计。雷击风险评估类型设定包括评估对象、评估范围、评估方法、评估标准的确定;雷击风险因子设定包括因子标准值的预置和提取,雷击风险评估数据处理在明确评估方法后,将收集到的相关数据录入系统后,按预先设定的评估公式进行计算,并显示处理结果。雷击风险评估报表将对评估结论进行综合分析,并通过打印机输出分析结果。用户可根据评估报表提出适当的对策与相应的措施。

通过以上每个模块结构及功能分析,利用Delphi 7.0作为开发工具,采用模块化方法进行程序设计,ACCESS构建为后台数据库,实现对评估数据结果的保存、查询、调用。本软件可在windows系列操作系统单机环境下运行,数据实时处理和共享,系统具有安全性高、功能齐全、操作简便、业务数据覆盖广泛、界面清晰友好、系统配置灵活等特点。

4、雷电风险评估软件的数据处理方法

雷电风险数据处理是系统的核心部分,根据国家防雷规范对雷电风险评估的技术要求设定各类雷电风险因子,比如建筑物位置因子(Cd)、环境因子(Ce)、校正系数(K)、材料结构因子等参数。雷电风险因子的取值按照规范中定义的参数设定,通过下拉框控件来实现软件因子值的选取。在确定各类因子值后,用户只需输入被评估单位的建筑物、电源系统、电子信息系统设备等评估对象的现状参数值,系统便根据预定的评估公式进行计算,并给出各类参数的计算结果。图3是数据处理流程图。

5、雷电风险评估软件的使用方法

图4为软件使用主界面,进入主界面后,用户可以按雷电风险评估的类型选择菜单功能。如建筑物电子信息系统雷电防护等级评估、建筑物雷击损坏相关概率评估、建筑物年预计雷击次数相关参数的评估等。下面以建筑物电子信息系统雷电防护等级为例,介绍评估软件的使用方法。

图5为建筑物电子信息系统雷电防护等级评估使用界面,用户按照软件使用界面输入被评估单位的建筑物电子信息系统防雷现状后,系统计算结果如图6所示。用户还可以通过因子选项下拉框任意调整雷击风险因子值,来自动计算雷电防护等级,并根据计算结果提出合理的雷电防护方案。计算结果可以存储在设计好的Access数据库表单中,并通过数据报表格式输出。

6、结束语

软件电子商务质量风险论文 篇5

关键词：软件；质量风险；政府；规制

电子商务扩大了软件的交易形态和交易范围，使软件交易比物质产品便捷和多样化，同时，由于交易流动性增强，交易中的不确定因素也在增加。由于软件是典型的后验产品，使其在电子商务中出现了不同于传统物质产品交易的质量风险，需要政府进行规制。

一、软件电子商务质量风险的生成

软件是后验产品，消费者只有使用它以后才知道它的真实质量，这形成软件交易中严重的事前信息不对称，如果没有良好的信息传递机制，软件市场容易因逆向选择而形成“柠檬”市场。电子商务使软件交易中的信息不对称程度进一步加剧。在软件传统的商务渠道中，供应厂商的品牌、包装、广告及赔偿承诺等，都向消费者传递着软件质量的信息，厂商营销中投入巨额成本及其与销售代理商的合作，都显示着厂商的“实力”与其产品的“层次”。而在Internet上，大大小小的厂商甚至个人都可以花很小的力气(成本)向你推销软件，你的网页上时不时会“飞”来某个软件广告，这些软件的质量信息几乎没有经过“过滤”，参与软件电子商务交易的消费者在搜寻信息成本几乎下降到零的同时，却带来了挑选成本的激剧增加。消费担心的还有，这些“厂商”今天在网上设立软件商店，明天它会不会还存在？更严重的是，这些软件提供者中，还时有发布电脑病毒的“骇客”浑水摸鱼混杂其中，使挑选软件增加了很大的风险成本。所以，如果没有政府进入规制，软件电子商务质量风险将成为Akerlof(1970)所提的典型的“劣质产品市场”，甚至连市场也无法形成。

二、软件电子商务质量风险规制

软件电子商务交易中的质量风险可由市场的内在机制在一定程度上解决，政府的规制作用是使这种风险降到最低，以使软件电子商务交易市场扩大和更有效率。软件电子商务中的质量风险主要由软件交易中严重的质量信息不对称性、网上交易的低约束性和违约惩罚成本的高昂性引起。为此，政府对软件电子商务交易必须针对性地采取相应的规制措施，消除交易双方在交易中的契约力不平衡，创造公平、透明的交易条件。从交易契约理论出发，政府可采取的规制措施包括事前的准入注册，事中的认证评级、信息服务、监控维护和事后的追究惩罚等。

1.准入规制

政府对软件电子商务交易中的供方实行注册登记等准入规制可增加交易的约束性和减少信息的不对称性。软件电子商务交易由于供方在每一个端口均可供货，并且供方可以“跑了和尚又跑了庙”，这给买方带来了交易上的风险，包括产品质量和服务质量上的风险。当买方意识到卖方可能实行一次性交易时，就会担心卖方的道德风险而选择“信用认定”，即在交易前多方搜寻对方的信用信息，或是干脆选择不交易，这增加了交易成本和缩减了市场，加上软件的信息不对称，软件电子商务交易市场将大幅缩水。在没有政府规制的“自由市场”情况下，软件电子商务市场交易的供方将集中在少数“品牌”公司，因为只有这些投入大量的沉没成本去建立起市场信誉的公司才值得买方信赖，也只有这些大公司的雄厚实力才使用户有“庙”可找。所以，软件电子商务市场在没有政府时虽然是个人人均可进入交易，没有限制的“公平”市场，但实际上是个只有大的软件公司才能生存，产生“公平”性失效的市场。由此，政府需要进行准入规制。

政府应该采取怎样的准入规制措施？现代规制理论表明，过严的政府规制将使政府政策替代市场机制，从而导致政府失灵；有效率的政府规制必须是政府的规制措施弥补市场机制的不足，起到扶持和维护市场的作用。简言之，就是政府应永远是裁判员，而不应是运动员，即使是政府的微观规制也只能是“跑着的裁判员”。对每个市场失效，市场本身均有一定的自我修复的内在机制（“免疫力”），软件电子商务市场也如此。例如网上信用认证服务就具有这方面的功能，实际上，VeriSign等网上认证服务公司在国外已经起步发展。因而，政府对软件厂商进入电子商务的规制应该是核准注册制度，而不是审批制度。同时，为适应软件电子商务交易特点，政府需要为用户提供厂商注册信息查询服务，并制订与网络交易相符合的防止软件电子商务交易中价格欺诈或质量欺诈等违法交易行为的法律法规。除此之外，政府所能做的还有对网上软件交易认证服务公司给予税收优惠，以满足软件电子商务中日益增加的产品信息和信用信息需求。2.交易运行规制

在初步确定对方可交易后，软件电子商务交易中的质量风险来自买卖双方之间存在的严重信息不对称，这容易导致软件电子商务市场萎缩或转变成“劣质产品市场”。为克服因质量信息不足产生的逆向选择，在没有政府介入的情况下，产品高质量的厂商将采取信誉培育、高质高价和通过市场中介传递质量信息等措施传递甄别信号，从而减轻市场的失灵。但甄别信息传递过程需要高昂的信息传递费用（对厂商）和鉴别费用（对消费者），交易成本过高会影响市场的交易效率和交易范围，为此需要政府进入软件电子商务市场，提供部分质量公共信息和限制虚假信息的发布，以减少厂商与消费者之间的信息传递和鉴别成本。这里的问题是，政府应如何提供减轻买卖双方信息不对称的服务？

在传统物品质量信息不对称规制上，政府只要采取广告、质量标准等常规的规制措施就可以达到质量价格的均衡从而避免信息不对称下的价格欺诈。而对软件电子商务交易而言，信息不对称程度和传递、鉴别信息的费用显著地高于传统的物质产品，因而要求政府提供更多的规制服务，包括：第一，提供质量信息在线服务。信息具有天然公共品的属性，由政府提供软件质量的相关信息，不仅可显著减少甄别信息的传递费用，而且能减少质量信息的鉴别费用。当然，政府所发布的信息只能限于一些公共、实用而现实的信息，如软件电子商务市场的政策信息、软件真假鉴别的实用技术和鉴别机构、软件质量技术监督部门对市场的监督报告等。这些信息，应以数据库的形式提供在线查询服务。第二，认证和评级。认证评级是政府降低用户鉴别软件质量信息成本的有效规制措施，也是提升高质量软件的信誉度，降低其信誉投资成本的良好措施。限于公共职能和信息不对称，政府认证规制在操作上应以提供准入性和达标性的认证为服务内容，而把其他的认证工作交由市场认证服务公司；评级服务方面，政府可从市场销售额、市场占有率、专利申请数、服务质量、投诉率等方面公布企业“排行榜”，以让消费者对软件企业有个基本的判断。第三，信息监控。鉴于信息不对称中大量信息租金和由此带来的道德风险的存在，政府需要监控企业传递信息的真实性，其中主要是软件厂商在互联网上发布的各类广告和信息是否虚假或是否具有误导性，以及所采取的预防和治理措施。

3.惩罚规制

在软件电子商务交易中，单纯依靠消费者搜集和鉴别信息去减少卖方在质量上的败德行为是很费成本的事情，政府进入规制能有效减少这种成本的支付，从而增加卖方的约束性和减少交易中质量的不确定性。在电子商务中，由于交易存在着部分“虚拟”成分，使法律的执行成本很高，这个特点由于软件交易“边界模糊”的特性而在软件电子商务交易中表现得更为突出。政府在惩罚规制上有两种惩处方法可选择，一是实施高频率的检查规制；二是加大惩罚力度从而相对减少查惩费用。由于网上交易约束性低，查处不容易和法律惩罚成本高，信誉低的公司比信誉高的公司更有积极性选择质量欺诈行为，因而，从维护市场与降低社会成本角度出发，政府需要选择从严惩处的办法。

简短的结论：软件电子商务交易中的质量风险需要政府提供更多的网上在线服务，这种服务应限于公共服务领域而不是替代市场“免疫”机制的作用。此外，为增加交易双方的约束力，减少质量欺诈行为，政府应实行在线的监控惩处机制和加大违规者的惩罚力度。

主要参考文献

[1] C.夏皮罗，H瓦里安.信息规则［M］．北京：中国人民大学出版社，2000.[2] 张昕竹.网络产业·规制与竞争理论［M］.北京：社会文献科学出版

社,2000.[3] G·J·施蒂格勒.产业组织与政府管制［M］.上海：上海三联书店、上

基于客户的软件项目风险规避研究 篇6

摘 要:软件项目开发成功率低是软件行业的共识,主要是因为在软件开发过程中众多的风险因素造成。文章拟从以客户为中心的软件开发思想,以客户为主导的角度研究软件项目风险的规避行为,降低软件项目的风险。

关键词:软件项目;以客户为中心;风险

中图分类号:F407.672 文献标识码:A文章编号:1006-8937(2009)24-0036-02

信息技术的发展促进了软件产业的飞速发展,使得软件产品在众多领域的应用越来越重要。然而,软件产品的开发成功率相对于其它工程项目产品要低得多,这主要是由于软件产品的特殊性造成的,软件产品的特殊性使得软件项目在开发过程中具有众多的风险因素,而且风险因素错综复杂。

从软件项目风险管理的研究成果来看,风险辨识和评估的研究比较丰富和深入,而软件项目风险因素的识别、评估的最终目的是为了能够制订科学的风险管理和控制方法,从而有效地进行软件项目风险管理。然而,如何在风险辨识与评估的基础上采取风险规避行为,文章从以客户为中心的软件开发思想出发,提出基于客户满意度的软件开发能够在一定程度上减少软件项目的风险,即在软件开发过程中,客户满意度越高软件项目成功的概率越大。

1全生命周期的客户风险

以客户为中心的软件项目开发思想是敏捷软件项目管理中的核心思想,时刻与客户保持合作关系,使得客户能参与到软件项目开发中。由于软件是一种特殊的逻辑产品,不具备实体的可见性,它是由经过智力劳动而产生出来,具有特殊物质的复杂事物,因此在软件开发过程中将有众多的不确定因素存在,如客户需求不断变化。采用以客户为中心的软件开发更适用于软件行业,Ilieva et al.(2004)等人在研究敏捷开发中发现:客户在软件开发过程中对开发进程监控,使得项目在签收时受到客户的高度评价,即项目成功。但是Tore Dyb与Torgeir Dings?yr(2008)指出客户在敏捷开发中表现出不持续性将对项目带来更大的风险[1]。

客户风险主要是客户对中间产品或最终产品的不满意,或客户的意见未被采纳或更改,造成产品最终无法满足客户的要求;客户对规划、原型和规格的审核决策周期比预期的长;客户提供的组件质量欠佳等。客户风险体现在软件项目生命周期中的各个阶段。

软件项目在其生命周期中,分为以下四个阶段:需求分析阶段、制定方案阶段、实施阶段与结束项目阶段。

①需求分析阶段。对于软件项目组织来说,该阶段需精确识别客户的真实需求,因此项目组织必需密切与客户沟通,在将收集到的信息加以汇总时对不明确之处反馈于客户,以期客户解答。此阶段中,若客户不予以配合或不完全表达其意思,则软件项目必定失败。项目组织在需求分析过程中,需要时时以客户为中心,使得客户能够顺利方便地参与到项目中,做好软件项目工作的第一阶段。因此,与客户的沟通程度、客户的参与程度将是客户风险在该阶段的体现。

②制定方案阶段。该阶段项目团队的主要任务就是与客户一起制定一个以前期明确的需求、双方的资源、项目开始实施的时间约定、项目费用限制等为基础的具有可操作性的项目计划,从本阶段开始争取客户全面参与项目的管理,需要双方共同考虑项目实施的具体计划落实和风险规避。

③实施项目阶段。此阶段为项目成功的主要阶段,伴随着项目工程的推进,在前两个阶段中不确定性的事件可能会成为该阶段的主要事件,客户在本阶段也会因为外界环境的变化而使得第一阶段中的需求发生改变,如客户所处公司的环境。此时项目团队应实时对客户满意度进行评估,实时了解客户的需求。在本阶段中,客户风险体现在原需求的改变、项目进度达不到客户需要、软件项目的成本、软件项目的质量(如软件界面设计)等。若此阶段项目团队不能与客户密切沟通与合作,客户风险将导致项目的夭折。

④结束项目阶段。此阶段也可以称为软件产品验收阶段,软件项目经理将软件产品交付客户使用。客户对软件产品的满意程度将直接决定是否签收该软件产品,如果客户对软件产品不满意,意味着软件产品的开发失败,修改软件产品将需要更多的成本与时间。因此,客户对产品的质量、成本控制、项目是否延时等问题都将成为影响客户满意度的因素。

2风险规避模型建立

在软件项目全生命周期中,客户风险时刻存在。为了达到客户满意度,采用一般风险管理中常用的规避风险的四个策略:“避免”、“转移”、“接受”、“遏制”和“深入探讨”。所谓“避免”策略是指通过改变产品设计或开发过程,避免或消除风险可能造成的严重后果。“转移”策略常用于保险分担或合同分担,风险出现的概率并没有因此而降低,但是降低了风险出现后某一方遭受损失的程度。“接受”策略指听任风险的自然发展,一方面不需付出风险控制成本,另一方面也没有消除风险可能的危害。“遏制”策略通常有两条途径,一条是加强高风险因素的薄弱环节,降低风险发生的概率;另一条是调整设计方案或管理方法,减轻风险出现后的影响后果。“深入探讨”策略是为掌握风险的具体特性而开展的各项活动,以便取得更多的信息,使风险决策更为科学和明智。

软件项目开发的过程中,软件项目团队与客户保持密切联系,共同处理风险。文章中采用这个四个策略的优先级顺序评估客户对软件项目风险处理的接受程度,达到客户的心理接受风险程度,即客户对软件项目的满意程度。

3 结语

在项目管理过程中,项目的三个主要控制要素:成本、质量、进度。这些要素是每个项目管理中不可获缺的,在软件项目中也不例外。在软件项目中,这三个要素在不同的阶段具有不同的权重,而且其中的任何一个要素的滞后都将带来客户的不满。

软件风险评估 篇7

1. 软件企业在销售软件产品时存在着许多的税收风险, 主要的税收风险有下面几点:

新办软件企业从获利年度起对软件生产企业销售软件产品所获得的即征即退增值税缴纳了企业所得税, 不能享受“二免三减半”的企业所得税优惠政策。

在我国的《财政部国家税务总局关于企业所得税若干优惠政策的通知》中的第一条第一款规定中就提到了:“软件生产企业实行增值税即征即退政策所退还的税款, 由企业用于研究开发软件产品和扩大再生产, 不作为企业所得税应税收入, 不予征收企业所得税。”第二款规定:“我国境内新办软件生产企业经认定后, 自获利年度起, 第一年和第二年免征企业所得税, 第三年至第五年减半征收企业所得税。”虽然通过这个规定, 软件企业可以享受优惠政策, 即享受增值税即征即退政策所退还的税款, 不予征收企业所得税, 并且从获利年度起境内新办软件生产企业还可以享受“二免三减半”的企业所得税。但是, 在实践当中, 企业要想享受这些优惠是要履行一定的法律程序的。

2. 由于在计算软件产品增值税即征即退税额的时候有计算

不准确的现象, 会使得企业多缴纳或者少缴纳增值税, 这就使得软件产业在销售软件产品时有了风险

3. 软件企业在很多情况下不享受营业税的税收优惠政策, 比

如软件企业从事软件开发与测试, 信息系统集成、咨询和运营维护, 集成电路设计等业务收入缴纳了营业税等

二软件生产企业销售软件产品的涉税风险控制策略

为了有效的控制上述所说的涉税风险, 我们必须采取积极的措施来控制涉税风险的产生, 主要要注意一下几点:

1. 建立有担当的主管部门

有担当的软件主管部门是软件生产企业不可缺少的一个部门, 比如科委就是主管部门的一种, 科委可以根据法定程序来办理《软件产品登记证书》或《计算机软件著作权登记证书》, 从而到当地税务主管部门办理税收优惠政策审批手续, 使得涉税风险得到有效的控制。

2. 关注享受增值税即征即退的范围

只有了解了享受增值税即征即退的范围之后, 我们才能明白软件企业是否在享受这个优惠的范围之内, 在《财政部国家税务总局关于软件产品增值税政策的通知》中就规定了增值税即征即退的范围, 我们可以总结成两个方面:

(1) 对于软件企业自行开发生产的软件产品, 应当先按17%税率征收增值税, 然后对对增值税实际税负超过3%的部分实行即征即退政策。

(2) 对于那些进行本地改造后的进口软件产品的销售, 应当对其增值税实际税负超过3%的部分实行即征即退政策。

软件企业应该注意这些范围, 从而维护好自己的权利。

3. 注意软件产品和嵌入式软件产品增值税即征即退税额的计算

根据《财政部国家税务总局关于软件产品增值税政策的通知》我们总结出了软件产品增值税即征即退税额的计算方法:

(1) 即征即退税额=当期软件产品增值税应纳税额-当期软件产品销售额×3%

(2) 当期软件产品增值税应纳税额=当期软件产品销项税额-当期软件产品可抵扣进项税额

(3) 当期软件产品销项税额=当期软件产品销售额×17%

我们对即征即退的增值税税额的计算可以分三个步骤来进行:

第一步:确认销售额, 即对嵌入式软件产品的销售额进行确认

我们在对即征即退的增值税税额进行计算时, 首先要做的就是确认它的销售额, 在确认销售额时, 我们必须要先剔除计算机硬件和机器设备的销售额, 按照相应的次序来进行销售额的计算。在这里还应当注意的是当纳税人按照组成计税价格计算确定计算机硬件和机器设备的销售额时, 我们应在分别核算软件产品与非软件货物或者应税劳务的销售额和进项税额的前提下, 还要注意对嵌入式软件产品与计算机硬件、机器设备部分的成本的核算, 当这些核算不清楚的时候就无法享受优惠政策。

第二步:确认进项税额, 即对嵌入式软件产品的进项税额进行确认

对于进税额的分摊是指纳税人在销售软件产品的同时也销售其他的货物或应税劳务, 他们对那种无法划分的进项税额就应当按照实际成本或销售收入的比例来确定软件产品应分摊的进项税额, 而那些专用于软件产品开发的生产设备和工具的进项税额怎不用进行分摊。

第三步:通过计算嵌入式软件产品的实际税负来确认实现的即征即退的增值税数额

4. 对于进税额的分摊, 应该遵循一定的原则。

首先, 增值税一般纳税人除了主要要销售软件产品外, 还要销售其他货物甚至是应税劳务, 那么这就会相伴产生许多无法划分的进项税额, 对于这部分进税额, 我们就应当按照它的实际成本或销售收入的比例来对确定软件产品的进项税额进行分摊;其次, 还要记住一点就是那些专用于软件产品 (包括不限于用于软件设计的计算机设备、读写打印器具设备、工具软件、软件平台和测试设备。) 开发的设备和工具的进项税额不可以进行分摊;再次, 还要注意分摊方式的备案, 即纳税人将已经选好的分摊方式到主管税务机关进行备案, 且在在一年内不可变更。

三结束语

软件风险评估 篇8

在软件开发项目实践中,常常会遇到某个环节由于种种原因而延期,从而引起与之相关联的后续工序工期的延迟,最终导致整个项目延期、成本增加,严重的还会产生法律纠纷等风险。这说明软件开发项目的工期延误及其产生的风险具有传递效应。

目前,对软件开发项目风险的研究大多还局限于对一些经典风险管理模型的讨论上[1],从风险传递角度对工期延误进行研究的文献尚不多见。刘筱驹,王越等[2]从集成项目的工作任务分解结构(WBS)出发,提出了一种风险传递算法,进行工期风险传递计算,进而得出系统集成项目的总工期风险,并进一步从关键风险单元的识别入手,进行工期风险的调整、优化和控制。王元明等[3]将建筑项目质量风险分为可控性与系统风险两类,从建筑项目的一次性特征角度,分析了建筑项目质量风险的传递机理,并提出了两阶段的可控性质量风险传递模型。赵道致等[4]从风险相关性角度,研究了基于PERT的项目单时段和全时段工期风险的形成以及传递机制,并以事例说明了该方法的具体运用。这些文献要么侧重于对项目工期风险的传递机制进行研究,要么对某类项目工期风险的传递算法进行定性描述,还不能很直观地反映出工期风险从起点到终点的变化程度。本文则从风险传递角度,以某软件开发项目为例,借助模糊集理论,研究软件开发工期风险的传递特性,并对整个项目工期的风险容量进行定量分析与评估,旨在为软件开发项目中的工期风险评估提供一个新思路。

2 风险传递模型的相关概念

文献[4,5,6,7]对风险传递的相关概念进行了介绍。为了更好地理解工期风险传递模型,先引入以下相关概念和定义。

定义2-1 工期风险

项目实际完成工期与所预计的工期出现不一致的现象。工期风险有两层含义:一是指在规定工期内不能在计划工期内完成的可能;二是因为不能按照目标工期完成项目而造成的后果[4]。工期风险记为e。本文主要针对工期风险的第一层含义进行研究。

定义2-2 工期延误率

项目某阶段的合同工期和实际工期之间的变化程度,用△T表示。关系式如下:

undefined

式(1)中Fτ表示项目某阶段的实际工期,Cτ表示项目某阶段的合同工期。

定义2-3 风险传递关系

对于目标对象y,如存在某种对应关系f,使项目阶段的工期风险ei满足:

y=f(ei) (2)

则称式(2)为工期风险的传递关系式,f为工期风险的传递函数。

定义2-4 风险传递系数

项目第i阶段的工期对i+1阶段工期的影响程度[4],用ωi表示。

一般情况下,ωi的取值范围如下:

0≤ωi≤1 (3)

ωi=0表示第i阶段的工期对i+1阶段的工期不产生影响;

ωi=1表示第i阶段的工期对i+1阶段工期产生完全传递,造成工期顺延。

定义2-5 工期风险容量

项目所能容忍的工期与实际工期之间的差距,记为Z。

Z=Cx-Fτ (4)

式(4)中,Fτ表示项目的实际工期,Cx表示项目所能容忍的工期。

Z>说明项目工期在可接受范围内;

Z=0说明项目工期已达到临界,必须引起高度关注;

Z<说明项目工期已不能接受,必须立即采取措施对工期风险进行调整。

3 工期风险传递评估模型

软件开发项目中的工期风险传递,本质上是由于项目中的各环节,在其生命周期各阶段受诸多因素的影响,不可避免地会受到来自内部和外部某些因素对施工时间的干扰,使得这些干扰所产生的不利或不确定性因素,以某种形式进行传递和扩散,进而导致与之相关联的下阶段工期与预期发生偏离。由此可见,软件项目中的工期风险主要来源两个方面[7]:一是外部环境变化所造成的风险(E);二是某阶段内部环境变化所造成的影响(S)。工期风险的传递如图1所示。

工程实践中,由于在项目各工序内部以及工序与工序之间实施相关的风险控制[2],如图2所示。这使得工期风险在项目各阶段之间的传递过程并非表现出简单的递推关系,即:某阶段的工期延迟并不一定造成下阶段工期的如数顺延。因此,文献[2]所描述的工期风险传递算法则不尽全面。对一个完整的项目工期风险,不仅要考虑项目某阶段的工期延误率,还必须考虑到风险传递系数对下阶段工期的影响。

图2中,假设项目每阶段的工期风险e1,…,en,对整个项目工期所造成的风险遵循并行和串行的关系[2]。考虑到项目某一阶段活动所产生的工期风险对紧邻的下一阶段工期风险的传递系数,根据定义2-2和定义2-4,则,软件项目工期的传递风险关系式如下:

undefined

式(5)中,对项目最后一道工序的工期风险en而言,取ωn=0。

4 算例分析

4.1 算例说明

某高校有一个OA软件开发项目。经过项目前期大量的调研和论证,以及政府招标程序后,于当年的6月20日进入项目的启动阶段。按照合同约定,项目启动后各阶段的工序以及各工序的合同时间如图3所示。根据学校要求,考虑到9月1日有大量学生入学,有课表查询、缴纳费用等需要,学校对新系统建设所能承受的工期最迟不能超过8月31日。

4.2 工期风险评估应用

4.2.1 建立工期延误率△T的模糊评估集。

设延误率△T的模糊评估集V={很高,高,中,低,很低},V中各因子的取值以及所对应的特征描述如表1所示。延误率越高,则新系统延期交付的可能越大,产生的风险越高。

4.2.2 建立风险传递系数的模糊评价集。

设风险传递系数ω的模糊评价集ω={很高,较高,一般,较少,无影响},ω的取值以及所对应的控制措施和特征描述如表2所示。风险传递系数ω越高,工期延误对下阶段的影响越显著。

4.2.3 工期风险的传递影响评估。

图3中,本OA项目启动的标志环节是软件开发。由工程实践可知,软件开发阶段的工期风险主要在于目标及需求的变化或项目立项时的需求不明晰[8]。为此,在项目前期阶段,可通过多次召开座谈会,采取让学校各职能处室、老师、学生代表等参与需求分析、业务模型建设、针对演示DEMO的多次反馈意见等方法,以减少软件开发阶段由于需求的不明晰而返工造成的工期风险[9]。一旦项目进入启动阶段,要尽量减少需求的变化,如果有,也将需求变化控制在1/3范围内,如果有1/2的项目需求发生变化,则采用项目2期的方式对该系统的功能加以拓展。在数据移植阶段,由于OA系统会涉及到数据的迁移和录入,尽管工作量大,但发生工期延误的可能性不高[9]。在用户培训阶段,只要组织得力,建设方与用户配合默契,该阶段发生工期延误的可能性很小。竣工验收作为本项目的最后阶段,按照式(5)的说明,取工期风险传递系数为0。由以上分析,结合表1和表2的内容,将图3中各阶段的工期延误率△Ti以及风险传递系数ωi列表如下。

由式(5)可算出整个OA项目的实际工期Fτ

Fτ=67.8≈68天 (6)

由图3和§4.1的内容可知,该OA项目的合同工期Cτ=61天,项目建设方对项目所能容忍的工期Cx=72天。

由式(4)可算出该项目的工期风险容量

Z=Cx-Fτ=4天 (7)

式(7)说明,在考虑软件开发项目风险控制的前提下,该项目各阶段所导致的工期延长对整个项目的影响不大,其风险在可接受的范围内,即:该项目从当年的6月20日启动,可在8月28日前将系统交付使用。

5 结束语

软件开发项目中的工期风险传递受诸多因素影响,涉及到众多环节,这些特点客观上给工期风险的评估带来许多不利影响。本文只是在前人工作的基础上,结合软件开发工程实践,提出一个简单而实用的项目工期风险传递评估模型,期望为软件开发项目风险的控制决策提供一个思路。

参考文献

[1]牟玲玲,陈立文,张建军.软件项目风险管理研究综述[J].计算机工程与应用,2007,43(10):202-205.

[2]刘筱驹,王越.系统集成项目的工期风险传递算法及评价控制[J].运筹与管理,2004,13(1):38-43.

[3]王元明,赵道致.建筑项目质量风险传递模型与控制研究[J].商业经济与管理,2008,200(6):15-20.

[4]赵道致,王元明.基于PERT的项目工期风险传递机制[J].工业工程,2008,11(4):14-18.

[5]简大鹏.网络系统安全性评估技术研究[D].哈尔滨工业大学博士论文,2008.

[6]李存斌,王恪铖.网络计划项目风险元传递解析模型研究[J].中国管理科学,2007,15(3):108-113.

[7]王元明,赵道致,徐大海.项目供应链的风险单向传递机理及其对策[J].北京交通大学学报:社会科学版,2009,8(4):47-52.

[8]项目实施过程中的风险控制[EL/BO].http://www.javaeye.com/topic/522412,2009-11-22.

论软件项目风险管理 篇9

1 特点

(1)风险的不确定性和损失性。任意具体风险的发生都是诸多风险因素和其他因素共同作用的结果,是一种随机现象。个别风险事故的发生是偶然的、杂乱无章的。

(2)风险的可变性。这是指在项目实施的整个过程中,各种风险在质和量上是可以变化的。随着项目的进行,有些风险得到控制并消除,有些风险会发生并得到处理,同时在项目的每一阶段都可能产生新的风险。

(3)风险的多样性和多层次性。大型开发项目周期长、规模大、涉及范围广、风险因素数量多且种类繁杂,致使其在全寿命周期内面临的风险多种多样。而且大量风险因素之间的内在关系错综复杂、各风险因素之间与外界交叉影响又使风险显示出多层次性。

2 管理过程

2.1 风险分析

通过风险识别过程所识别出的潜在风险数量很多,但这些潜在的风险对项目的影响是各不相同的。“风险分析”即通过分析、比较、评估等各种方式,确定各风险的重要性,对风险排序并评估其可能后果,从而使项目的整体风险得到有效的控制。

风险分析的结果能够给出项目管理过程中某一危险发生的概率以及其后果的性质和概率,一般关于概率有客观概率和主观概率之分,客观概率的计算方法有两种:一种是根据大量试验用统计方法进行计算;另一种根据概率的古典定义,将事件集分解成基本事件,用分析的方法进行计算。但在实际工作中经常不可能获得足够多的信息,因为通常对遇到的风险事件都不可能作大量试验,所以不能作出准确的分析,也就很难计算出客观概率,这时只能由决策者或专家对事件出现的可能性作出估计,这就是主观概率。风险分析主要可采用风险概率/影响评估矩阵、敏感性分析、模拟等方法。

2.2 应对策略

制定风险应对计划时有多种不同的策略,对于不同的风险,采用不同的应对策略会有不同的方法。

(1)制定科学的风险管理计划。从风险管理的角度对项目规划或计划进行审核,建立“风险清单”,对每个可能存在风险的表现、范围、时间做出尽量准确的判断并对风险进行监控,提前做好应对准备。

(2)选择合适的开发技术。虽然在系统设计时需要考虑新技术的发展和技术的先进性问题,但最好的不一定是最合适的,如果项目组的人员对所需开发技术不熟,在满足业务需求的前提下,尽可能采用熟悉的技术来减轻项目在成本或进度方面的影响,也可以事先进行培训来减轻对项目的影响,以避免因技术瓶颈导致的项目失败。

(3)采用快速原型和迭代模型进行开发。应用部门的需求往往会随着时间的推移、业务发展的变化而有所变化,因此,技术部门要强调敏捷开发,缩短软件第一版本的上线周期,尽快给用户一个快速原型启发用户的需求,并持续为用户提供有价值的软件。

2.3 风险跟踪与监控

风险监控的主要目的是评估一个被预测的风险是否真正发生了;保证为风险而定义的缓解步骤被正确地实施;收集能够用于未来风险分析的信息。在很多情况下,项目中发生的问题可以追溯的不止一个风险,风险监控应该试图在整个项目中确定风险的起源。风险跟踪的目的是根据项目最新情况修正风险列表中的数据。风险跟踪主要包括重新评估风险、过程审计、分析项目的偏差情况、进展情况和储备情况。

风险监控主要包括以下几方面的任务:

(1)在整个项目过程中,时刻监督风险的发展与变化情况,确定伴随某些风险的消失而来的新的风险并制定相应的处理措施。

(2)保证风险应对计划的执行并评估风险应对计划执行效果。评估的方法可以是项目周期(阶段)性回顾、绩效评估等。

(3)对突发的风险或“接受”的风险采取适当的权变措施。

通过风险监控过程,项目人员持续更新项目风险列表,并通过重复上述各步骤保证项目风险始终处于受控状态。

3 结语

在项目开发过程中,一个成功的风险管理可以防止和减少项目中潜在问题的影响,当风险没有出现时,风险管理有助于降低风险发生的概率或转移风险,减小风险损失;当风险出现时,风险管理有助于预测到风险并迅速做出反应,从而减小风险对整个项目所造成的影响。

摘要：风险管理一直是软件项目管理中的重点和难点问题。对风险的定性/定量分析、制定风险应对策略、风险跟踪与监控进行了深入的研究,对项目管理过程中的风险问题做了全面的阐述。

关键词：风险跟踪与监控,风险管理,风险分析

参考文献

[1]郑人杰.实用软件工程[M].北京:清华大学出版社,1991,2:1-20.

[2]李美华,付宏.软件项目风险评估模型的建立[J].吉林大学学报(信息科学版),2005,23(6):696-701.

[3]张珞玲,李师贤.软件项目风险管理方法比较和研究[J].计算机工程,2003,(3):91-94.

[4]覃征.软件项目管理[M].北京:清华大学出版社,2004.

软件项目风险形成机制研究 篇10

1 文献综述

目前关于软件项目风险的研究, 在软件项目风险因素分析方面, 常金玲[3]基于项目实践和软件工程原理, 将软件系统开发风险归纳为7个大类、36项风险因素;张天宇等[4]在分析软件企业项目开发特点的基础上, 提出软件项目开发的关键性风险因素, 并对其进行风险评估。在软件项目风险管理方面, 潘春光等[5]总结了Boehm和Charette的风险管理框架、Higuera和Haimes的持续风险管理框架模型、Hall的六学科风险管理模型以及基于CMM/CMMI的风险管理框架等;还有一些学者在软件项目风险分析基础上提出相应的风险管理方法[6,7]。现有研究很少有从软件项目风险形成的根源和形成机制方面进行, 而分析软件项目风险的形成机制对于认识和管理项目风险具有重要的意义。基于此, 本文在分析软件项目风险及特点的基础上, 研究其形成根源, 然后在此基础上构建软件项目风险的形成机制, 不仅有助于丰富和完善软件项目风险管理的研究成果, 也可为软件项目的顺利开展提供保障。

2 软件项目风险的类型与特征

软件项目属于智力密集型和劳动密集型产品, 技术性强, 在项目开发的各阶段都需要细致、复杂的手工劳动以及高强度的脑力劳动, 受人的因素影响较大;另外, 由于软件产品的抽象性以及用户需求的不稳定性, 使得项目目标难以明确、任务边界较为模糊, 项目的质量、进度和成本也很难度量。因此, 与传统项目相比, 软件项目的风险更为复杂。根据软件项目的开发流程, 可将其划分为五个阶段, 各阶段的风险具体见表1所示。

由此可见, 软件项目风险的特点主要有:

(1) 随机性。风险是不以人的意志为转移并超越人们主观意识的客观存在, 由于软件项目需求的不确定性、系统设计和实施的复杂性等, 使得风险发生的时间、持续时间及风险后果的出现表现出随机性。

(2) 复杂性。软件项目特别是一些复杂应用项目开发周期长、涉及面广, 在整个过程中面临多种多样的风险, 而且, 这些风险因素之间还存有复杂的关系, 使得项目风险的复杂性非常显著。

(3) 动态性。软件项目在开发的不同阶段会有不同的风险, 这些风险随着时间的推移不断变化并具有传递效应, 而且风险的影响效应还可能会在传递中不断积累和放大, 对整个软件开发过程产生致命影响。

(4) 损失性。如果软件项目各阶段的风险没有消除, 甚至连试图降低风险的努力都没有, 这时潜在风险就会变成真正风险甚至是现实, 从而造成实施效果下降、预算超支或实施周期延长等恶性后果或损失。

3 软件项目风险的形成根源

3.1 软件项目的复杂性

软件项目作为一个复杂巨系统, 其复杂性主要来自技术的复杂性、组织环境的复杂性和项目管理的复杂性。

3.1.1 技术的复杂性

技术是实现软件产品所用到的具体手段和方法, 也是实现软件产品的基础。在这方面, 软件产品与计算机、汽车或建筑存在很大的差别, 因为后者在开发中往往会有大量的重复部分, 计算机系统虽然也较为复杂, 但软件系统比计算机系统更复杂, 在软件实体扩展中不仅是相同元素的重复添加, 更是不同元素的添加, 而且这些元素还以非线性递增的方式交互作用, 使得软件开发技术的复杂度以更大的非线性级数增长。另外, 王连成[8]提到, 复杂产品开发的复杂性主要是源自其开发过程固有的无序性, 这种无序性表现在两方面:一是过程阶段间的反向影响性, 即后一阶段的开展需要以前一阶段的实现为其提供条件的同时又会反过来对前一阶段或以前若干阶段的活动提出变动要求;二是开发活动并行的不协调性, 即同一阶段的活动在同时开展过程中存在着相互影响, 一些活动的中间或最后结果可能影响另外一些活动方式的条件。

3.1.2 项目管理的复杂性

项目管理主要涉及项目的范围管理、时间管理、质量管理、沟通管理和人员管理等。在范围管理上, 由于软件是一种抽象的逻辑实体, 在签署项目合同时, 大多条款是关于功能概要上的描述, 很难对具体范围进行详细描述, 再加上需求变更频繁, 使得范围管理更加复杂;在质量管理上, 除了因功能描述不清等而导致的质量管理复杂外, 还有因用户满意度要求提高、项目管理范围扩大而与之相应的质量标准体系还不是很成熟等, 造成质量管理难度较大;在人员管理上, 由于软件项目及其开发工作的特点, 制定一个既重视财务指标和客户满意度指标, 又能突出人员创新和团队协作方面的指标就显得很重要, 而均衡与协调的管理方式是较为复杂的;在沟通管理上, 由于常出现项目组与客户之间因项目范围的变更而起争执、项目组成员间因意见不合而产生冲突等, 使得项目经理不得不花费大量的时间和精力去沟通协调;在时间管理上, 由于软件项目是不可见的, 再加上是以人的脑力劳动为主, 估算出的时间与实际项目进度存在较大的差异, 从而增加了项目时间管理的复杂性。

3.1.3 环境的复杂性

环境是指存在于项目内外并影响项目绩效的各种力量和条件的总和, 可分为外部环境和内部环境两方面。外部环境包括政治、经济、法律和技术等一般环境, 以及竞争者、用户、供应商和新进入者等任务环境, 前者由于各要素的异质性或多样性以及要素间的相互作用增加了项目分析与实施的复杂性, 而后者由于所涉及的各利益相关者较多且差异较大, 增加了彼此交互的复杂性, 影响项目进展。内部环境的复杂性则主要体现在三个方面:一是内部环境系统结构的复杂性, 软件项目开展时一般都设有若干项目小组, 每个小组内又含有各种不同专业背景的人员, 这些人员及小组需要密切配合与协调;二是内部环境系统内部关系的复杂性, 即各子系统之间构成一个关系复杂的网络并具有广泛而紧密的联系, 一个子系统的变化往往会作用到其他子系统, 而且这种作用是非线性的;三是内部环境的智能性, 软件项目的原材料是人的思想和智慧, 因此项目的内部环境就是一个人工智能系统, 具备适应、调节、学习和发展的能力, 进而增加了管理工作的复杂性。

3.2 人的认识能力的局限性

软件项目属于“知识转移型”产品, 受人的因素影响较大。根据人类认识论观点, 人们在认识能力上的局限性使得任何人不管多么努力也无法全面预见未来而成为所谓的“先知先觉者”。因此, 人的认识能力的局限性使得人在项目实施中总会出现这样或那样的失误和错误, 而这些失误和错误正是导致项目风险形成的主要原因之一。一般, 影响人的认识能力的因素主要有:

(1) 物质手段, 即物质形态的认识工具, 是人类为了突破自身认识器官的局限而有目地制造出来的各种物质工具的总和。在软件项目开发中, 这类认识工具包括软件需求工具、软件设计工具、软件构造工具、软件测试工具、软件维护工具和软件工程管理工具等。虽然这些工具降低了开发人员的工作难度, 提高了对软件产品的认识能力, 但开发工具的功能并不是想象的那样强大, 而且现有工具的发展应用跟不上时代要求, 如许多测试工具仍是就问题论问题, 缺乏统一性和通用性。

(2) 方法论手段, 即观念形态的认识工具。康德认为, 虽然认识起源于感觉, 但仅靠感觉是不会形成关于对象的认识, 要保证认识的客观和有效, 还需依赖于人所具有的先验认识能力, 需要整理、联结和规范感性材料。也就是说, 认识中形成的理论和方法对认识活动起着重要的作用。在软件项目开发中, 软件开发方法也一直不断演变, 如结构化软件开发方法、面向对象的软件开发方法、基于PUP的软件开发方法、基于构件的软件开发方法、敏捷性软件开发方法以及面向Agent的软件开发方法等。然而, 由于环境的变化以及软件开发中新问题、新情况不断出现, 使得现有软件开发方法离人们所追求的高效率和高质量还存在很大的差异, 这也决定了当前软件开发方法应用的有限性以及演变的无限性。

(3) 人的生理基础。健全的感官器官、神经系统和大脑是人开展认识的前提基础, 但这些生理条件只是为人的认识活动提供了生物学上的可能性, 即它是必要条件而不是充分条件。也就说, 只有人们经过大量的社会实践和社会交往, 掌握了各种知识结晶和认识形式后, 认识活动才能成为现实, 大脑和感觉器官也才能成为真正的认识器官和认识基础。然而, 现实中, 人的时间和精力是有限的, 而历史积累下的知识成果是广泛的, 而且还在不断出现新的知识。同样, 在软件开发时, 从需求分析、方案设计、编码到测试等, 涉及多个方面的专业知识, 人们在精通某一专业知识时, 其他知识难免就会相对缺乏, 而软件项目作为一个复杂系统, 各模块及子系统间具有很强的耦合性, 任何相关问题都可能导致整个系统的故障。

3.3 项目的不确定性

不确定性是指引入时间因素后事物的特征和状态不能充分地、准确地加以观察、预见和测定。一般项目的不确定性既包括项目内在不确定性和项目外在不确定性。

3.3.1 项目内在不确定性

软件系统的开发本是为了解决现实问题和减少现实系统的不确定性而存在的, 但自身的产生过程却充满了诸多不确定性, 具体有:

(1) 需求分析的不确定性。软件需求分析主要是研究问题, 了解用户的真正需求以及解决问题存有的约束, 然而, 人们在软件系统开发之前是不可能准确地把握当时的需求以及其未来的走势, 这一点已被Wegner[9]利用数学方法给出了严格的证明。

(2) 从需求到设计和编码转换的不确定性。软件项目不同于传统的建筑项目, 需要在多个抽象层次表述系统, 如需求分析模型、设计模型和源代码执行模型等。在这些不同抽象层次间转换时常会引入不确定性, 如设计模型是否忠实于需求分析模型、概念模型在编码中是否被编码人员正确理解等。

(3) 重用项目成果的不确定性。重用已有项目成果从理论上讲可以回避前面两方面的不确定性, 但在实践中仍会引入很多不确定性, 如:重用构件的接口描述是否准确和完整;可重用构件或子系统是否满足当前应用的要求;给定一个重用构件, 如何调整以满足现有系统的约束条件等。

(4) 测试工作的不确定性。在制定测试计划时, 需要确定待测试的产品, 而这种产品主要包括需求说明、设计文档和源代码, 它们在测试前就已渗入了不确定性, 这种面向未来的测试计划只会将这种不确定性进一步放大;在开展测试活动时, 一般, 该活动开展的假设前提是在理想环境下, 因为只有这样才能确保测试过程与结果的可靠性, 但理想测试是不可能的。

(5) 项目管理的不确定性。项目管理活动与一般管理活动类似, 也涉及计划、组织、领导和控制, 由于人的因素和软件项目特点, 不可避免地会引入不确定性, 如:在计划和决策中, 是否权衡考虑了所有因素并识别出各因素取值是代表其真实状态;在组织中, 人员配置是否得当;在领导中, 项目组各层次沟通是否畅通;在控制中, 管理者是否清晰技术层面的实际进展等。

3.3.2 项目外在不确定性

项目外在不确定性, 即项目所处的外部环境的不确定性。根据Miller[10]的划分, 可将外部环境的不确定性划分为六类:宏观经济的不确定性、政府政策的不确定性、产品需求与市场的不确定性、资源与服务的不确定性、技术的不确定性和竞争者行为的不确定性。在经济与政策方面, 由于国内软件行业对国内市场依赖非常大, 一旦经济、政策发生变化, 对软件行业影响非常大;在需求和市场方面, 用户需求既与偏好相关也与经济形势相关, 软件项目对市场的变化非常敏感;在资源与服务方面, 人是软件项目的灵魂, 人员的流动特别是关键人才的流失会对项目造成巨大的影响, 而现实中软件人才的流动要高于其他行业;在技术方面, 新技术的本质特征就是高度不确定性, 其本身所固有的高度不确定性既是机遇所在, 也是风险的根源;在竞争方面, 随着近年软件业的快速发展, 同质化竞争非常激烈。

3.4 项目干系人的差异性

根据美国项目管理协会的定义, 项目干系人是指那些或者积极参与项目, 或者其利益在项目执行中或成功后受到积极或消极影响的个人和组织。一般, 项目干系人利用各种知识、技能、工具等对项目目标、规模和结果等产生直接或间接的影响, 因此, 与项目成败有着紧密的联系。Cleland[11]也认为项目与众多干系人相关, 考虑到他们的需求的差异性进行项目干系人管理是项目成功的重要部分。结合实际, 可将其项目干系人划分为客户、项目管理者、项目组成员和合作伙伴等四方面, 其差异性主要体现在:

(1) 目标的差异性。项目干系人来自不同的地域、不同的企业、不同的隶属关系以及不同的组织文化背景, 存在着不同的利益要求和追求目标;而且, 即使是同一干系人的利益范围也存有差异, 如有的项目组成员追求经济报酬、有的希望实现自我价值、有的则希望参与管理和决策等。表2是不同干系人的主要目标。现实中, 尽管项目的整体性要求成员维护总体目标, 但各干系人总是想法设法促使自己目标的实现, 在无法平衡各方利益诉求和同时满足各方目标追求时, 分歧和冲突也就产生, 给项目带来风险。

(2) 角色与职责的区别。1) 客户方面。客户是软件项目开发的重要参与者, 他们不仅要对自己的需求表达是否清晰负责, 还需证实开展的项目是否符合他们的需求, 并要支持项目的开发、确保人员的培训以及推进软件项目在企业中的应用。2) 项目管理者方面, 包括项目总监和项目经理等。项目总监主要是审批项目实施计划, 负责项目实施的重大事件决策, 协调各方工作关系, 对项目进度、质量等进行宏观监控;而项目经理主要是协调项目组人员的分工和资源分配, 监督项目实施和控制进度, 并与客户沟通联络、争取获得支持等。3) 项目组成员。项目组成员负责实施项目的各项活动, 包括系统需求分析、系统设计、编码与单元测试、系统测试、配置管理和文档活动等, 并支持项目编制和项目跟踪, 在项目预算及进度等约束条件下完成项目。4) 合作伙伴。合作伙伴一般根据项目开发者提供的需求规格说明书等, 利用自己的设备、人员、内部的生产过程和技术方法等在规定的时间内开发产品, 并接受项目开发者的监督和评审。

由此可见, 各项目干系人角色和职责的不同, 使得他们经常对项目成功完成应该执行的活动和次序等有不同的看法, 这种优先权的冲突即使在同一干系人范围内也会发生, 从而影响项目的开展。

4 软件项目风险形成机制研究

结合前面的研究内容, 我们可总结出软件项目风险的形成过程:

(1) 项目的复杂性与人的认知能力的局限性导致不确定性, 引致风险。

系统论认为, 系统是由彼此相关的部分或元素组成的具有一定功能、结构的有机体, 由于这一有机体还从属于一个更大的系统, 并进行着信息、能源和物质的交流, 使得系统本身变得异常复杂。对于软件项目来说, 不仅体现在软件项目逻辑结构、物理结构和模块间联结关系等技术的复杂性, 以及由此而导致的项目管理的复杂性, 同时由于其所涉及的环境因素众多, 特别是要素间相关关系错综复杂和动态变化, 使得软件项目更为复杂。

然而, 相对于软件项目的复杂性, 人们认识和把握这种复杂性的能力却具有很大的局限性。这种局限性, 一方面是因人的时间精力有限, 不可能获得所有有关软件项目的知识;另一方面是现有的软件开发工具和开发方法主要是应对过去一些常见问题而产生的, 但问题的多样性和新奇性使得这些工具和方法呈现出局限性。这种由软件项目自身的复杂性和人的认识能力的局限性之间的差距导致软件项目诸多方面的不确定性, 而这种不确定性又会通过各种不同因素的变化来体现, 一旦这种变化朝着不利方面发展, 就会影响软件项目的整体运行, 造成质量下降、工期延长和费用超额等。

(2) 项目干系人的差异性导致不协调和冲突, 引致项目风险。

除了由于软件项目的复杂性和人的认识能力局限性所导致的不确定性带来的风险外, 项目干系人的差异性也会给项目开展带来不确定性和项目风险。系统动力学认为, 在一个复杂动力系统中, 系统的每一部分运动导致的最终结果具有完全不同与部分的特征。例如, 一个人拉车或许刚好能拉动车, 但一群人拉车, 其结果可能就不一样了, 如果这群人都向同一个方向拉, 肯定会拉得更快;但如果各自向不同的方向拉, 或许一步也拉不动。这取决于各个方向上力的大小, 而且如果逆行方向的力最大, 还会出现倒退。同理, 在软件项目中, 涉及不同的具有独立主体利益的项目干系人, 有着不同的职责、隶属关系和不同的目标, 使得各方对于共同目标的认知很难一致, 而且出于追求自身利益最大化的本能, 往往容易忽略项目的整体利益, 而是从自身立场考虑, 难免会出现“系统内耗”现象。

由此可见, 在软件项目中, 一方面, 项目的复杂性与人的认识能力的有限性导致项目开展中的诸多不确定性, 为项目风险形成打下客观基础;另一方面, 项目干系人之间的诸多差异的现实存在导致项目的诸多不确定性, 为项目风险形成奠定了现实基础。由此, 可将软件项目风险的形成机制表示如图1所示。

5 结论

软件项目风险管理是软件项目管理中的一项重要工作, 但对于风险的管理既是一项重要的工作, 又是一项比较难的工作, 因此, 有必要研究软件项目的风险形成机制, 以帮助人们更好地认识、理解和管理风险。本文在分析软件项目风险类型和特点的基础上, 从项目的复杂性、人的认识能力的局限性、项目的不确定性、项目干系人的差异性等方面分析了软件项目风险形成的根源;通过整理分析发现, 软件项目风险的形成主要源自两方面, 一方面项目的复杂性和人的认识能力的局限性之间的差距使得项目开展中存在诸多不确定性, 另一方面项目干系人之间的显著差异使得项目运作与协调困难重重, 这两方面通过共同作用于软件项目引致风险事件, 最终造成风险损失。

参考文献

[1]KLEIN S A.Putting methodology in perspective from a project risk viewpoint[C]//IEEE Power Engineering Society 1999 Winter Meeting, 1999, 1 (31) :362-365

[2]KLASCHKE G.What the CHAOS chronicles 2003 reveal[R].San Diego:Cost Xpert Group, 2004

[3]常金玲.信息系统项目的风险因素分析[J].情报理论与实践, 2006, 29 (3) :318-320

[4]张天宇, 张英鹏.中小型软件企业项目开发风险研究[J].统计与信息论坛, 2009, 24 (5) :32-35

[5]潘春光, 陈英武, 汪浩.软件项目风险管理理论与方法研究综述[J].控制与决策, 2007, 22 (5) :481-486

[6]季年芳, 张宏书.基于风险因子分析的软件项目管理模拟模型[J].科技进步与对策, 2005, 22 (12) :172-175

[7]张俊光, 杨芳芳.软件项目风险管理方法研究[J].科技管理研究, 2011, 31 (8) :156-159

[8]王连成.系统工程论[M].北京:中国宇航出版社, 2002:92

[9]WEGNER P.Why interaction is more powerful than algorithms[J].Communications of the ACM, 1997, 40 (5) :80-91

[10]MILLER K D.Industry and country effects on managers`perceptions of environmental uncertainties[J].Journal of International Business Studies, 1993, 24 (4) :693-714

软件风险评估 篇11

IDG专供本报消息 微软公司4月3日宣布收购ProClarity公司，以增强其商务智能软件的实力。ProClarity提供商务分析和虚拟化软件，其软件从微软SQL服务器中采集信息并将信息提交给企业用户。ProClarity是微软公司的合作伙伴。此次收购符合微软要成为领先商务智能软件厂商的目标。

微软计划将ProClarity的技术与SQL Server 2005、Office Business Scorecard Manager 2005、Office Excel和Office SharePoint Portal Server结合起来。ProClarity的商务智能软件专门用于SQL Server，帮助用户利用数据库信息了解业务情况，以及利用其他有关企业绩效的分析信息。

SAP公司4月3日宣布，将收购法规遵从软件公司Virsa系统公司。此举旨在填补SAP软件产品组合在企业风险管理方面的空白，SAP希望在这一领域赢得市场优势地位。与竞争对手甲骨文公司用几十亿美元收购仁科和Siebel不同，SAP避开大规模收购，集中收购针对专门行业或技术的、较小的软件厂商。此项收购交易还有待于反垄断管理机构的批准。SAP希望今年5月完成对Virsa的收购工作。

软件风险评估 篇12

关于软件安全性,首先应该区分软件安全性和系统安全性的差别。文献[1]认为安全性是一个系统级的问题,就软件本身而言,软件并不直接做任何危险的事。然而,把软件放在一个复杂的系统中,软件有可能对系统产生不可预测和不安全的影响。软件安全性表示软件的运行而不使系统出现事故的能力。而IEEE标准认为软件安全性是指避免软件到达危险状态的能力[2];系统安全性指避免系统到达危险状态的能力。软件安全性仅仅与软件内部的失效有关,与硬件、人为操作等因素无关。而系统安全性受软件安全性影响。上述软件安全性的定义并没有反映出人们对于事故后果的严重性的态度。文献[10]认为安全性是一个不只局限于时间和空间的概念,还取决于人们对它的态度,这种态度是主观的并且随着时间和环境而变化。所以本文所采用的软件安全性定义认为它是软件运行而不至于使系统产生不可接受风险的能力。

鉴于软件安全性的重要性,各国对此进行大量的研究。美国各个安全关键领域制定了如下标准:MIT-STD-882B,NASA-STD-8719.13A,NASA-STD-8719.13B,NHB 5300.4(1.D.1)等;我国在80年代后期也相继研究和制定了软件安全性技术的国家标准和国家军用标准(如GJB/Z120-97,GJB/Z120-2004,GJB900-90等),但这些标准主要集中在安全性的分析、设计和开发等方面,对软件安全性的评估涉及不多。

从国内外的研究现状看,软件安全性评估分为两大类,一类是基于风险的安全性评估;另一类是基于可靠性模型的安全性评估。基于风险的安全性评估是根据领域专家的经验,对软件的失效率和严重度进行主观判断,这就需要有充足的历史数据供专家参考,才能使之做出正确的评价。而在实际的工程应用中,由于历史数据有限,这种方法就显示出局限性。基于可靠性模型的安全性评估对失效数据统一处理,并不把失效数据按失效严重度分类后处理,把安全性和可靠性混在一起,缺乏对失效严重度的关注和量化,不能很好地表征软件安全性。

对于软件安全性的评估,需要同时考虑失效率和失效严重度这2个因素,而且应该构建模型尽量客观地对其进行量化。本文提出的方法首先对失效数据按严重度分级。对于分级之后会出现某一级别失效数据极少而难以运用可靠性模型的情况,通过在总失效率和各级别失效率之间构建关系,可以比较精确地求得该级别的失效率。同时采用失效强度(残留失效检测率)和严重度来表征软件的风险,最后用实例来验证上述方法的有效性。

1 相关研究

风险评估法作为最早的软件安全性评估方法,用风险作为评估安全性的一个指标。风险由事故发生的可能性和事故发生的严重度综合决定。

其中,ε(hazard)表示事故所造成后果的度量(如死亡的人数、经济损失等),Pr(hazard)表示事故发生的概率[1]。失效率、失效严重度的值用自然语言表示,它们通过安全风险矩阵映射到风险,所以风险的值也是用自然语言描述的。因此,该类方法基本上也属于定性评估方法,而且评估带有很大的主观性。文献[3]给失效率和失效严重度赋于一定的权值,达到了定量评估安全性的效果,但是仍然没有改变评估不够客观的缺点。

考虑到用精确完整的数学模型去处理主观评价是相当困难的,甚至是不可能的。于是,一些学者引入模糊数学方法来对软件安全性进行评估[5,6,7]。首先根据不同领域的风险矩阵建立模糊规则库,用梯形模糊数标识领域专家对失效发生可能性和严重度的主观评价,然后根据模糊规则库将其映射到模糊风险水平。这在一定程度上可以合理地、客观地量化风险,但是仍然避免不了对失效率和严重度评价的主观性。

文献[8]把软件失效细分为安全失效和非安全失效两种状态。该方法假设失效率λ为常量,根据软件测试的客观数据,运用可靠性模型求得λ和平均失效时间MTTF,然后用Markov模型求得软件从正常状态到安全失效状态的转移概率C,进而得到平均非安全失效时间MTTUF=MTTF/(1-C)。文献[9]认为文献[8]的方法得出的结果过于乐观,用可靠性模型求出失效率的上限λmax和MTTFmin,最后通过Markov模型求出MT-TUFmin。用MTTUF评估安全性的缺点是只估计下一次非安全失效发生的时间,而不管该失效造成的结果有多严重。

考虑到任何方法都不能保证软件是绝对安全的,所以软件安全性的目的是减少非安全失效使之到达一个可以接受的水平。文献[10]提出Schneidewind模型,该模型用软件残留的失效数和到下一次失效产生的时间来表征风险。这种方法的缺点是没有很好地区分可靠性和安全性的差异。

2 残留风险分级评估法

2.1 符号意义

ns已知失效总数;

mi已知第i级严重度的失效数;

N失效总数的估计值;

Mi第i级严重度的失效数的估计值;

λ总失效率;

λi第i级严重度的失效率;

Z(i)第i级失效严重度的失效强度。在第i级失效严重度中,给定软件失效发生于t时刻的条件下,软件在t时刻之后单位时间内失效的概率;

Risk软件的残留风险。

2.2 各级失效率的计算

对软件安全性而言,需要对软件失效按严重度划分。软件失效可以分为安全失效状态和非安全失效状态[8]。但是这样的划分只能告诉我们软件是否发生了非安全失效,而不能精确地表明软件在非安全失效状态下到底发生了多严重的失效。所以要求更细致的划分失效严重程度。

假设失效数据集按严重度划分为n级,即软件失效后有n个状态(如图1所示),其中级别1严重度最高。

根据总失效数等于各级失效数之和的原理,可以得到如下公式:

分级之后会出现失效严重度高的级别数据比较少,以至于不能用可靠性模型评估该级别的失效率。假设级别1数据极少,其余级别数据充足。那么首先对整个失效数据集和失效数据充足的级别运用可靠性模型,求得λi(i=2,3,…,n)和Mi(=2,3,…,n)。进而可以求得M1。

把式(2)代入式(1)中,得到:

通过公式(3)可以求得只拥有微量数据级别的失效率。

2.3 各级残留风险的计算

传统的风险评估方法用失效率和失效严重度表征风险。软件风险等于每一个失效产生风险的总和。但是要求得到每一个失效的失效率和严重度显然是不可能的,所以本文用失效强度和严重度来表征软件的残留风险(即软件在t时刻失效,在t时刻之后软件剩余的风险)。

对各级的失效危害率计算如下:

各级别软件安全性残留风险的计算如下式:

其中S为Z(i)所在级别的失效严重度,是由领域专家根据经验对失效结果的评价。公式(5)的意义:第i级失效严重度下,软件在时刻t发生失效,在t时刻之后单位时间内的该级别剩余的风险。

2.4 总残留风险的计算

总残留风险等于各级残留风险之和:

如果所求的Risk小于给定的风险的话,那么软件是可以的接受的,否者继续测试,直到残留风险满足条件为止。

3 实例分析

图2中数据来自Johnson Space Center的一个地面系统中的安全关键软件的测试[9],总共测试时间是2656.9个小时,分为39个时间间隔。其中关键失效有4个,主要失效有84个,次要失效有157个。

对上述测试数据的分析发现,关键失效的数据极少,所以关键失效级别不适合用可靠性模型来计算其失效率。而对严重失效级别和次要失效级别分别运用GO模型得到λ2、M2、λ3、M3以及λ和N。把上述数据代入公式(3)求得关键失效率λ1。

根据已知数据可以求得关键失效的MTTF。图3表示新方法求得的关键失效的MTTF和基于Markov模型[8]求得值的比较。从图中可以明显看出新方法的预测结果明显优于原方法[8,9]。

图4表示各级别的失效强度Z(i),从图中发现,由于有一个明显不合理点的存在,致使该点附近曲线波动太大而掩盖了曲线的真实波动,不能明显地看出失效强度的真实走向。所以,为了看清曲线的趋势把该点去掉,从而得到图5(下同)。从图5可以看出,失效强度在早期有一些震荡但最后都趋于收敛。而且失效严重度大的级别,相应的失效强度就小,这也符合安全软件的设计目的。

失效严重度应由领域专家根据经验获得[13]。本文假设关键失效严重度为0.95,重要失效严重度0.65,次要失效严重度为0.4。用式(5)和式(6)求得Risk(如图6所示)。软件在经过了2000个小时的测试之后风险趋于收敛,风险值为0.03。在实际工程应用中,如果发现软件风险趋于收敛,并且该收敛值小于可以接受的风险的话,那么该软件就可以发布了。

从图5-图6可以看出,软件各级失效强度、风险经过早期的震荡最终都趋于收敛,所以该方法是合理的。但是,从图4看不出这种趋势,这是因为存在一个波动太大的点把这种趋势给掩盖了。经过分析发现,这个不合理点发生在同一时刻,即第871.6小时。在该时刻所对应的时间段内,关键失效和次要失效都为0,可能是这个原因致使曲线剧烈变化。另外,从图5和图6中发现,风险有负值存在,这是由GO模型产生的,该模型会估计出负的失效率和失效数。

总的来说,不管失效严重度的值如何变化,该方法求得的软件失效风险总是趋于收敛的。

通过对软件安全性的分析,可以大致预见哪些失效会产生严重的后果,那么,在相应模块的设计中采用较强的容错机制和安全核[12],使之少发生失效或者只发生安全失效。设计人员在越重要的软件模块(即失效严重度高的模块)投入的时间越多,设计越完善,其失效强度就越低。

4 结论

关于软件安全性评估,现有基于可靠性模型的方法对所有失效数据做统一处理,而不是对每一级失效严重度应用可靠性模型,使得构建出来的模型与可靠性模型区别不大。

本文结合风险评估的相关概念,把测试得到的失效数据按严重度分类,对数据充足的类别用可靠性模型估计失效率,再构建总失效率和各级失效率之间的关系,从而解决了对微量数据难以用可靠性模型来估计软件安全性的问题。

但是,该方法对于失效严重度的量化还是要靠专家经验来主观评估,这会对风险的收敛值产生一定的影响。另外,从图5可以看出,对于失效严重度大的级别,相应的失效强度就小。因此今后可以从失效强度入手,合理客观地量化失效严重度。

摘要：评估软件安全性常用的方法有风险评估和基于可靠性模型的评估。基于上述二种方法提出了残留风险分级评估方法。该方法用失效强度和失效严重度来刻画软件的风险,较好地解决了由于测试数据按失效严重度分类后数据少而难以应用可靠性模型的问题,并用实例说明了新方法的可行性。