软件项目风险分析与研究

索红军

摘 要：从软件设计开发组织、软件项目委托投资组织以及软件最后真正的使用组织三者的关系入手，分别针对这三者是否为同一组织及各组织对软件的不同观点、不同责任、不同收益等方面，提出不同软件项目由于三者关系不同而存在的不同风险。同时结合一般工程项目的风险量化方法，修正得到针对软件项目的风险量化方法，并就软件项目中的风险提出保留风险、降低风险、转移风险和避免风险等控制对策。

关键词：软件项目；风险分析；信息安全

DOIDOI：10.11907/rjdk.171409

中图分类号：TP319

文献标识码：A 文章编号文章编号：1672-7800（2017）008-0128-04

0 引言

任何团体、组织或个人在实現其目标的活动中，都会遇到各种不确定性事件，这些事件发生的概率及其影响程度是无法事先预知的，将对实现目标的活动产生一定的负面影响，从而影响目标实现的程度。这种在一定环境下和一定限期内客观存在的、负面影响目标实现的各种不确定性事件就是风险[1]。简言之，风险是指在一个特定的时间内和一定的环境条件下，人们所期望的目标与实际结果之间的差异程度。

在软件项目中，从立项开始到项目完成，每一个环节都存在影响项目完成的不确定负面因素，这些负面因素就是软件项目中的风险，其可能引起软件项目开发成本增加、软件项目开发周期加长、软件项目质量降低、软件项目完成后收益降低等，极端情况下会导致整个软件项目的报废，甚至为此付出额外的代价。因此，在软件项目整个阶段，都必须进行与风险有关的活动，包括风险识别、风险分析、风险应对、风险控制等。

目前，软件项目管理领域的许多文献都提到了有关风险识别、风险分析、风险控制等，这些都是针对软件项目整个阶段中可能出现的风险而言的，包括软件可行性分析阶段、软件需求获取与分析阶段、软件设计阶段、软件运行与维护阶段的风险等，涉及技术、管理、社会政策及地域环境等多方面。少有文献从软件开发者与软件开发投资委托方及软件最终使用者的关系方面探讨软件项目的风险。

1 风险识别

风险识别是指找出影响项目目标顺利实现的主要风险因素，并识别出这些风险究竟有哪些基本特征、可能会影响到项目的哪些方面。项目风险识别是一项贯穿于项目实施全过程的项目风险管理工作。它不是一次性行为，而是有规律地贯穿于整个项目中。严格来讲，风险仅仅指遭受创伤和损失的可能性，但对于项目而言，风险识别还牵涉机会选择（积极成本）和不利因素威胁（消极结果）。

项目风险识别的第一个目标是确定可能会遇到哪些风险，只有确定了风险才能够进一步分析这些风险的性质和后果。项目风险识别的第二个目标是识别风险的主要来源，只有识别了风险来源，才容易把握项目风险发展变化规律，也才能够度量项目风险的可能性与后果的大小，从而对项目风险进行控制。相关资料表明，风险识别首先要分析出软件项目中的风险因素，然后将风险分类，确定风险识别的输入，利用头脑风暴会议、德尔菲法、情景分析法、风险率、检查表等识别出风险[2]。本文将软件开发方和投资委托方以及软件应用方三者结合起来，也即将软件研发组织、软件投资委托组织以及最终软件使用组织三者结合，以它们之间的关系来识别和分析软件项目中可能存在的风险。

1.1 软件开发方、投资委托方和应用方为同一组织或个人

对于软件开发方、投资委托方和软件应用方为同一组织或个人的软件（即自己开发软件给自己用），其风险主要表现为由于软件文档资料缺失、算法缺陷等导致的软件升级困难。具体而言，此类软件一般存在以下风险：

（1）算法有误导致结果错误。笔者在第一次执行海南铱星任务时，所使用的软件没有判断出火箭的关机点，导致结果错误，经事后分析，原因是上级给定的算法存在缺陷。同类型的风险还有别人提供的信息错误、各种条件存在矛盾等，此类风险一般事前较难预测到，具有很强的潜伏性。

