软件风险

软件风险（精选十篇）

软件风险 篇1

开源软件起源于自由软件, 但又不同于自由软件。自由软件宣扬人人享有对软件代码进行复制、修改及传播的权利, 开放源代码, 并通过订立协议要求对使用自由软件代码进行二次开发的衍生作品也必须按照协议开放源代码。自由软件浓烈的理想主义色彩, 让商业软件公司对自由软件敬而远之。开源软件与自由软件不同, 它更注重与软件产业相结合, 对商业化更加友好。商业软件公司可以通过重用现成的开源软件节省开发成本, 缩短开发时间, 在风云变幻的软件业, 这种效率上的提高对于软件开发商具有重要价值, 因此, 越来越多的商业公司加入到开源软件的开发中, 并成为主导力量。

自1998年开源软件促进会 (Open Source Initiative, 简称OSI) 成立至今, 十余年间, 越来越多成功的开源项目走进了人们的视野, 如Linux操作系统、A-pache Web服务器、MySQL数据库、Eclipse开发平台、Firefox浏览器等。它们的出现打破了专有软件独霸天下的局面, 也为其他软件制造商进入开源领域提供了先验经验。

虽然开源软件的发展繁荣了全球软件产业, 也给我国软件产业带来了巨大的机遇, 但在使用开源软件进行商业软件开发时还存在一定的风险。这些风险主要来自于法律方面。同商业软件一样, 开源软件仍然受到知识产权相关法规的保护, 如果使用不当, 极有可能受到来自开源组织或其他商业软件公司的法律追究, 我国的某些软件公司已经出现了这样的问题。其他的风险还包括代码的稳定性, 以及对开源软件是否为国产软件的争论问题。本文将结合近年来的一些典型案例逐一讨论使用开源软件进行商业软件开发时可能遭遇到的风险。

2、使用开放源代码进行商业开发的法律风险

2.1 著作权

商业软件受著作权 (即版权, Copyright) 保护。著作权授予软件著作权所有者诸多的权利, 主要包括人身权和财产权两大部分。人身权包括署名权、发表权、保护作品完整权和修改权;财产权包括复制权、发行权、出租权、汇编权、翻译权等。开源软件的发布采用Copylef方式。它的授权方式与版权不同。Copyright的概念是为了限制他人任意使用创作物的自由。Copyleft则是为了保护这种自由而定义的概念[1]:它允许他人任意的散布、修改作品, 惟其散布及修改的行为和作法, 亦限定以Copyleft的方式行之。Copyleft作品是有版权的, 即开源软件同样受到著作权法的保护。开源软件著作权所有人通过授权许可协议放弃一部分权利, 如复制权、修改权等, 但其他权利仍受到著作权法的保护。所以, 那些认为既然可以免费获得源代码, 就可以对开放源代码为所欲为的观点是错误的, 更是危险的。

侵犯开源软件著作权的行为可能是有意的, 也有可能是无意的。无意的行为可能出于没有正确理解开源协议, 或是当前法律对开源软件的界定还不够明确。有意的侵权行为则是恶意地使用开源软件的源代码而不遵守开源协议, 或是包含了商业软件的代码, 对其他商业软件公司造成了侵权。2009年6月, 我国国内公司开发、国家工业和信息化部出资购买供全社会免费下载使用的上网过滤软件"绿坝-花季护航" (下面简称绿坝) 就面临违反开源协议和侵犯知识产权的法律诉讼[2]。绿坝被指其用于不良图像过滤的核心识别程序文件和其他一些程序文件均来自Intel公司资助的开源软件OpenCV, OpenCV采用的是BSD许可证, 但绿坝并未按照BSD许可证的要求在软件版权信息中附上BSD声明, 并且删除了源文件中所有的版权信息。另外, 绿坝还涉嫌抄袭美国一个名为Cybersitter的软件逾三千行源代码。2010年12月, 美国法院已经受理了有关绿坝的侵权诉讼, 原告Cybersitter软件的开发商美国Solid Oak公司向绿坝软件开发商、预装绿坝软件的个人电脑生产商和中国政府索赔22亿美元[3]。由此可见, 这种盗用开源软件以及商业软件源代码的行为, 不但会招致诉讼风险, 面临经济上的巨额损失, 更会损害公司形象, 影响公司商誉, 甚至累及国家。

另外, 开源软件自身也存在着著作权归属不明的问题。开源软件通常具有非常复杂的血统, 这是由其特有的开发模式导致的。开源软件提倡集合世界各地的开发人员的力量共同开发, 一个开源软件的代码贡献者可能动辄几人, 多则数十人、上百人, 而像Linux这样的大型项目更是数以千人计。这些参与者的背景各不相同, 很难保证他们贡献的代码都没有问题。这种知识产权归属混乱和复杂的状况使得不少开源软件时时处在被指控侵权的风险之下。Linux就曾经涉嫌侵权美国SCO集团拥有知识产权的UNIX程序代码[4]。对于开源软件自身存在的侵权问题, 开源软件许可证也不提供任何特别的条款或者其他保证, 确保源代码的贡献者没有侵犯其他人的知识产权, 这些许可证对于第三方的侵权指控不提供任何免责保护。这也加大了使用开源软件进行商业开发的风险。

2.2 专利

与著作权相比, 专利保护的特点是保护期短、保护力度大、需公开技术。以专利保护计算机软件的特点是, 专利权是一种绝对权, 且专利保护延及过程和方法, 所以专利法的保护力度远强于著作权法, 对技术具有更强的垄断性。专利法保护的是软件作品发明创新的技术方案, 其他人只要沿用其技术方案, 即使完全重新编码也不允许。但开发一段程序通常需要组合上千个技术, 即便这些技术中的一些来自开发者本人的创新, 其他的技术也一定是来自于开发者以前看过的其他软件。而如果这些技术都被打上专利的标记, 每一个大程序都可能会侵犯几百条专利权。开发一个大程序就置身于几个百潜在的法律诉讼之中[5]。长期以来, 开源界一直都很排斥对软件实行专利保护, 认为专利保护限制了软件技术的发展。商业软件公司则与开源界持相反态度, 事实上, 商业软件公司更乐于利用专利来对开源软件形成威慑。

有关于开源软件涉嫌侵犯商业软件专利的法律纠纷案件不胜枚举。仍以Linux为例, 2004年8月, 以专营开放资源保险业务的开放源代码风险管理公司公布, 经调查, Linux操作系统含有可能引发专利侵权纠纷的美国专利共有283项[6]。2007年5月, 在一次《财富》杂志访谈中, 微软首席法律顾问声称开源软件包括Linux侵犯了其235项专利, 但出于多方面考虑, 微软公司没有提出诉讼[7]。

如今备受追捧的Android手机操作系统也正面临专利侵权的诉讼。Android由谷歌开发且对外开源, 手机制造商可以在Android上进行二次开发, 并免费用作手机的操作系统。2010年8月, 甲骨文公司控告谷歌Android侵犯Java的知识产权[8]。随后不久, 微软也声称Android侵犯专利, 手机制造商使用Android存在风险[9]。为了避免争端, 最大的Android手机制造商HTC已经向微软缴纳了专利费[10]。苹果公司起诉HTC的Android手机侵犯了一系列苹果的专利也印证了微软这一说法[11]。而对于这起专利纠纷, 谷歌也只给HTC提供道德而非法律上的支持。

为了应对商业软件公司的专利策略, 开源社区联合支持开放源代码运动的商业公司共同展开了反击战。2005年, IBM与SUN公司先后向开放源代码界开放了逾2000项专利。与此同时, 开源界也注意到专利是一把双刃剑, 既可以作为进攻武器, 也可以用作防御武器。开源软件也开始使用专利制度来降低专利带来的威胁。主要的办法有: (1) 鼓励主动申请软件专利后在开源软件许可证下发布; (2) 尽早将软件开发的发明思路在公共论坛上发表; (3) 在技术上使软件结构易剔除侵权代码; (4) 出现软件专利侵权诉讼时, 开源社区一起提供能有效推翻其专利权的证据等。

2.3 开源软件许可证

开源软件与商业软件的本质区别体现在许可证的定义上。在传统商业软件的许可证中, 一般明确许可方的版权归属及权利义务;作为被许可方支付软件使用许可费的回馈, 许可方一般提供缺陷担保、违约责任, 并涵盖支持、维护等技术服务内容及其费用。而在开源软件许可证中, 主要规定被许可方是否能够发布该演绎作品的源代码、对源代码进行修改应满足的要求等, 一般不涉及软件许可费、维护支持的内容。

OSI于1998年成立后取得了认证开源软件许可证的资格, 只有使用了经过其认证的开源许可证的软件才能被称为开源软件并准许使用其商标。目前, 经OSI认证的开源许可证共有74种, 这些许可证大致可分为两类, 一类是以GNU通用许可证 (GPL) 为代表的强“Copyleft”型许可证, 另一类是以BSD为代表的宽容型许可证。GPL给予任何人自由复制、修改和发布GPL代码的权利, 但作为回报, 所有以GPL协议发布的源代码的衍生作品, 也必须按照GPL发布。虽然GPL协议并没有规定以GPL协议发布的软件不允许用作商业用途, 但GPL的这种病毒效应使得GPL无法与商业走得太近。而BSD许可证则宽松得多。BSD许可证仅要求被许可者附上该许可证的原文以及所有开发者的版权资料。它允许原作品及其修改版发行时不公开源代码或以其他许可证发行, 它不像GPL具有"病毒效应", 为开源软件转化为商业产品敞开了大门。但不论是GPL许可证还是BSD许可证, 都没有明示专利授权, 且都有拒绝担保的声明。这也就意味着, 使用以GPL或BSD发布的开放源代码时, 不能不顾及专利以及版权问题带来的风险。

侵犯开源软件的著作权通常是由不遵守开源协议造成的。有些人对"自由"与"开源"没有正确的理解, 认为免费获得也就意味着随意使用。但不论是自由软件还是开源软件, 它们都受到著作权法的保护。

另有一些商业公司存在矛盾与侥幸的心理, 一方面想直接使用以GPL协议发布的源代码, 节省开发成本, 另一方面又不想公开技术, 发布其衍生代码, 抱着当前法律对开源软件的保护还不完善的侥幸心理, 封闭源代码, 用作商业用途, 这种行为极有可能招致法律问题。2008年8月, 美国联邦上诉法院在判决中第一次承认"开源协议"是一种著作权协议, 违反协议就是侵权行为[12]。违反开源协议的二次开发商要么遵照协议, 公布源代码, 要么被终止使用授权, 删除衍生作品中所有的开放源代码。

2007年, 华硕公司推出易PC, 易PC推向市场后不久即遭遇到著作权问题[13]。由于华硕易PC采用了开源软件Linux作为其操作系统, 却违反了开源软件的GPL协议, 未公开其对于高级配置与电源接口的部分程序文件修改结果的全部源代码。此事曝光后, 华硕迫于压力, 不久后即公布了原先未公布的全部源代码。前文提及Google开发的Android手机操作系统涉嫌专利侵权。2010年年底, 红帽公司的Matthew Garrett爆出大多数Android平板电脑制造商未遵守GPL协议, 没有按照许可证公布源代码[14]。一旦开源社区集中力量对违反协议的Android平板电脑制造商展开攻势, 经济上的损失将难以避免。

2.4 商标权

关于开源软件的法律风险问题, 开源软件的商标问题远不如其著作权及专利问题讨论的激烈。但商标也是使用开源软件的一个潜在风险, 不应被忽视。

商标是商品生产者、经营者或服务提供者为了让其自有商品或服务区别于其他商品或服务所采用的由文字、图形、数字等单独或组合形成的可视化标识[15]。商标使消费者联想到商品本身, 消费者凭借商标来选购商品。商标的滥用会导致消费者误以为经营者与商标注册人存在某种联系, 同时也侵犯了商标注册人的权利。利用商标对软件进行保护, 可以拓展软件的版权保护和专利保护的保护范围, 同时可以通过对商标的续展获取更长的保护期限, 且对于商标侵权的认定也较版权与专利更为容易。商标法不但适用于商业软件, 同样适用于开源软件。许多开源软件产品注册了商标, 并订立了严格的商标使用许可协议, 如数据库MySQL[16]。

在使用开源软件进行商业软件开发时, 涉及的商标问题一般有两种情况。第一种情况是使用原有开源软件的商标, 这种情况不涉及商标注册的问题, 主要的风险在于是否合理使用开源软件商标。使用开源软件的商标有被动使用与主动使用之分。许多开源软件许可证都要求"保留源代码中所有企业标识", 即要求对源代码进行衍生作品开发的作者需要将先前开发者的商标或企业标识原封不动地植入自己的作品中, 这种情况就属于被动使用商标, 因为受到了许可协议的约束。前文已经提到, 不遵守协议的后果是随时可能被终止使用授权。主动使用开源软件商标一般是为了借助原开源软件的知名度来推广衍生作品。开源软件开发商虽然允许在遵守协议的前提下自由使用源代码, 却不会允许自由使用其商标, 事实上, 任何人要想在软件产品中使用先前开源软件的商标, 都要向商标注册者缴纳一定的费用, 且遵守商标使用协议。以MySQL为例, 该软件对商标的使用有着近乎苛刻的规定, 即使允许使用MySQL标识, MySQL也可单方撤回授权, 即随时收回许可权利, 而使用商标过程中的风险则由使用者承担[16]。

另外一种情况是为自己的演绎作品申请商标。除非先前开源软件的商标所有人授权, 否则开源软件的衍生产品无权使用与原来产品相同的商标。例如, Debian Linux对Mozilla的Firefox浏览器进行了修改, 删除了一些装饰性的功能, Mozilla也拒绝让Debian继续使用Firefox这个商标。结果, Debian版的浏览器被命名为"Iceweasel", 虽然在功能上它与Firefox几乎完全一样[17]。

商标有"商品商标"与"服务商标"之分。由于源代码不可视为一种商品, 如果需要为开源软件申请注册商标, 则只能就围绕该开源软件所提供的服务、技术支持等申请"服务商标"。但对于与硬件有关的开源软件产品, 开发商可以就该开源软件产品的周边硬件商品申请商品商标。

3、使用开放源代码进行商业开发的其他风险

开放源代码商业模式的出现无疑为我国软件业的发展带来了新的机遇, 但如何运用好开源模式, 开发出具有自主知识产权的国产软件依然是值得思考的问题。当前, 我国众多参与开源软件商业开发的企业都是直接从开源社区中"拿来"程序, 经过修改、演绎或者打上补丁之后进行销售。这样的软件是否是国产软件, 是否具有自主知识产权, 进入市场后遭遇法律诉讼的几率有多大, 这些问题都是开源软件商业开发的隐患。

另外, 尽管开放源代码的质量问题一般对开发开源软件的影响较小, 但由于参与开源软件的开发者可能来自身份、背景都不相同的不同领域, 技术水平的高低不同可能会影响开放源代码的质量, 因此在对开源软件进行商业开发时, 不得不考虑开源软件的成熟度问题。对于这一问题, 企业需要规范管理, 规范开发, 建立严格的代码审查制度, 为每一段代码验证身份, 禁止程序员在网上抓取身份不明的代码。

4、总结

开源软件作为软件开发的一种商业模式正在日渐成熟, 它改变了软件产业的格局, 有利促进了软件技术的传播与发展, 并终将成为未来软件开发的主要模式。对于软件产业相对落后的我国, 应该鼓励软件企业尤其是中小型企业进行开源软件的开发。如今, 在开源软件的法律保护还不甚完善以及开源模式还没完全成熟的现状下, 使用开放源代码开发商业软件存在一定的风险, 这些风险不应被忽视, 但也不应被夸大。了解风险, 正视风险, 采用合理规避策略, 在开放源代码基础上开发拥有自主知识产权的商业软件, 才是我国软件企业在未来发展过程中应该重视的问题。

摘要：开源软件是当前日渐流行、同时也是争议最多的软件开发模式。在我国, 越来越多的软件开发商正加入到开源软件的开发中来。结合典型案例, 探讨了在使用开源软件进行软件开发过程中可能遭遇到的来自著作权、专利、开源许可协议、商标法等法律风险问题, 以及国产开源软件的知识产权归属和开放源代码质量问题。希望借此帮助我国开源厂商、开发者认清使用开源软件进行软件开发的各类风险。

软件项目风险研究（共） 篇2

摘要： 阐述了软件项目风险的概念和风险定义，并且分析了在软件项目中的风险类型，最后根据风险的定义和类型，分析出相应的风险避免措施。

关键词：风险的概念；风险定义；风险类型；避免措施；

The Analysis Of Software Project Risk

WengHuaBin 10703080227

（ChongQing University Of Technology-Software Engineering）

Abstract: Describes the concept and definitions of software project risk ,And analyzed the types of software projects risk ,Finally, according to the definition and types of Software project risk analysis to avoid the risk of the corresponding measures.Key words: The concept of risk;The definition of risk;The risk types;The avoid measures;

软件行业在社会各界（包括政府、教育机构以及各个企业）的日益剧增的信息化需求下，已经成为高速信息化建设中必不可少的一个元素。所以软件行业要不断的提高稳定程度和运行效率，然而软件项目本身就是一个高风险的项目类型，任何项目都是存在一定的风险性，软件项目更是不例外，所以软件项目需要更好的风险避免措施，只有做到更好更科学的防御措施，才能在最大程度上降低软件项目成本和提高软件项目的成功率。再者，国内外的一些成功的软件项目案例告诉我们，软件项目风险分析是一个相当重要不容忽视的环节，只有做好了软件项目风险分析才能致使软件项目成功地进行，得到用户满意的软件，这也是众多软件公司的最终目的，所以科学的风险分析和必备的防御措施是一个好的软件项目的先决条件。软件项目风险概念

首先，我们知道任何项目都是有一定的不确定性和风险性，然而，软件项目是一个风险 比较大的项目种类，所以总而言之，零风险的项目基本上是不存在，项目中的风险分为多种类型的，只是我们在遇到风险的多少、大小以及严重程度是不同的。

再者，我们分析一下，在软件项目中，我们一般遇到的软件项目风险是怎么样的。在软件项目风险分析中，基本上所有的软件项目管理者都会很大程度上地关注软件项目的进展程度、完成情况以及对成本的控制等等，但是我们必须不可以忽视的问题是我们在项目进行当中遇到的风险，这些风险虽然一时半会可能会隐藏于软件开发中，但是一旦这些问题暴露出来，就会给软件项目带来不可挽回的灾难，任何一个技术人员、管理人员的一个失误或者软件开发中的任何一个负面的因素都有可能成为软件项目成功的威胁，所以我们不能忽视任何的失误，更不能忽视任何一个可能的风险。然后在我们的软件项目中，有可能就是因为一种侥幸的心理往往让我们得不偿失，因为风险本来就是一个不及时出现而又可能本质存在的客观因素，所以我们说它是一种潜在的风险，但是当它真正威胁到我们的时候，也就是我们发现风险存在的时候，这个时候它已经给我们带来了很大的麻烦，并且严重的有可能是不能挽回的损失，所以作为一个软件项目技术人员或者管理人员，我们都应该及时的关注软件的发

展进度，并且的不断的尝试有可能出现的风险的分析。

所以，我们要对软件项目进行规划来查找可能的风险，这样软件项目的期望值才会由低变高，进行了风险分析，这样软件项目的成功率也会大大提高，根据成功软件项目的经验和失败软件项目的教训，我们得知成功的软件项目都必须采取积极的步骤对要发生或者有可能存在的风险进行分析，从而才可能采取有效的措施避免软件项目的失败。软件项目风险定义

风险是潜在的对软件项目的威胁，未来可能发生损失的一种度量，当然也有可能不发生，但是一旦这种危险出现了，就会对软件项目带来很大甚至不可估量的损失，也是对公司的一种负面消极影响。软件项目风险是是未来的一种关注，本来风险就是不确定性的，所以这种潜在的危险就给开发过程中带来了各种决策的选择，另，风险还和人为因素（例如思想、行为）和环境因素（例如时间、地点）有关，等等这些因素都会导致软件项目的风险，所以在对软件项目进行分析的时候这些因素都是不容忽视的。

软件项目风险一旦出现就会影响软件的开发进度、成本，这些都可能导致最后的软件项目的失败，这些都应该是软件项目组所关心的重点。在软件项目的开发过程中，我们都知道现在软件行业的技术是日新月异的，所以必然会用到一些新技术，以及我们的人力方面，这些都是影响项目开发的主要因素，然而正是这些因素的复杂性，也就造就了软件项目风险的复杂性，这些因素本身就是不确定的，当我们面对这些复杂的未知数时，要进行科学的分析得出更加合理的答案，才能使软件项目不断地向成功的方向发展，并且对软件开发做出一个正确的引导，反而言之，项目损失带来的将是项目的无法如期完成或者大量的超出成本预算，这些都将给企业带来直接的损失和消极的影响，所以我们在这里可以定位软件项目风险的重要性。

综合上述的分析，我们可以总结出风险的几个要素，风险首先是一个不确定的风险因素，然后会导致一个风险事件，这样带来的结果就是直接的损失，这样开发出来的软件就和企业以及客户的预期值相差太远，最后就有了风险结果，我们可以用一个图来表示这个风险描述：软件项目风险类型

软件项目风险的类型可以从不同角度进行分类，以下就范围角度和预测角度进行风险类 型的分析：

从范围角度，风险主要分为：商业风险、管理风险、人员风险、技术风险、开发环境风险、客户风险、过程风险和产品规模风险等等。

1）商业风险：是指与管理或市场所加诸的约束相关的风险，主要包括市场风险、策略风险、管理风险和预算风险等；

2）管理风险：是指在项目开发进程中，对潜在的人力和物力以及相关资源的管理风险，这

其中包括对时间、技术人员和项目相关资源的分配不合理，还有对项目计划实施没有做到足够好的预期安排等；

3）人员风险：人员风险主要是指在开发和实施的过程中技术人员自己的相关因素，其中主

要包括技术人员自身的不稳定性和错误判断，还有包括项目参与人员的经验不够丰富以至于做出错误的决定，这些都会影响项目的质量；

4）技术风险：是指在不断更新的软件开发技术中，会有某些不稳定的技术的参与，或者与

正在进行的项目不兼容的现象等等，所以在做技术风险分析的时候，我们先要对技术的稳定性和兼容性进行准确的测试，这样才能给软件项目进行准备的技术定位；

5）开发环境风险：主要是指开发环境以及工具可能会对项目造成的风险；

6）客户风险：在软件项目开发中，我们可以很明确的感觉到用户的需求的确定是一件具有

一定复杂性的工作，这样往往在我们的开发过程中，可能是因为客户的理解的差异造成客户修改需求的风险，这样的风险是最常见的，我们不能随时的变更需求，但是客户又必须要求更改需求的时候，这时候我们的客户风险就大大的出现在软件项目中了，所以为了避免这种风险或者减小这种风险发生的可能性，所以我们在分析客户需求的时候就要尽量想到以后可能会出现的风险；

7）产品风险：产品风险主要是指在产品成型之后，所出现的产品质量与客户或者开发人员

自己所预期的不相符合的情况；

8）过程风险：过程风险是与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险；

从预测角度分析风险类型：

1）已知风险：在软件开发过程中，已经知道的风险是通过评估项目计划、开发项目的商业

及技术环境以及其他的可靠的信息来源而得来的；

2）可预测风险：这种风险类型是通过以往的项目经验来进行预测的风险类型；