（2）软件开发人员变动导致软件维护升级困难。这类自己开发给自己使用的软件，会存在很多不规范现象，若发生人员流动，将加大软件后期维护和升级难度。一般情况下，软件设计开发人员都不愿编制整理软件开发和使用相关文档资料，存在无任何资料或资料不全、不够详细，软件的算法、代码可能存在瑕疵等问题，只有原开发人员清楚如何避免瑕疵，原开发人员应用该软件没有问题，而别人使用该软件时可能存在一些问题。当原开发人员离开后，他人对软件修改升级时困难重重，其经济成本、时间成本大大增加。这就是此类软件存在的一个风险。同类型的风险还可能是软件文档资料丢失、部分人员技术信息封锁隐藏、人力资源调度不合理等。

1.2 软件投资委托方为应用方中的极少部分组织或个人

将这类软件归结为设计开发方为一个组织，投资委托和软件的使用方为同一组织，但投资委托方只是软件使用群体中的极少一部分。应用这类软件的用户量一般特别大。进行软件开发时，没有途径或不合适或因控制成本需要等原因，在需求获取时没有征求到大量用户的需求，最终可能在软件需求方面不能尽如人意，存在很大的风险。比如，各大学的教务管理软件，全校教师学生都是该软件的用户，然而当设计开发该软件，给开发公司提供专属需求[3]时，只能是学校的极少数人员，而且这些人员可能都是管理部门的，对用户（一线教师和学生）的真正需求理解不可能完全正确，甚至出现偏差。当软件投入使用后，经常会出现大多数人对软件需求（功能、性能、约束等）不满意的情况。这类风险在软件需求获取与分析时就产生了，严重程度比较高。同类型的风险也可能存在于管理的专政、沟通的缺失、成本的不合理压缩等情况。

1.3 软件开发方、投资委托方为同一组织或个人

这类软件的设计开发人员和投资委托人员为同一组织或个人，但用户是另外的组织或人员，即一些组织或个人自己开发设计软件，完成后的软件交由他人使用。比如，一些软件公司自己调研设计开发软件后，将软件以商业的形式发布出去，供其他人员使用。这类软件在开发之前并不清楚用户的具体需求，因此存在的风险主要体现在没法真正掌握用户对软件的期望、软件的性价比等。比如，现在很多软件类公司开发的手机APP软件，开发完成后推向市场，能否得到用户的青睐，在开发初期是预测，只有开发完成投放市场后，才能真正清楚软件到底怎么样。若这时发现软件不被市场所钟爱，没有用户数量，已经晚了，前期的投资可能得不到应有的回报。因此，对于这样的商业类软件，能否真正产生商业价值，存在很大的风险，而这个风险，最终体现在软件设计开发投资委托方对未知用户的需求期望预测和开发成本之间的关系，可能会涉及竞争对手、社会环境、政治政策、人力资源等多种因素。endprint

1.4 软件开发方、投资委托方和应用方均为不同组织或个人

软件的开发方、投资委托方和应用方均为不同组织或个人，这类软件目前比较多，从各方是否能够提前预知等方面，又可以将其划分为下列几类：

（1）某些机构以商业目的委托软件公司开发软件。某些组织机构自身不做软件研发，但有可能从商业角度考虑涉足软件研发。这类软件有开发方、投资方和用户3方面，其实际上是将上文讨论情况下的开发方和委托方分解成两个不同的组织，原来的风险也相应分解到两个组织，但毕竟又不同于上文讨论的情况，最终风险可能更多地集中在投资委托方。这类软件的投资委托方并不真正涉足软件的具体设计开发过程，只是一个中间投资方，既要获取到市场用户的真正需求，又要与开发方准确地沟通，对于投资和收益都可能存在与实际的偏差，最终导致投资委托方成为风险的主要承担者，而且有可能风险比上文讨论的情况更为严重，因为这种情况下软件开发方风险较小，因而其工作态度、责任心等不一定会达到上文讨论的情况。