3）不可预测风险：不可预测的风险往往是隐藏在项目开发过程中，这种风险是很难在其中

得知的，但是这种风险出现几率就没有那么大了，所以一个强大的企业需要有能够承担这种风险的能力；软件项目风险避免措施

当我们了解了风险的概念、定义以及类型以后，就应该根据风险的一些特性制定出相应 的避免措施。

在软件开发的初级阶段，最重要的工作当然是需求分析，当然这个里面包含了风险分析，做一个好的风险分析就等于为软件项目的成功打下了坚实的基础。首先，我们在需求分析的时候，必须要深刻的了解客户的使用情况，要深入到企业或者试用人员的周围调研用户需求，这样得到的需求才是真正的用户需求，如果我们只是一味的听从客户所描述的需求来定义软件需求的话，那么我们就大错特错了，在一般情况下，用户描述需求都不能全面的或者专业的转达他们理解下的需求，所以软件项目人员必须自己做好需求调研工作，这是一个至关重要的阶段，做好了这个阶段，也就减小了后续开发中的风险。其次，在软件开发的过程中，我们应该合理科学地安排技术人员以及其它与项目相关的资源，安排好这些资源后，才能减小开发中人员风险存在的可能性。还要做好其他相关风险的安排和考查工作，这里就每个风险类型不做一一介绍。最后，软件项目参与人员还应该根据已有的成功项目和失败项目的经验和教训，对此加以总结和比较，得出影响软件项目的相关重要因素，并且对这些可能存在的因素进行分析，尽可能地得出已知的和潜在的风险，根据相应的风险类型，及时的做出最合理的避免措施，以至于有效的防止风险的扩大化和普遍化。结束语

本论文主要介绍了软件项目风险的概念、风险的定义、风险的类型以及避免措施。我们 了解了风险的危害性，风险会对项目的成功造成决定性的威胁，所以当我们知道了风险危害性以后，应该怎么地去避免措施，做好合理科学的检查和预测，才能高效的防御风险发生的可能性，所以，要想做好一个软件项目，软件项目中的风险分析是一个重中之重的环节，不容忽视的，我们要总结已有的软件项目的成功和失败之处，然后运用到自己的项目中来，这样才可以最好的做到软件项目风险分析工作。参考文献：

【1】韩万江 姜立新 软件项目管理案例教程（第二版）机械工业出版社，2009.04.【2】卢有杰 卢家仪 项目管理系列教材 清华大学出版社 2001.08

【3】王卓甫 工程项目风险管理 中国水利水电出版社 2003.02

【4】Elaine M.Hall（王海鹏 周靖译）风险管理 清华大学出版社 2002.09

打车软件风险几何 篇3

从1月开始，快的和嘀嘀两家打车软件不断推出补贴，通过烧钱大战占据打车市场。但到了3月4日，快的宣布乘客补贴下调至每单5元，每天2单。3月10日，嘀嘀也宣布乘客微信支付补贴调整为随机减免5至10元。

不过补贴的降温并未使打车软件淡出公众视野。3月10日，上海嘀嘀、快的两大软件被纳入强生公司的出租车电调平台，而到3月底，还将与大众、锦江、海博三大出租运营商完成平台上的技术对接。这意味着上海嘀嘀、快的两大软件从此被“招安”了。但无论是补贴下降，还是被收编，似乎都不能平息这场关于“打车软件”的争议……

互联网巨头争夺打车市场

2013年底，一场烧钱大战蔓延了打车市场，烧钱双方分别是嘀嘀打车与快的打车，二者背后分别是腾讯与阿里巴巴。据统计，二者宣称的投入补贴已超过19亿元，这使得打车软件成为了2013年至 2014年烧钱最厉害的移动互联网领域。

“从O2O的角度来说，打车软件是一个先行领域，同时与其他应用（如手机地图、旅游平台、餐饮娱乐）相结合能够有效地促进移动互联网领域的发展。可以说，腾讯和阿里巴巴通过‘烧钱大战’，想要的不仅是打车软件市场，更是一个完整的‘闭环’。”中国移动互联网产业联盟秘书长李易告诉《方圆》记者。

虽然上海嘀嘀、快的两大软件被收编了，但并不妨碍“闭环”的完成，最主要的一点原因是，被招安的是打车软件本身，而最为主要的“移动支付入口”被保留了。只要“入口还在”，无碍于“闭环大业”。

“如果有一天你出门吃饭，打车用嘀嘀，在微信的朋友圈里发餐厅的照片，吃完饭结账用微信支付，打车回家再用嘀嘀，那么你整个消费活动只与腾讯发生联系。这就是腾讯想要完成的‘闭环’。”资深互联网从业人员罗宇（化名）告诉记者。

“以阿里巴巴为例，它就已经基本完成购物的闭环了。我们先在微博上看到一个商品的推荐，然后通过微博链接转到淘宝的页面，点击下单后用支付宝付款，到以后甚至可以用它们自己的菜鸟网来送货，这就是一个完整的O2O模式。”据李易分析，“将来这两个打车软件不会单独地存在，比如快的打车，它很可能会整合到阿里巴巴里，虽然目前的烧钱看起来是两家打车软件的竞争，但最后软件一定会被收编到互联网巨头的手中，进而形成一个‘出行-娱乐活动-回家’的另一个‘闭环’。”

从盈利的角度看，看似免费的“移动支付”钱包，其实可以给阿里巴巴或是腾讯带来不菲的利益。根据海通证券的分析，“第三方支付”盈利模式主要来源于4部分，收单手续费、备份金利息、预付卡和平台建立带来潜在收益。客户在使用虚拟账户消费转账过程中，会在备付金账户内沉淀出一定规模的资金。这部分资金的利息收入归第三方支付机构所有。但第三方支付机构并不能够对备付金账户中的资金随意处置，只能存活期或最长一年的定期存款，因此这部分资金绝大部分只能获得活期利息收入。

罗宇认为，如果你正在享用打车软件的“免费的午餐”，你就成了移动支付的“钱包”。

“此外，腾讯和阿里烧钱大战，‘大数据’亦是其目的之一，自打车软件推广以来，线上客户不断增加带来‘大数据’。阿里和腾讯可以通过这些用户的网络足迹分析出其娱乐、购物等一系列经济活动，从而有的放矢地展开商业攻势。”罗宇说。

“二马”最近频繁的动作似乎是印证这些判断的最好例证：腾讯日前与大众点评宣布达成战略合作，并入股京东15%；阿里巴巴则在多个平台出击，比如在餐饮领域推出“淘点点”，在服装领域推出“微淘”。李易认为，对于“二马”来说，打车软件只是帮助他们完成O2O布局的重要手段之一，而包揽整个移动互联网市场才是他们的真正目的。

烧钱大战伤害打车行业？

烧钱大战是否真的能为两大巨头包揽庞大的“移动互联网市场”打下坚实的基础尚未可知，但烧钱大战点燃的争议却一点都不少。比如不少司机忙于应付打车软件的订单，从客观上增加了扬招打的的难度；而使用打车软件的以年轻人居多，这样就使得不会使用打车软件的特殊消费群体（比如老年人等）难以顺利打到车；还有一些司机师傅为了获取更多的订单，在出租车上装两个打车软件，不停刷单而影响行驶安全。

打车软件遭受人们争议最多的地方则是在“烧钱买用户”行为和影响市场方面。阿里巴巴支付宝的工作人员王洲（化名）接受记者采访时说：“先以蝇头小利来吸引用户，培养用户使用手机支付的习惯，然后再从商家和你身上赚钱，这是互联网行业很成熟的案例。不仅是中国老百姓，在全世界的老百姓对占便宜这事儿都是趋之若鹜的。”

但是记者通过采访发现，很多打车软件用户表示，如果补贴取消后，将不会频繁使用打车软件。“有补贴之后，我经常打车回家，如果以后补贴取消了，我可能还是会更多地选择公共交通吧。”在东直门附近工作的王先生告诉记者。商务部电商和信息化司副司长张沛东也在今年3月的“两会”上表示，打车软件“花钱买用户”营销策略是不可持续的。

此外，这场烧钱大战背后其实暗藏危机。李易说，由于各大互联网巨头涉及的领域错综复杂，利益相关，大家都想做成全产业链的模式，形成自己巨大的“互联网帝国”。如果政府像过去一样放纵互联网野蛮生长，遵守“丛林法则”的话，互联网创业在一定程度上会被扼杀。像之前的摇摇、大黄蜂，作为打车软件第一批先行者，在嘀嘀和快的疯狂“烧钱”中成了炮灰。

其实，烧钱大战已经在互联网行业造成了“尸横遍野”的景象。“去年本来是有二十多家企业在做打车软件，如果腾讯和阿里不拼补贴，这些软件就可以进行自由的创新，极有可能创造出对用戶更优的体验。可惜现在只有两家了，软件已无创新之处。创新不是用钱创出来的。”罗宇告诉记者，“竞争也要讲究策略和规则，目前两大公司的竞争越来越像价格战，这未必是好事。比如京东、当当、移动和联通都曾发起过价格战，有些企业因此严重损伤了元气，继而让全行业蒙上阴影，继而顾客也未必长期获益。目前，打车软件的竞争也在滋生一些弊端，靠补贴抢客户恐怕也不是长远之计。”

随着打车软件的“火爆”，除了以上种种问题，其他安全隐患也逐渐浮出水面。在大部分人不仅享受着打车软件的补贴，更享受着司机的“专属服务”时，有的乘客用软件招来了“黑车”，有的乘客因手机支付不成功而被司机索要补贴，还有人担心绑定银行卡不安全、私人信息会被泄露……

火热背后有风险

乘客的担忧并非空穴来风，打车软件前方“烧钱正旺”，后方“大院起火”。用户们疯狂用补贴，司机们疯狂抢单，使得打车软件后台系统的压力也大幅度提升，导致嘀嘀和快的两个软件相继“崩溃”。2月18日，嘀嘀系统瘫痪，无法使用微信支付；快的则出现定位乘客位置故障等问题。处于升级中的两个软件，背后也存在一定的技术风险和法律风险。

“在安全漏洞方面，打车软件的情况已经比去年好很多了，尤其是腾讯和阿里两大巨头加入进来后，用户的移动支付和个人信息安全得到了很大的保障。”李易提醒广大消费者，虽然用手机进行的是小额支付，但现在黑客水平高，钓鱼软件增多，不可否认，风险总是客观存在的。尤其是当用户已经受到了切实的利益损失，用户、移动支付、打车软件这三方的归责与界定是不清楚的。

无论是嘀嘀和快的，在进行移动支付时都牵涉到个人姓名、手机号、银行卡号等许多个人信息，这不仅涉及用户的个人信息和隐私，还关系着用户银行卡的资金安全。

从用户信息安全来说，第三方支付都有关于用户个人信息保护的条款，其中规定需运用各种安全技术和程序建立完善的管理制度来保护用户的个人信息，但因用户管理不善可能导致的遭受盗号或密码失窃，责任由用户自行承担。

“打车软件通过移动支付来付费，第三方支付平台作为付费的渠道就有义务来保护用户的个人隐私。”北京市昌平法院的刘法官告诉记者，“如果用户认为自己被第三方泄露或倒卖了个人信息，这就牵涉到证据问题。个人隐私被泄露的途径其实很多，也很难证明，比如你去工行办银行卡，填写了身份证号、工作、居住地址等许多个人信息，也可能会泄露你的隐私。通常，用户无法证明侵权行为是谁造成的。而证明责任的分配主要看过错、因果关系，如果用户状告第三方侵权，而证明不了侵权人是谁，像这种没有证据证明侵权方的侵权行为的情况，在法院可能连立案都很难立上。”

刘法官认为，这种没有确凿的证据证明侵权行为的情况，用户维权最好通过消费者组织（如消费者协会）、公益诉讼等途径，才有可能得到一定的证据，进行群体性诉讼。单靠个人举证是很难成功的。在国外，很多消费者也是以“群体对群体”的方式来解决问题的。

从用户资金安全的角度看，用户也面临法律上的障碍。以微信支付为例，《微信支付用户服务协议》提到，微信支付是由深圳财付通科技有限公司提供。根据协议，财付通公司在接到用户通知之前，对第三人使用微信支付已发生效力不承担任何责任。而且对于被诈骗或被恶意软件非法划款的用户来说，财付通公司也不对经济损失承担任何责任。

对此，北京大学网络法律研究中心研究员刘德良说：“对于网络支付、移动支付发生的纠纷，目前法律没有明确的规定，学界也没有一个统一的认识。传统上，消费者在消费时遭受损害可以要求商家赔偿，但是能不能直接应用在网络支付上，学者关注得比较少，对纠纷性质的认识也存在一定分歧。我个人认为和传统商家一样，网络、移动支付的商家也负有安全保障义务。随着这些业务的发展，未来应当在立法上明确双方的权利和义务，包括支付风险的责任分配。”

“如果移动支付用户遭受了资金上的损失，一般可以通过合同条款进行维权。以腾讯为例，用户和公司之间是有契约关系的，如果是由腾讯本身疏忽导致的漏洞，且不符合國家规定的通常责任义务，即谨慎义务时，腾讯就需要承担责任。”刘法官也认为第三方支付机构有提供安全保障的义务。

法律规章和市场监管亟须迎头赶上

烧钱大战这把“火”的火势越来越大，价外加价、运营途中操作打车软件抢活带来安全隐患、市民路边扬招越来越难……这些竞争带来的弊端也引起了地方监管部门的关注。

2月20日，北京市交通委员会公布打车软件“限装令”——每辆出租车只允许安装一个手机叫车终端，而对于手机里装了几个软件并无限制。尔后，上海市交港局规定早晚高峰时段出租车严禁使用打车软件提供约车服务。

这些刚出台的规定无疑是这把“火”的降温剂。但北京市交通委的规定也引发了另一场争议，限制打车软件合法吗？打车软件该怎么管？

“从行政法角度看，可能很多人会问，打车软件应该是由市场来解决的问题，政府出台这么些限制规定是否是滥用权力呢？我认为，在市场和公共安权同时面临冲突和矛盾的情况下，政府有责任介入来解决问题，不能把事关公共安全的事情完全交给市场，这也是政府存在的价值和功能。”国际关系学院行政法教授毕雁英告诉《方圆》记者，打车软件事关公共安全，规定的出台合法合理。

毕雁英说：“这些规定可能会让大家觉得不合情理。因此政府也有责任想办法来解决因限制打车软件造成的困难。只有在管理和技术上有更多更细致的改进，才能满足社会各方面、各层次的人群需求。”

“最近有传言说腾讯和阿里巴巴要坐下来‘喝杯茶’，但我认为他们喝茶谈合作是不太可能的。而且如果两大巨头联合，就很可能会形成市场的垄断，这就涉及不正当竞争行为，是法律所不允许的。”李易说，我国互联网产业已经到了一定的“深水区”，不再能够“摸着石头过河”了。打车软件的竞争应当回归理性，不仅要依靠市场的“无形之手”，更要有政府的“有形之手”主动参与。

正如全国人大代表交通运输部部长杨传堂在“两会”时所说，对于手机招车软件，我们总体上是支持和鼓励发展的，但对存在的问题要逐步调整和规范，下一步，交通部将会同有关部门，加快研究制定规范手机招车软件发展的指导性政策，规范解决当前存在的各种问题。

北京、上海等监管措施的出台，不仅是为了让打车软件真正发挥作用，缓解打车难的问题，为乘客提供切实的便利；更是为了对有损市场公平的行为进行坚决的抵制和管理，堵住政府监管上的空白，消除潜在的法律风险，让打车市场健康、合理、有序地生长。

软件项目风险管理 篇4

1.1 风险的定义

风险定义有好几种, 一是不希望事物发生变化, 二是事物存在很多的, 三是事件产生的影响。可以概括为“人们因对未来行为的决策及客观条件的不确定性而可能引起的后果与预定目标发生多种负偏离的综合。”公式表现为:风险f (事件, 不确定性, 后果) 。用数学表达式则为:R=f (s, P, X) , 其中R表示风险, S表示时间, P表示不利事件发生的概率, X表示该事件发生的后果。

1.2 风险管理的背景

随着社会对软甲的需求增大, 软件的开发技术不断更新, 难度不断增大, 但软件的数量却依然增加很多, 同时随着社会节奏加快, 软件的供应商需要提供不间断的软件更新服务。但与此同时, 各种难度的上升, 给企业在开发软件的过程中加大了风险。软件项目能否开发成功, 关系着一个企业的生死存亡。但矛盾的是, 随着开发软件的业务增大, 但对软件的质量和用途也随之提高, 这对软件开发商造成了巨大的压力, 在这种情况下, 软件风险管理和控制成为软件开发成败的关键点。

根据有关资料调查显示, 有百分之十五到百分之三十五的软件项目在开发的过程中被取消, 剩下的软件项目有的是没有在预期内完成而夭折, 或者又是软件开发的过程中超出了经费的预算。除此之外还有软件项目因为风险管理和控制失败的大约占百分之九十。目前国内的大多数软件开发企业还缺乏对软件开发项目的风险认识, 缺少进行系统、有效的度量和评价的手段。所以能建立有效的风险识别、风险分析、风险计划、风险跟踪和风险对策的机制, 是有效提高软件开发成功率的方法之一。

2 风险管理的内容

为了最大化的减少软件风险的发生, 可对软件项目进行风险管理。而软件项目风险管理过程是指软件风险从认识到采取措施的过程包括风险识别、风险分析、风险计划、风险跟踪和风险对策等, 从而将可控因素最大化, 将不可控因素到最小, 从而对未知的风险消灭, 从而对风险进行回避或者缓解。

2.1 风险识别

风险识别的常用方法通常有现场观察法, 财务报表法、环境分析法、流程图法、座谈法、相关部门配合法等。风险识别要确定影响本项目的潜在威胁的来源以及在何种条件有影响, 怎么产生并有什么特性等, 风险识别并不是一次就可以后顾无忧的, 需要贯彻到整个软件的生命周期中。

2.2 风险评估

风险评估时对风险影响力进行衡量的活动, 即衡量风险发生的概率和风险发生后对项目目标的影响程度, 从而为后面制定风险对策提供依据。对已识别的风险要进行估计和评价, 常用的方法有:概率分布、外推法、多目标分析法等。

2.3 风险计划

风险计划:风险计划是通过技术手段或者其他方法来降低风险的发生, 将风险评估后的结果进行处理。风险计划就是在软件开发的过程中起指导作用, 如先处理那个风险, 怎么消除风险, 如何避免风险等。

2.4 风险应对

风险应对就是对风险计划的执行, 共有三种方向来进行风险应对。一是风险控制法, 对存在风险进行主动出击进行消灭或许能避免风险:二是转移风险, 将存在的风险进行转移:三是风险存留, 就是风险威胁不大时, 可以对风险不采取任何措施。当然在软件的开发过程中, 要想有效的消灭风险, 就得让风险还在初级阶段的时候消灭。再者就是风险发生时, 要考虑后果再最大化的缓解风险。

3 风险的分类及各类风险产生的影响

3.1 组织和管理风险

一是管理层做出了错误决定, 技术决策导致计划进度缓慢, 延长计划时间;二是低效的项目组结构降低生产率;三是管理层审查决策的周期比预期的时间长;四是预算削减, 打乱项目计划;五是工作失误与重复工作;六是非技术的第三方的工作时间比预期的延长。

3.2 需求风险

在软件开发的过程中, 如果不能控制和需求有关的风险因素, 那么将会产生不好的结果, 如软件有可能是错误的软件或者质量不合格的软件。当然很多软件开发项目都会面对这些不确定的威胁, 如果早期对于这些不确定的风险置之不理, 那么在项目过程中也得不到解决, 那么“千里之堤, 溃于蚁穴”, 这些不能控制的威胁将对软件成功的开发造成巨大的威胁。

与客户相关的风险因素有, 第一客户对软件缺少清晰的认识, 没有对开发的软件各方面的特性以及功能有个全面了解。第二对产品需求缺少认同, 当软件成功开发时, 但对软件由于认识度不够或者别的原因导致对开发出来的软件缺少认同感。同时还存在一些需求风险因素如在做需求中客户参与不够, 又或者是没有优先需求, 再就是由于不确定的需要导致新的市场, 其次是不断变化需求和缺少有效的需求变化管理过程以及对需求的变化缺少相关分析等。

3.3 合同风险

风险存在的概率很大, 大多是因为合同里的条款比较多引起的。比如如果在软件开发的过程中, 没有对开发软件的范围有准确的定义, 并且成为合同中一部分时, 此项目即便成功了, 也很难验收, 并且项目开发的时间加长了, 极大的加大了开发的成本。这就符合了软件项目经常以一定的价格签订合同, 但签约方却希望更多的功能。

3.4 设计和实施的风险

在软件开发的准备工作, 因为设计不满足要求, 导致软件重复设计。在无法使用已有的代码或者库实现新开发软件, 导致软件的必要功能有问题, 因此软件开发人员需要重新设计代码或库现实又或者重新开发软件的功能。其次认为增强工具能节省很多时间, 但却没达到应有的预期效果。最后, 不能有效的连接整合开发的模块, 需要重新设计和开发。

3.5 人员风险

软件开发需要大量的人才, 所以人员也是风险的一个因素, 如果软件开发前, 不能对员工进行有效的培训, 那么软件开发必然受到一定的影响。再就是开发员工们和领导的关系不好, 那么必然导致领导的决策执行缓慢, 且效率不高, 工作积极性不佳, 必然影响全局。领导层不仅要和开发人员交流沟通, 塑造一种团结合作的气氛, 同时必须鼓励员工可以是口头赞许或者是物质奖励激发开发人员的工作积极性。对于员工有可能不熟悉公司的开发环境和开发工具, 其次是在软件开发过程中, 有可能后来加入的开发员工, 不熟悉开发软件的现状, 所以就需要加大开发员工之间的沟通。对于一些评估不好的开发人员, 在软件开发的过程, 由于自身的缺点而影响到其他开发人员的积极性又或者同个组里的人员因为某些事情而发生争吵, 导致沟通不利, 所以导致设计不妥或者其他一些小错误出现。最后就是企业没有招到拥有特定的人才来开发一些特别的软件。

3.6 过程风险

在软件开发的过程中, 过程因素也是一个不容忽视的风险, 在开发过程中, 如果纸面上的设计跟不上该项目工程的实施, 那么将会导致进程的计划严重推迟。如果软件开发的前期, 没有做好充分的准备工作, 那么将会导致后期工程的风险大大增加, 基础没打牢, 将会导致后期需要重复的做基础工作。其次是, 编程人员与设计人员没有良好的沟通交流, 导致软件的出炉不能符合设计员的想法, 导致质量不达标, 严重时需要重新开发软件。有时候过于守旧即就是对软件的规则反反复复的提及, 这将会导致无用功做的过多, 而实际工作少, 这也会推荐软件完成计划推迟。其次是软件开放程序员大部分时间用于软件开发的实时过程报告而占用过多的时间, 这也会将原定计划打乱。最后, 由于风险管理不细心, 没有发现软件存在的风险。

3.7 质量风险