（2）某些组织机构下派的软件。在现实中，存在一些上级向下级分派软件的情况，特别是一些政府机关及事业单位之间，或者企业的管理部门向企业分派下发软件等。这类软件开发方、投资委托方及用户不是同一组织或个人，软件的真正用户一般是被动地使用软件。对于这类软件，由于开发方与真正的用户几乎没有联系，对软件的需求是依据投资委托方提供的，其结果是用户会对软件不满，在软件的售后维护经费方面可能存在很大差异。风险主要表现在软件需求与用户需要的差异、用户对软件的接受程度等。

（3）软件服务外包。由于技术、工具、人力资源等差异，软件开发方经常会将部分软件外包出去以节省成本、提高进度等。另外，有些非软件开发为主的组织，其硬件产品中需要的软件，也经常需要外包出去。对于外包的软件，风险主要表现在外包部分与自主完成部分（包含硬件）的配合衔接程度及外包部分的功能、性能等。一般情况下，外包的这部分软件不是主体，经常得不到足够的重视，当产品交付用户后再发现外包部分软件有问题时，将会产生各种问题，比如纠纷、修改成本等。同时，由于对外包软件内部不熟悉，当对软件作很小修改时也可能花费很大的成本。

2 风险分析与估算

将风险识别出来后，必须分析估算风险发生的概率以及风险一旦发生所带来的损失等，因此需考虑如何应对风险。风险分析是指在风险识别的基础上，分析风险事件一旦发生所造成的损失及风险事件发生的概率，真正的损失是这两项的乘积[4]。风险分析主要是在项目现有信息的基础上，分析这两个方面，尽可能准确地将这两个方面量化出来，以得到风险的具体量化值R。任何项目其风险量化值R都可用式（1）表示。

R=f（p，c）（1）

式（1）中，p表示风险发生的概率，c表示一旦该风险事件发生将造成的损失，R表示最终的风险值。将所有风险的值R确定后，就可对各风险进行优先级排序和监控处理。

对于软件项目，由于软件的研发组织、软件的投资委托组织以及最终软件的使用组织三者之间的关系不同，式（1）有必要作适当修正。

R=f（p，c）+k*x（2）

式（2）中，前部分含义和式（1）中相同，后边增加了两项。x表示软件研发组织、软件投资委托组织以及最终软件使用组织三者之间的关系不同时的参数，k为系数。

根据经验及理论计算，结合各方面对软件需求、市场、技术、环境等的熟悉程度，x的取值可参考如下：①5～10：三方为同一组织或个人；②8～15：软件委托方为应用方中的极少部分组织或个人；③8～20：软件开发方、委托方为同一组织或个人；④3～25：软件开发方、委托方和应用方均为不同组织或个人。

一个取值范围内具体应该取何值，应根据以往经验、参考同类型项目、头脑风暴等确定。至于系数k的值，结合软件的规模、开发人员的技术力量等，一般可取1～3。

3 风险控制与对策

当对风险具体量化后，就可以根据R的值进行排序，根据风险的重要程度进行适当的控制，制定相应的对策。在软件项目中，风险控制与对策主要从风险应对和风险监控两方面考虑。

风险识别和风险分析的目的是让决策者能够在问题发生之前深思熟虑，准备好最佳应对措施。一般而言，项目的风险应该由参与项目的所有各方共同承担。避免风险的最好方法是放弃项目，一定要判断是否值得承担这么多风险来取得项目收益。人们常说，风险越大收益就越大，到底项目是放弃还是继续，可能要根据项目决策者的性格、能力、外部环境等多种因素确定。另外在风险承担上，让最有能力控制风险的一方负责承担风险是最明智的分配，当然也应该尽量把风险分配给那些受风险影响最小的项目参与者。