质量风险通俗来说就是质量没达到客户的期望, 但产品质量如何好, 其风险总是存在的。在软件测试时, 即便开发商在模拟用户的各种场景及用途, 但也不能保证万无一失, 因为无法覆盖全部的操作路径, 总会存在一定的差异, 所以无法使客户百分百的满意。但是纠结如何消灭质量风险是毫无意义的, 关键是如何降低质量风险, 提高顾客的满意度, 因为提高了软件的质量, 客户的满意度也会随之上升, 这也就是控制质量风险。导致软件质量低下的原因是在原则上对软件的质量实行了保证, 但在实际过程中对软件测试的忽略或不看重;软件的复杂性导致水平要求较高以致很难实现;没能全面理解客户的需求, 导致客户对产品不满意甚至拒收;需求变更导致测试不足, 新产生的严重缺陷没能被发现;设计评审、代码评审不足都可能错过某些严重的问题。

4 风险分析和控制

4.1 风险分析

软件项目风险经常会包括许多方面, 是指软件项目开发风险在其包括开发过程、运作过程、维护过程几个阶段, 它们覆盖了需求、设计、实现、确认以及维护等活动所遇到的所有预算、进度和控制等各方面的问题, 或者是由这些问题而产生对软件项目的影响。如:软件缺乏用户的测试、软件开发没有领导层的支持, 模糊要求, 没有计划和管理等。

为了对风险分析从而进行控制以及管理又或者将风险降到最小, 而这些对软件项目开放的成败具有巨大的影响, 尤其是上述都是软件项目成败的隐患, 所以常常利用风险分析软件对风险进行分析。常用方法有风险条目检查表, 它是利用一组提问来帮助项目风险管理者了解在项目和技术方面有哪些风险。在风险条目检查表中, 列出了所有可能的与每一个风险因素有关的提问, 使得风险管理者集中来识别常见的、已知的和可预测的风险, 如产品规模风险、依赖性风险、需求风险、管理风险及技术风险等。风险条目检查表可以不同的方式组织, 通过假设分析、成本效益分析、风险剖面分析、判定树等, 给出这些提问确定的回答, 就可以帮助项目管理人员估算风险的影响。

为了让软件管理人员和开发人员能够直观的看到在软件开放的各个阶段存在的风险的状况以及每个风险危险的大小, 通常我们可以凭借风险条目检查表来做到。当一个团队接到软件开发的项目时, 通常都是按照自己已有的习惯来开发软件, 但这其中存在风险发生概率比较大, 尤其是在需求风险方面和管理风险方面, 往往决定软件开发的成败。在软件开发完成时存在很多必要的内容缺失, 是因为在软件的分析阶段不够细致, 需求风险意识淡薄所致。在整个软件的开发过程, 如果需求风险控制不好, 那么对软件开发的不利影响是巨大的或者是直接导致软件开发失败。管理风险是软件开发的管理层对与软件开放的风险意识的预见和解决的综合反映。

4.2 风险识别

在软件项目的开发过程中, 风险无处不在。如果不能正确的识别和控制风险, 那么点滴的疏漏就有可能把项目推向崩溃的边缘。

首先, 软件项目风险具有繁殖能力。如果不能识别初级风险, 那么这个风险很可能在项目推进过程中衍生出其他风险

其次, 软件项目风险具有变异能力。如用户需求的定义, 不同设计人员, 定义的结果就会发生差异。

最后, 软件项目风险具有依赖性。风险们互相依赖, 互为因果。它们就像一张无形的网, 如果找不到正确的节点, 那么它们会越搅越乱。

4.3 风险控制

为了转移或避免风险而利用一些技术, 如原型化、软件自动化、软件心理学、可靠性工程学以及某些项目管理方法等叫风险控制。发现问题要立即上报, 尽快解决。并建立风险监管日志, 实行“岗位负责制”, 将软件开发项目的风险降到最低。

参考文献

[1]俞立伟, 薛胜军.软件风险管理[J].电脑知识与技术, 2006 (35) .

[2]梁涛, 欧立雄, 黄柯鑫.基于聚类分析的软件项目风险趋势研究[J].信息工程大学学报, 2006 (01) .

[3]曹光忠.软件项目的风险管理[J].计算机时代, 2005 (06) .

[4]付玉, 邱冠周, 冯其明, 高阳.应用软件开发的需求风险及控制[J].计算机工程与应用, 2005 (13) .

[5]]孟祥睿.软件项目风险管理研究[J].经济论坛, 2005 (07) .

[6]郭研.软件项目管理[J].物流科技, 2005 (02) .

[7]蒋国萍, 陈英武.基于面向对象贝叶斯网络的软件项目风险评估[J].系统工程与电子技术, 2005 (02) .

[8]蒋国萍, 陈英武.基于关键链的软件项目进度风险管理[J].计算机应用, 2005 (01) .

[9]陈忠.软件项目的风险管理[J].经济与社会发展, 2004 (12) .

[10]王敏晰.软件项目管理中人员流动风险的管理[J].商业研究, 2004 (17) .

软件开发风险管理研究论文 篇5

摘要：在软件项目开发过程中，存在着诸多风险，举例来讲，有技术风险、资金风险、组织风险、财务风险等，如何识别并防范这些风险，将是影响项目能否顺利完工的重要因素。在项目实施过程中，因涉及干系人众多，需要对相关组织机构以及具体时间安排等方面加以协调，由于上述原因，在一定程度上提高了项目实施的风险性，因此，实行合理高效的项目风险管理对维持项目实施的正常秩序至关重要。

关键词：软件;开发;风险管理

在进行项目管理时，应当依据现实状况，遵照项目风险管理的主要原则，加大对其中存在的风险性的重视程度。首先，应当确立合理详尽的风险管理计划，能够发现和预测其中存在的风险性，并且对风险清单进行定性和定量的分析，对发生可能性较大和对项目运行可能产生的影响较大的风险采取针对性的措施予以削弱，另外，利用多种方法和举措，对项目运行过程中的各个环节、各个阶段存在的风险性加以检测和处理。下面从风险管理计划到风险监控，浅论如何做好项目风险管理。

1确立风险管理规划

从理论上来讲，风险管理规划是指制定关于风险鉴别、风险分析和风险削弱的具体措施，并且对相关的管理机构以及具体的行动纲领加以明确。相关的项目管理组织应当通过举办讨论会议，采纳参会各人的合理意见，并且依据项目内部、外部环境特征与过去的操作经验初步确立针对性的风险管理计划。并且确立具体的风险鉴别、风险分析、风险应对的操作流程，对风险管理规划的成本进行预测，实现操作成本与具体活动的无缝衔接，为以后的`项目风险管理奠定基础。

1.1风险鉴别

风险鉴别是指对可能对项目运行产生影响的风险性加以分析，并记录下来。相关负责人应当有项目经理、项目团队成员等，争取形成相关工作人员参与风险鉴别的全员性。风险鉴别是一个不断反复提高的过程，伴随项目过程的进行，新的风险可能会出现，这就要求项目团队定期开展风险识别会议，并在每一次风险识别过程中，让团队成员始终保持责任感。应当准确鉴别出可能对项目运行产生影响的风险性，并结合其具体特征逐个击破。把鉴别出来的风险性登记造册，来对其进行实时监测，从而可以及时的消除可能出现的风险。一般在项目中，我们识别的风险主要有技术风险、外部风险、内部风险。技术风险主要是技术团队在某些陌生领域的技术短板，而影响到整体项目的进度、成本、质量等问题。软件技术的快速发展和经验丰富员工的缺乏，是造成技术风险形成的主要因素。因此，要对技术风险进行提前防范，采取合适有效的措施解决技术风险。外部风险主要是来自项目外部，如：涉及的开发商、施工方众多，如果与任何一个外部单位对接出现问题，都会对整个项目进度造成影响;另外，需要采购外部单位设备规格不同，设备改造升级工作量大，施工时间不充裕可能成为工程进度的风险，影响项目正常进度。内部风险主要表现在资源协调方面，主要是项目团队在人员组织和调配上，出现的风险问题。例如：新的突发事件，占用项目成员的工作时间，进而可能对此项目的进度产生一定影响。

2风险定性分析

风险定性分析是指分析各种风险出现的概率以及其对项目产生的影响的大小。另外，也要对这些可能出现的风险等级进行排序，加大对风险性高的方面的重视力度。所以，可以邀请专家和相关专业技术人员对内部环境、外部环境以及现实情况进行具体分析，并且可以通过利用分析矩阵明确风险等级，最后要将上述分析结果登记造册，以便实时监测。

2.1定量风险分析

定量风险分析是指对各种风险对项目的影响程度加以定量的确定。具体来讲，要组织专家、专业技术人员以及相关工作人员对项目实施各个环节可能出现的风险加以分析，立足于量化的角度分析其影响程度的大小，最后要将上述分析结果登记造册，以便实时监测。

2.2风险应对计划

风险应对计划是指通过对经过定性、定量分析后的项目风险分析数据进行分析，进一步确立项目的有机影响方面和不利影响方面，并采取科学合理的带有针对性的应对举措。如：针对技术风险，可以培训、聘请顾问以及为项目团队招聘合适的人才等进行防范。为避免外部风险，制订沟通计划，与干系人积极交流，加强工作联系，定期沟通汇报，一旦出现问题，项目组对具体问题进行分析研讨，及时解决。对于内部资源协调问题，与主管领导进行协商，协调其它部门抽调人员加入项目组。风险都需要进行提前的预判，针对各风险的关键点进行分析讨论，最终形成风险识别清单和应对措施，从根本上消除风险或把风险降至最低。

3风险监控

浅谈软件编程的风险规避 篇6

关键词：软件编程;风险;规避;措施

中图分类号：TP311 文献标识码：A 文章编号：1671-864X（2015）01-0161-01

人本思想在现代社会中广泛应用，并在企业经营过程中转化为了更适合企业发展的以客户为中心的经营理念。软件编程的过程中，编程人员也受到了这种以客户为本思想的影响，因此开始关注客户的需要，并以此为基础进行软件的编程。而在现代标榜个性化的社会中，客户的需要层出不穷，因此需要软件编程人员及时的搜集客户信息，并以最快的速度完成软件编程。这种快速、多样的发展模式，使得软件编程过程中经常会出现一些意料之外的问题，造成软件开发无法继续，软件公司遭受损失。

一、软件编程中存在的风险

现实生活中风险存在可控性，但是风险却不能被彻底的杜绝，并且风险存在于一切活动之中，与活动内容之间有着密不可分的关系。在软件编程的过程中，风险由始至终都形影相随，随时都可能对软件编程工作造成影响，造成软件编程工作时间的延长、成本的提升或者研发的失败。具体来说软件编程过程中存在的风险主要涉及了以下几个方面：（1）时间因素。主要指软件的研发时间，以及研发速度等，（2）资金因素。主要指软件研发应用的成本，以及资金链的供给等，（3）人才因素。主要指研发人员的素质，以及研发人员的专业水平。（4）科技因素。主要指技术的先进性等。上述是软件编程过程中风险出现频率较高的几个方面，除此之外，还有一些没有规律可循，难以预料的风险存在。

在进行软件编程风险规避研究的过程中，我们主要将研究的重点放在上述几个主要的方面上，力求通过有针对性的防范与治理，提高软件编程风险规避的效果。但是对于一些不可预料的风险因素，有关人员也应给予关注，制定一些应急措施，以避免软件编程工作受到过大的冲击。

二、软件编程风险规避的有效措施

（一）做好准备工作，确保资源供给。

软件开发主要以人力为主，是通过技术人员对程序的编写达到研发软件的目的。因此要想确保软件编程的顺利进行，技术人员方面要有充足的保障。所以软件开发企业，应在进行软件编程之前做好准备工作，在公司中打造出自己的专业研发团队，并且注重新人的储备和培养，以避免研发人员不足现象的出现。除此之外，软件开发企业还应保障技术人员研发过程中可以有充足的资源可以利用。例如，保障设备质量;搞好文档机制等等。

（二）做好技术审核，保障技术应用。

为了保障软件编程的先进性，软件企业经常会引入一些新的技术进行应用，但是由于软件研发技术人员对这些技术并没有进行过实际的应用，因此难以保障技术应用的效果以及软件编程的质量。鉴于此，为了避免新技术对软件编程造成不良影响，控制开发过程中的风险。软件开发企业应做好技术的审核工作。首先，搜集技术相关信息，加强对技术的了解，并对技术的核心功能进行掌握。其次，要对新技术存在的风险提前预设，并对风险制定出解决方案，降低软件编程对技术的依赖性。

（三）制定研发方案，提高执行效果。

软件的编程应带有一定的目的性，并且要按照既定的方案，有计划的进行下去。通常情况下软件的研发方案，应包括软件的功能、核心技术、研发时间、进度要求等等。在实际的编程工作中，该方案应是整个编程工作的指导，技术人员应在最大限度内配合方案规定的内容进行软件的编程，以保障软件开发工作可以在预期时间内顺利的完成，并达到理想的目标。

为了让软件编程人员可以按照制定的方案进行编程工作，在制定方案的过程中，软件研发企业需要注重方案的实际性，使得方案的制定真正的符合实际的软件编程工作，减少工作人员的执行难度，使得整个软件编程工作都可以在预期的状态下进行。

（四）完善监督制度，把握编程情况。

风险存在于软件编程的整个过程之中，因此企业需要全程对编程工作进行把控，最好的办法就是建立起全面的监督机制，对软件编程工作进行细致的监督与管理，对可能出现的问题进行及时的发现，提高工作人员的工作质量，保障技术的应用水平。

（五）建立风险控制体系，实现风险提前防范。

风险规避是对已经总结出的风险进行有针对性的避免，而实际的工作过程中仍存在着一些未知的风险，要想对这些风险进行规避存在着一定的难度，不利于软件编程的顺利进行。因此软件开发企业还需要建立风险控制体系，设立专门的风险管理部门或者风险控制人员，对风险问题进行管理，针对可能出现的风险进行预设，并制定出相应的防范方案。并且，软件开发企业的风险防范人员还应积极的关注同行业中其他企业的风险防范情况，从中吸取经验，完善自身风险控制方面的不足。

（六）引入现代科技，实现风险管理。

IT行业发展程度越深，软件编程遇到的风险也就越多，所以风险的规避逐渐成为了软件开发企业核心的工作内容之一。因此一些企业开始提出研发风险控制软件，通过风险控制软件的应用实现风险控制的自动化以及智能化。这种构想得到了广大软件开发企业的支持，并且已经逐步成为现实，使得管理类型的软件在软件编程过程中发挥了风险管理方面的作用。

三、结束语

综上所述，软件行业的繁荣不仅带来了行业的进步与完善，同时也给软件编程工作带来了巨大的压力和风险，因此需要相关企业重视软件编程过程中的風险规避，不断对企业内部的风险管理进行完善，促进软件行业的持续发展。

参考文献：

[1]黄石磊.浅谈软件编程的风险规避[J].科技创新导报.2010（04）.

[2]王维友.试谈软件编程的风险规避[J].电脑编程技巧与维护.2013（08）.

[3]张楠.有关软件编程的风险探究[J].科技传播.2014（19）.

浅谈软件项目风险规划 篇7

在现在的社会中，无论是“项目”、“软件”还是“软件项目”已经越来越被大家所熟悉，而且普遍存在于我们生活或者社会的各个方面。

对于一个软件项目而言它首先具有目标性，工作的目的在于得到特定的结果，因此项目是面向目标的，这个目标贯穿于项目计划和实施活动的始终。其次项目还具有相关性，因为每个项目与生俱来都有复杂性，一个项目里有很多彼此相关的活动，例如，某些活动在其他活动完成之前不能启动，而另一些活动则必须实施，如果这些活动相互之间不能协调地开展，就不能达到整个项目的目标。再次，项目还具有周期性，当我们达到目标后，项目就意味着要结束，因此它是一个临时性的任务。再有，项目还具有独特性，在一定程度上项目和项目之间没有重复性，假如要为新一代的计算机设计操作系统，那么这个系统一定会有独特性，是以前的操作系统没有的特性，这样才有开发的必要。那么，项目还具有约束性，一般约束项目的重点都是资源成本，这是一个项目成功实施的重要约束。最后项目还具有不确定性和结果的不可逆转性，一个项目不可能完全按照既定的预算和流程完全实施下去，很有可能会因为外因或者内因发生一些变化，因此会出现不确定性，而到了项目结果，结果也就出现，就不能够再逆转了。

由于上述的软件项目的特性，可以发现，一个项目最终得到预定的结果，就是要保证项目要顺利按照既定规划实施，而由于项目又有不确定性，那么我们就要对不确定性进行梳理，对项目风险进行管理，规避风险，减少不确定性，只有防患于未然，进行合理的风险管理、制定及时的风险计划，做到主动控制风险，而不是被风险所控制。那首先要明确的就是软件开发过程的风险究竟会有哪些，其次如何识别，最后是规避风险。

1 风险类型

1.1 从风险范围角度看

1.1.1 项目自身风险

这种风险是潜在的预算、进度、个人、资源、用户和需求方面的风险，比如时间和资源分配的不够合理、项目优先级没有配比好，资金不足等等都是风险的根源。

1.1.2 技术风险

比如技术上的一些不确定性，技术陈旧。有些技术相对复杂，项目执行过程中使用技术或者行业标准发生变化所导致的风险。

1.1.3 商业风险

主要包括策略风险、市场风险、预算风险，比如开发出的软件并不是市场认可的软件，那么风险可想而知。

1.2 从风险预测角度看

1.2.1 已知风险

通过仔细评估项目计划、开发项目的商业和技术环境以及其他可靠的信息来源之后可以发现的那些风险。例如，不现实的项目交付时间，较差的技术环境等。

1.2.2 可预测风险

指根据以往项目经验能够提前获知的风险。

1.2.3 不可预测风险

指很难事先识别出的风险，会根据项目的进行情况而突发的风险。

那么根据上述的风险类型可知，要规避风险，接下来就是对风险进行识别。

2 风险识别

风险识别是试图系统化地确定对项目计划的威胁，识别已知和可预测的风险，识别内在和外在的风险，贯穿整个项目中的行为。常用到的项目识别方法中最多的是风险条目检查表法，其次还有德尔菲法、头脑风暴法、情景分析法，面谈法。而这一切方法都是为了识别出风险，并会将风险输出为风险列表。识别出的风险列表会有两列，一列是识别出的风险，另一列是对风险进行的分类。通过对识别出的风险列表进行分析、评估，对风险发生的概率进行估计、对发生后的后果进行估计、对后果所产生的影响进行估计都是在识别出风险之后做的事情，其实就是对风险进行评估。评估后，要对风险分析后的结果进行统计，这个统计主要是，要列出风险及风险所对应的类型，可能发生的概率，发生后产生后果的影响效力指数，以及对若干个风险进行一个排名。这样我们对软件项目中所存在的风险就能掌握在手。接下来就是如何规避风险，降低风险发生的几率。

3 风险规划

风险规划并不能够消除所有的风险，但是能够通过合理的规划来规避一些已经识别出的风险事件。比如说，当我们知道人员流动会给软件项目带来人员数目及经验的风险，那么就可以及时的制定计划，比如，对项目中的重点实施人员提高补贴，对项目完成后的奖励进行说明，稳定人员，减少其流动性。这是风险规划的一种。风险规划一共有以下几种形式：

3.1 回避风险

这是对可能发生的风险尽可能地回避的一种方式，比如拒绝使用导致风险的方案。这种方式通常是切断风险的起源，一般针对于风险发生后影响巨大的风险类型，如果影响很小，我们启用别的方案也许会带来比这个方案还要大的风险影响。及时风险发生后影响巨大，这种风险规划方式也不适用于立即使用，我们还是要寻找其他的风险规避的方法，实在不行才能用这样的方式。然而也不是所有的风险都可以用这样的方式来规避，比如突发的风险是无法用这种方式规避的。

3.2 转移风险

这是从发生风险产生损失后的责任入手的方式。比如一个大型的软件项目开发，环节复杂，监管困难，多个环节都存在巨大的风险，为了降低风险，可以将一些风险大，自身又顾及不到的小项目交给其他的公司去做，这样风险就转嫁到了他人的身上，一旦风险发生，产生损失，可以对其他的公司问责，减少了自身的损失。这是一种转嫁的方式，还有可以与软件项目的委托方达成一定的协议，有一些不可预测的风险一但发生，可以免责，比如天灾发生，延误了软件项目的交付时间，如果有了免责条款，那就可以避免损失。再有，可以参加保险，将风险转嫁保险公司，一旦发生严重后果，有保险公司来负担损失也是不错的办法。

3.3 损失控制

这是指风险发生前就消除风险因素和减少风险损失的方法。比如，风险识别分析之后，对于一些风险可以提前做出预防，就好比人员流动风险，我们可以采取措施减少人员的流动，来保障项目的顺利进行。还可以有备用人员来防止一旦有员工离职而无人可用的尴尬境地。是风险减缓，尽可能少的产生损失。

3.4 自留风险

而自留风险是承担风险的一种方式，承担风险可以是消极的也可以是积极的，合理判断后仍会产生的风险，我们就可以通过研究决定将这样的风险承担下来，而不是说都不知道这个风险因素就被动的必须承担。

4 风险规划结果

风险规划的结果其实就是我们面对风险应该采取的措施，根据风险类型的不同，风险影响力的不同，通过不同的规划方案得到不同的措施。举个例子，在系统设计评审的时候因为没有足够的时间进行软件产品的测试而产生的风险，可以采取的让员工加班的方法规避，也可以修改项目计划去掉一些任务来规避，还可以去和客户商量延长交付时间来规避。假如在需求和计算阶段遇到了采用新技术会导致任务延期的风险时，我们可以去培训开发人员，或者招募一些有新技术经验的工作人员，也可以找来专家对开发过程进行指导跟踪，还可以采取边开发边学习的方法，让员工在规定的时间内掌握新技术。

这样软件项目的成功率将得到提高，风险事件发生的损失将会在掌控之中。

摘要：文章以规避软件项目风险为目的,利用软件项目的特性和其产生风险的类型,以及风险规避时用到的方法,阐述了软件项目风险规划的观点。

关键词：项目,风险,规划

参考文献

[1]韩万江,姜立心.软件项目管理案例教程[M].北京:机械工业出版社,2005.2.

[2]张艺.软件项目中的关键风险管理[J].吉林省教育学院学报(学科版)2010,(02).

[3]方德英,李敏强,寇纪淞.软件项目风险管理方法的比较与分析[J].运筹与管理,2004,(03).

[4]杨荣光,李月梦.项目管理的控制实施[J].现代企业教育,2005,(03).

[5]罗东坤.实行项目管理的几个理论问题[J].石油大学学报(社会科学版),1993,(01).

软件开发风险之浅析 篇8

1. 需求内容描述不清

分析报告上文字不准确、不规范。需求变化的风险:由于分析人员在进行需求分析时是很难预测客户将来的需求变动的, 所以, 需求分析只是针对客户已经确定的需求。需求理解错误的风险:阅读者因为报告中的文字表达或者本身水平而很难理解需求分析报告中有些语句。需求分析错误的风险:对客户提出的需求可行性研究不够深入, 从而产生分析的偏差。

2. 软件设计中的风险识别

除了需要与供应商的系统功能共同设计外, 对现有的系统构架, 如网页浏览构架还是服务器客户端构架的决策, 网络拓扑形式, 数据库软件的选取等等设计元素是否与当前的信息系统和网络平台相兼容。

二、软件开发与风险

软件开发有4大要素:人员、项目、产品和过程。软件开发过程就是将用户需求转化为产品所需要的完整活动的集合, 是建造高质量软件产品的框架。一个软件开发过程定义了软件开发中采用的方法、模型等, 是对软件项目进行控制和管理的基础。软件开发过程与软件风险有紧密的联系, 历史上也出现过许多软件开发过程模型。风险, 有着不确定的特性, 但是并非所有不确定的事物都是风险。而软件开发过程中自g风险, 指的是在软件开发过程中, 或者在软件项目的管理活动中, 项目管理人员不希望发生的、消极的结果发生的可能性。

三、软件开发过程中的风险管理

1. 风险管理

风险管理是贯穿于软件项目开发生命周期的全过程的, 它的目的是为了保障软件开发项目按照计划进行。它对软件开发的策略、工具、技术和方法进行整合, 对风险评估、计划、排序和监督活动进行控制, 是项目管理非常重要的组成部分。风险管理是系统全面的、明确的, 而且与常规的软件项目管理是相容的。风险管理可以根据开发类型、项目种类与客户类型灵活选择, 这样就满足了系统全面性的要求。而与常规管理的相容性使得风险管理与常规项目管理避免出现矛盾, 可以充分利用项目开发资源, 是动态进行风险管理的必要条件。

2. 软件开发风险管理的发展

在软件开发早期或者说还不是很发达的时期.软件的开发基本上采用的都是调码+调试的过程.但是.困难和调试的成本引发了20世纪50年代末期的软件危机为了应对软件危机.软件界希望借用工程的思想解决这一危机.于是出现了软件开发模型。

软件开发过程中的风险是软件项目预期结果的一种概率事件, 这个可能性是以概率或者概率区间来表示的, 而结果可以用一些确定的值或者值区间来表示。预期结果与软件开发的环境、所掌握的知识、开发状态等方面有关。在软件开发项目管理中, 风险可以用实体的概念来描述, 那么实体之间的联系和实体的属性可以用来描述风险的相关性质。风险实体可以表述为一个三元组, 其中各个变量分别为风险环境、预期概率和风险引发后果。

3. 软件项目风险管理的现状

国内学者在I1r软件项目风险管理方面也提出了许多有创建性的研究成果。李清、薛四新依据项目管理知识体系和IT项目管理的特殊性.探讨IT项目管理的体系结构和模型驱动的集成技术与方法。方德英在2003年从方法论角度阐明了风险管理的学科思想、学科体系设计机理和设计准则, 构建了全面IT项目风险管理体系。随后, 在2006年又从组织保障、制度保障和机制保障三个方面论述了组织类型的选择原理、人力资源的配置方法、机制设计的优化思路.并总结了现有的制度标准和度量体系。

四、项目风险管理的内容

项目风险管理主要包括以下过程:风险管理计划编制、风险识别、定性风险分析、风险应对计划编制和风险监视。

1. 风险管理计划编制决定了如何动手处理、规划和实施项目的风险管理活动。风险管理过程的计划编制非常重要, 因为它要保证风险管理的级别、类型即可见性, 和风险本身以及项目对组织的主重要程度是相称的。这样组织才能提供充足的资源、时间来实施风险管理活动。

2. 风险识别决定了那些风险会对项目造成影响, 并记录下这些风险的属性:一般而言, 风险识别的参与者尽可能包括以下人员:项目团队、风险管理小组、来自公司甚至其他项目的专业人员、客户、最终用户、其他项目经理、项目干系人和公司外部的专家等。

3. 定性风险分析对项目的风险进行优先级排序, 以便进行后续的深入分析、或者根据对风险概率和影响的评估采取适当的措施;定性风险分析包括对已识别的风险进行优先级排序, 以便采取进一步措施, 如何进行风险量化或风险应对。

4. 风险应对计划的编制是开发一些应对方案和措施以提高项目成功的机会、降低项目失败的风险;一个有计划的风险应该考虑风险的重要性、成本的有效性、应对的及时性、项目环境中的现实性、是否可以被各方接受以及有一个明确的责任人。风险应对计划的内容要明确出风险的一般应对方法。

5. 风险监控是在项目的整个生命周期内, 监视残余风险, 识别新的风险, 执行风险应对计划, 以及评估这些工作的有效性。执行风险应对措施, 并且连续对项目工作进行监督以发现新的风险和变化的风险风险监控跟踪已识别的危险, 检测残余风险和识别新的风险, 保证风险计划的执行, 并评价这些计划对减轻风险的有效性。

五、重视软件风险管理的必要性

软件工程地定义是为建立和使用正确的工程准则获得可靠的、在机器上高效运行的经济型软件。软件工程包括方法、工具和过程, 它们使管理者能控制过程, 并为工作者提供了以卓有成效的方式构建高质量软件的基础。面对有限的资源、有待改进的技术以及瞬息万变的环境对复杂系统的强烈需求, 要求管理人员必须具备管理项目不确定性的能力。

对目前利润缩减的商业大环境、全球经济极其不稳定的市场条件和技术飞速发展压力下的激烈竞争, 我们都可使用一种应对机制, 针对这一需求, 软件经理和工程师们会根据具体情况, 采用风险管理方法。

参考文献

[1]徐绪松, 但朝阳高技术项目投资风险模糊综合评价模型[J].数量经济技术经济研究, 2000, (1) :34-36

[2]郭百钢.基于Bayes网络的项目投资风险评估与决策方法研究[D].南京:南京理工大学, 2004

有关软件编程的风险探究 篇9

1 软件开发中可能会存在的风险

有过项目开发或管理经验的人都知道, 在项目进行过程中总会遇到预想或出乎意料的风险。例如计划编制风险、项目开发团队风险、开发环境风险、技术兼容性风险、质量控制风险等等。当计划、资源、产品定义不清, 对客户需求和领导要求理解不到位时可能对需求定义偏差, 无法制定出准确的计划。也可能计划设计过于理想化, 缺乏可实现性, 在客户限定时间内无法完成规定的产品。在项目实施过程中一个任务拖延导致相关任务无法按期进行。项目团队配置不佳, 个别成员不稳定, 团队成员不能配合, 导致培训和团队合作效率低, 尤其是项目核心成员的稳定性对项目顺利完成影响更大。开发环境也至关重要, 开发工具没有达到预期的效果, 需要创建新的环境或更换新的工具, 非常耗时。硬件产品之间, 操作系统, 数据管理系统等系统软件与主机设备之间, 系统软件之间, 应用软件与系统软件之间等都存在兼容性问题。前期的质量保证行为不真实, 进度跟踪不准确, 质量跟踪不准确等等, 导致无法掌控影响进度的质量问题。此外, 编程过程中用户可能会提出新的需求, 如果用户提出新的需求或用户意见没有被采纳, 最终无法满足用户期望, 必须重做。或者是对客户需求定义不清, 导致开发额外的需求, 延长了开发时间。以上是软件编程过程中可能遇到的风险, 在执行项目时应尽量规避。

2 对项目进行风险管理

项目风险管理是指对项目风险从识别到分析到采取应对措施等一系列过程, 它包括将对项目产生影响的积极因素最大化, 消极因素最小化。具体的说包括风险识别, 风险量化, 和风险对策。在项目开发计划中应制定风险管理计划。在项目开发前, 项目负责人应根据风险资料库, 项目总体计划等资料, 与项目团队和有关专家共同分析项目可能存在的风险, 分门别类, 预算解决风险所需的经费。在诸多风险中, 影响不同, 对影响项目的关键风险, 应制定措施重点预防或解决。监控风险主要在开发初期, 制定并明确风险管理人员的职责, 是软件编程过程中需要长期进行的工作, 意义非凡, 应予以重视。

3 如何规避软件编程风险

3.1 需求明确

需求不明确是软件开发过程中较常见的问题, 有可能是客户需求阐述不清, 也可能是技术人员和客户理解偏差, 或者是承接项目的负责人或领导要求与客户不一致。要想项目令客户满意, 必须把好需求这道关, 明确需求范围, 注意细节描述, 避免需求前后相互矛盾等。让客户参与开发过程有利于把握客户需求, 选择精通业务或计算机技术的用户参与。根据需求制定出软件开发的主要任务, 设计软件程序的大体框架, 对可靠性做出详细的计划。

3.2 人员储备及技术代码积累

软件企业技术人员流动性大, 储备适合参与项目的后备人员, 对于有离职倾向的人员应采取措施, 保证其所负责的部分能够留下文档, 以便离开团队以后不会影响整个项目的进度。对项目核心开发人员, 应注意维护其稳定性, 保持团队成员的沟通流畅, 以免因团队合作不利或人员流动影响项目进度, 甚至质量。平时对于项目实施过程中产生的代码或接触的新技术应注意积累, 建立开发过程的文档机制, 便于在其他项目中应用, 减少人员流动对编程工作的影响, 提高软件开发的抗风险能力。

3.3 新技术引进

在软件开发过程中, 各种各样的技术风险都可能遇到。项目风险管理人员应对可能使用的关键技术进行调查研究, 对比分析, 因为软件技术更新迭代速度很快, 应对关键技术的先进性进行证实, 以免出现选用了已经落后的技术或编程语言, 影响项目进度或质量。对于新技术, 要充分论证, 尽量掌握最多的信息, 搜集同行经验, 做出正确决定, 减少失败的风险。

3.4 计划制定完备

有了项目计划书, 团队成员才能各尽其职, 协作完成程序编写, 因此项目负责人应根据项目进度制定详尽的项目计划。在项目实施过程中, 各阶段的项目完成情况应接受检查和监督。如遇特殊情况, 项目负责人有必要申请或变更开发计划。如果项目延后, 应对导致延后的原因进行详尽的分析, 必要时请有关专家一起讨论, 听取同行意见等等, 根据原因分析, 制定出相应的指导措施, 保证项目的顺利实施。

3.5 项目监控

项目监控就是围绕项目, 跟踪进度, 掌握各项工作状况, 以便进行适当的资源调配和进度调整, 在项目实施过程中要对项目进行时时跟踪, 使项目按计划规定的进度, 目标, 要求完成, 以利于后续阶段的顺利开展。通过报告, 例会等办法对项目任务, 项目开支, 人员表现进行监控。项目监控可以避免计划在实施中落空, 或偏离正轨。

3.6 产品性能保证

性能问题在系统切换或新系统使用一段时间后显露出来, 这是用户和开发团队都不愿意遇到的问题。首先在系统设计时, 应做好前期性能规划, 对可能出现问题的环节做出充分的估计。开发过程中也可模拟真实使用环境进行性能测试。在项目开发中, 为后期留有足够的调试时间, 进行性能测试, 压力测试, 回归测试, 以保证产品的性能。

4结论

随着软件在各行各业的应用越来越广泛, 行业竞争越来越激烈, 开发难度日益增加, 开发过程中各种风险也在增加, 因而开发进度、成本、质量也受到了影响, 最终受到损害的是软件企业的经济效益。所以, 为了保障软件项目的顺利实施, 以及开发成本的控制, 项目负责人应提高自己的风险管理意识, 为项目负责, 为企业负责, 做好需求确认, 储备人员, 做好技术文档备份, 调研关键技术, 必要时引进新技术, 制定完备的项目计划, 科学监督, 保证产品性能, 最终实现软件开发的任务目标。

摘要：随着我国信息化进程的迅速发展, 软件技术应用范围越来越广, 编程工具等软件开发技术更新迭代速度也越来越快。除了实现用户需求的软件功能外, 对编程中可能遇到的风险也应有所预测, 并加以规避。

关键词：信息化,软件技术,编程工具,风险

参考文献

[1]林引晖, 李伟贤.编程软件中的风险规避分析[J].硅谷, 2013 (8) .

[2]童吉辉.浅谈利用软件编程和借口技术[J].科技咨询, 2011 (6) .

浅谈软件项目风险管理 篇10

软件项目开发过程中存在着大量不确定事件, 这给项目的成功带来了风险。近几年来软件开发技术、工具都有了很大的进步, 但是软件项目开发超时、超支、甚至不能满足用户需求而根本没有得到实际使用的情况仍然比比皆是。有调查显示:

1) 80~90%的信息技术投资并未达到预定目标;

2) 80%到位迟或超过预算;

3) 40%以部分失败告终或最终放弃;

4) 不足25%完全符合了企业和技术的目标;

5) 只有10-20%满足所有既定工作标准。

因此, 风险管理被认为是软件项目中减少失败的一种重要手段。当不能很确定地预测将来事情的时候, 应该采用风险管理的方法来发现软件开发计划中的缺陷, 并且采取行动来减少潜在问题发生的可能性和影响。风险管理意味着危机还没有发生之前就对它进行处理。这就提高了项目成功的机会和减少了不可避免风险所产生的后果。

2、软件项目风险

2.1 软件项目风险定义

风险英文单词是“Risk”, 它来自古希腊单词“Rhiza”, 风险最原始的概念是靠近峭壁航行危险:可能撞上礁石, 可能碰上暗流, 可能遇上从崖上掉下的石头。Webster字典将“风险”定义为“可能的损失、损伤、缺点、破坏”。SEI接受了这个说法, 并将风险定义为“可能的损失”。为了使风险的描述能够被理解, SEI规定风险的描述必须包括两个部分:1) 可能导致损失的当前状况描述;2) 损失的描述。Charette在他的《软件风险分析与管理》一书中将隶属于某一活动、事件或事物的风险进一步定义为如下三个部分:

1) 活动、事件或事物附带的损失。

2) 损失在现有条件下发生的不确定性。

3) 将影响到产出 (如损失程度等) 的一些行为选择。

虽然对于软件风险的严格定义还存在很多争议, 但在风险包含了如下两个特性这一点上已经达成共识:

不确定性——风险可能发生, 也可能不发生;也就是说, 没有100%发生的风险。

损失——如果风险变成了事实, 就会产生恶性后果或损失。

2.2 软件项目风险的影响纬度

一个软件项目实际状态的测量主要包括四个纬度:功能、质量、进度和成本, 这与软件项目的目标是一致的, 即在规定的时间和成本范围内, 提供高质量的符合客户需要的产品。

功能 (F) 可以使用一组产品特性 (pf) 及其重要程度 (fw) 来定义, 如下:

质量的一种简单化表示是由软件项目所包含的缺陷来定义的。因此, 质量 (Q) 可以使用一组缺陷 (p d) 及其严重程度 (dw) 来定义, 如下:

对于进度, 一般使用期望完成的日期来表示, 如“2008-08-30”;

对于成本, 通常使用人力成本或开发工时来表示。如“$18000”、“5000人时”。

根据风险的定义, 风险是指“可能的损失”, 因此, 风险对软件项目的影响也主要体现在这四个维度上, 这四个维度上的任何偏差或不确定性都是软件项目组要关心和控制的。特别地, 进度纬度上的偏差和不确定性是所有四个纬度中最需要重点关注的。

2.3 软件项目风险的种类

(1) .按风险内容分类

对软件项目的管理部门来说, 在做出与规定费用按规定时间交付规定产品或达到规定性能水平的决断时, 风险是永远存在的。软件项目管理部门因风险而导致工作失败有三种方式:产品达不到规定的性能水平、实际费用过高、交付过迟等。就项目而言, 其面临的风险可分为五个方面:技术、管理能水平、实际费用过高、交付过迟等。就一个项目而言, 其面临的风险可分为五个方面:技术、管理、社会环境、费用和进度。

(2) .按风险性质分类

已知风险, 是通过仔细评估项目计划、开发项目的商业及技术环境以及其它可靠的信息来源之后可以发现的那些风险;可预测风险, 能够从过去项目的经验中推测出来;不可预测风险, 它们可能、也会真的出现, 但很难事先识别出它们来。

3、软件项目风险管理的过程

软件项目风险管理实际上就是贯穿在软件项目开发过程中的一系列管理步骤, 其中包括风险识别、风险分析、风险监控和风险应对。

3.1 风险识别

风险识别就是企图采用系统化的方法, 识别某特定项目已知的和可预测的风险。

风险识别主要方法有:

头脑风暴法

头脑风暴法是团队通过本能地、不加判断地汇集一些想法, 产生新的主意, 从而找出解决某一特定问题的方案。建立一份综合风险清单的时候可能用到这一方法。

Delphi方法

Delphi方法是从一组专家中得到一致的意见, 来预测未来的发展。它是一种以互相独立的输入为基础, 对未来事件进行预测的系统化、交互式程序。Delphi方法重复使用几个回合的提问, 包括来自前几轮的反馈, 从而发挥团组输入的优点, 同时又可以避免面对面商议中可能出现的偏见效应。

访谈

访谈是通过面对面或电话讨论的方式, 收集信息、寻求事实的一种技术, 访谈也可以通过电子邮件和即时信息进行。与那些具有类似项目经历的人们进行面谈, 是识别可能风险的重要工具。

检查表

当检查表用来进行风险识别时, 将项目可能发生的许多潜在风险列于一个表上, 供识别人员进行检查核对, 用来判别某项目是否存在表中所列或类似的风险。检查表中所列的内容都是历史上类似项目曾发生过的风险, 是项目风险管理的结晶, 对软件项目有开阔思路、启发联想、抛砖引玉的作用。此外, 也可以通过使用Standish Group, SEI或其他组织开发的检查表, 来帮助识别项目的风险。

流程图

流程图是一种风险识别的常用工具。借助于流程图可以帮助项目风险识别人员去分析和了解项目风险所处的具体项目环节、项目各个环节之间存在的风险以及项目风险的起因和影响。

3.2 风险分析

风险分析是在风险识别的基础上对项目管理过程中可能出现的任何事件所带来的后果的分析, 以确定该事件发生的概率以及与可能影响项目的潜在的相关后果。风险分析的出发点是揭示所观察到的风险的原因、影响和程度并提出和考察备选方案。

风险分析的方法有:

概率/影响图

概率/影响图 (图1) 是风险定性分析的方法。概率表示风险发生的可能性大小, 而结果表示风险发生后所带来影响的程度, 使用风险暴露值=发生概率*结果影响来评价风险。

专家判断法

专家判断法是依赖专家们的直觉和以往的经验来代替或补充数学分析技术, 专家可以使用或不使用较为复杂的技术, 例如, 无须计算风险暴露值, 直接把风险定为高、中和低三种。

决策树

决策树是一种图形化的风险量化分析方法, 可以帮助在未来结果不确定的情况下, 选择最好的行动路径。

模拟

模拟是指用系统的模型或表示法来分析系统的预期行为或绩效, 也是一种量化分析方法。大多数模拟都以某种形式的蒙特卡罗 (Monte Carlo) 分析为基础。蒙特卡罗分析通过多次模拟一个模型的结果, 从而提供计算结果的统计分布。

蒙特卡罗法

假定函数Y=f (X1, X2, …, Xn) , 其中变量X1, X2, …, Xn概率分布为已知。但在实际问题中, f (X1, X2, …, Xn) 往往是未知的, 或者是一个非常复杂的函数方程式, 一般难以用解析法求解有关Y的概率分布及其数字特征。蒙特卡罗法利用一个随机数发生器, 通过直接或间接的方式抽样取出每一组随机变量 (X1, X2, …, Xn) 的值 (X1t, X2t, …, Xnt) , 然后按Y对于 (X1, X2, …, Xn) 的关系式确定函数Y的值Yt, Yt, =f (X1t, X2t, …, Xnt) , 反复独立抽样 (模拟) 多次, 便可以得到函数Y的一批抽样数据Y1, Y2, …, Yn, 当模拟次数足够多时, 便可以给出与实际情况相近的函数Y的概率分布及其数字特征。

3.3 风险监控

监视风险似乎被视为被动的活动, 但事实并非如此。风险跟踪活动包括衡量风险和观察项目中有用信息的指标, 表明何时应该执行风险行动计划。指标指代一个没有直接说明数量的值。成组的指标可使项目状态清楚可见。先行指标是有预见能力的指标。指标可告诉何时可采取行动避免风险。有效的风险控制离不开在恰当的时候采取行动。

风险跟踪过程目标: (1) 监视风险设想的事件和情况; (2) 跟踪提前示警的风险指标; (3) 为触发机制提供通知; (4) 获得风险应对努力的结果; (5) 定期报告风险度量和度量规格; (6) 使风险状态可见。

3.4 风险应对

针对风险评估的结果, 制定相应的应对措施去响应风险, 就是风险应对, 其目的是创造机会, 回避威胁。风险应对中, 需要对风险的正面效应 (即潜在的机会) 制定增强措施, 对风险的负面效应 (即可能的威胁) 制定应付方法。对于不同的风险, 需要根据其重要性、影响大小以及已经确定的处理优先次序, 采取相应的措施加以控制, 对负面风险的反应可以是尽量避免、努力减小或设法接收。

另外, 在处理风险时需要注意应对的“及时性”和“反复性”, 即在第一时间对各种突发的风险作出判断并采取措施;对已经发生或已经得到控制的风险经常进行回顾, 确保风险能够得到稳定长期的控制。

项目风险应对的措施主要有:

(1) 修正项目目标或范围。尽管有深入的项目调研和详尽的项目规划, 但软件开发项目过程中的需求改变常常难以避免, 因此为保证项目的实施效果, 对项目的目标或范围加以必要修正, 能够有效应对项目偏离需求的风险。

(2) 加强培训。加强项目培训能够提高参与项目的IT人员和业务人员甚至管理人员、决策者对信息化项目的认知, 对规避项目的实施风险有良好的效果。

(3) 准备风险保证金, 适当预留项目计划时间。在项目预算中预留一定数量的风险保证金, 时间计划中预留一定的时间, 能够有效应对由于项目需求改变或者范围增加而造成的时间和成本风险。

(4) 始终贯彻项目管理的标准流程。严格执行项目管理中的时间、成本、质量控制等标准流程, 能够有助于控制项目风险。

(5) 加长模拟阶段的周期。软件项目经常需要开发相应系统与企业业务流程相结合, 因此加长系统模拟业务流程的周期, 使之充分适应企业业务流程, 能够保证项目对企业的适应性, 从而降低项目的风险。

(6) 终止项目。这是一种极端的做法, 往往由于项目目标没有明确所致, 采用这种做法虽然会导致项目的彻底失败, 但也是万不得已, 能够避免企业更大的损失。

4、结束语

软件项目管理从某种意义上讲, 就是风险管理。风险管理在国内软件行业的应用, 远未达到预期应该达到的水平。人们往往看不到风险管理的重要性, 这种错误的认识有时会让我们付出很大的代价。软件企业应该对企业员工进行系统的软件风险管理培训, 提高对软件风险管理的重视。同时, 企业应充分运用已有的各种风险管理理论, 创造性地找出一套适合自己企业的风险管理方法进行软件项目风险管理, 并且将该方法贯穿软件项目开发的整个过程, 减小软件项目失败的可能性, 以确保软件项目在规定的预算和期限内完成项目。

摘要：软件项目开发过程中存在着大量不确定事件, 这给项目的成功带来了风险。软件风险管理是对影响软件项目、过程或产品的风险进行估计和控制的实践过程, 也是为了解决影响软件项目、过程或产品的风险而制定的准则。本文叙述了软件开发项目风险的定义、影响纬度和种类, 重点分析了软件项目风险管理的过程。

关键词：风险,风险管理,风险识别,风险分析,风险监控,风险应对

参考文献

[1][美]Schwalbe, K.著, 邓世忠等译.IT项目管理.机械工业出版社.2004年

[2][英]Hughes, B.著, 周伯生等译.软件项目管理.机械工业出版社.2004年

[3]卢有杰, 卢家仪.项目风险管理.清华大学出版社.1998年

[4][美]Glass, R.L.著, 陈河南等译.软件开发的滑铁卢——重大失控项目的经验与教训.电子工业出版社.2002年

[5]邱箢华主编.现代项目风险管理方法与实践.科学出版社.2003年