对于已经确认的风险，通常可以采取以下措施：保留风险、降低风险、转移风险和避免风险。软件项目中的某些风险是无论如何也不可避免的，要实施项目就得保留风险，或者说采取其它风险应对方案的成本超过风险发生所造成的损失，这时就可以保留风险。保留风险是指这类风险一旦发生，项目团队或相关组织必须承担风险产生的后果，接受风险。降低风险是指把不利风险事件的概率或后果降低到一个可以接受的水平，实际上也是在风险发生之前通过一些技术措施、管理措施或者经济措施等降低风险发生的可能性或者减少风险可能造成的损失。转移风险是指为了避免承担风险造成的损失而有意识地将风险导致的损失或有关结果转嫁出去的方法。避免风险是指对可能发生的风险尽可能地回避，采取主动放弃或者拒绝使用导致风险的方案等，例如新技术有可能产生风险，放弃采用新技术就可以避免风险。但避免风险有可能产生其它风险，而且避免风险也可能导致机遇的丢失等情况出现。

4 风险评价与管理

在项目的全生命周期内对项目风险进行连续辨识和分析，可以为有效地控制风险提供依据。风险评价通常也分为两个步骤：一是风险辨识；二是風险分析。项目前评价和项目中评价都包含有风险评价。在项目前评价中，风险评价是指项目执行以前，对项目环境风险的预测和评价，包括政治风险、经济风险、自然风险、技术风险等，是项目可行性研究的一个组成部分。本文主要探讨项目中评价阶段的风险评价问题，因为在项目实施过程中，项目管理者需要随时掌握当前项目所面临的风险状况，指出项目进行不正常的风险信号，必要时预先采取纠正措施。endprint

项目风险管理是为了更好地达到项目的目标，识别、分配、应对项目生命周期内风险的科学与艺术，是一种综合性的管理活动。由美国项目管理协会（PMI）开发的项目管理知识体系PMBOK2000指出，项目风险管理的内容包括项目风险管理计划、风险识别、定性风险分析、定量风险分析、风险应对计划和风险监督与控制[5]。项目风险管理是一个动态的工作过程，在此过程中，项目风险的各项作业是相互交叉和重叠开展的。项目风险识别是项目风险管理的重要环节，若不能准确识别项目面临的所有潜在风险，就会失去处理这些风险的最佳时机。

项目风险管理是在项目进行的全过程中，对于影响项目的进程、效率、效益、目标等一系列不确定因素的管理，包括对外部环境因素与内部因素的管理，也包括对主观因素与客观因素、理性因素与感性因素的管理。

5 结语

软件的设计与开发是一个非常复杂的过程，一个软件从立项开始到项目完成，其中包含了大量不确定因素。这些不确定因素对软件项目成本预算、工期预测、收益率、软件质量等影响非常大，而且这些因素的影响大部分是负面的，形成软件项目风险。为了高效地完成软件项目，必须提前对软件项目中的风险进行预测分析，预测分析项目在实施过程中可能会有哪些风险，每一个风险一旦发生导致的损失以及每一个风险发生的概率。最后根据风险的损失和概率等因素，决定风险优先级、风险应对措施等。同时，为了总结经验，为后续软件项目降低成本，提高收益，对软件项目的风险也应该进行必要的评价和管理。本文从多方面对软件项目的风险进行了分析研究，但也只是笼统分析，并没有针对某一个具体的软件项目进行分析。不同的软件项目，其包含的风险不尽相同，针对某一个具体软件项目的风险分析与研究，有待在后续具体的工程实践过程中进一步深入。

参考文献：

[1] 閆彦，刘军，于淑娟.企业管理[M].北京：清华大学出版社，2010：41-45.

[2] 朱少民，韩莹.软件项目管理[M].北京：人民邮电出版社，2013：174-179.

[3] 齐治昌，谭庆平，宁洪.软件工程[M].北京：高等教育出版社，2013：68-69.

[4] 刘凤华，任秀枝.软件项目管理[M].北京：中国铁道出版社，2014：180-184.

[5] [美]项目管理协会.项目管理知识体系指南[M].第5版.卢有杰，王勇，译.北京：电子工业出版社，2009：309-318.endprint