软件开发的技术风险及规避方案（软件项目开发的风险和措施）
本篇文章给大家谈谈软件开发的技术风险及规避方案，以及软件项目开发的风险和措施对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
软件开发过程中会有哪些风险？
1、未经权威部门确认的功能标准、开发规范以及质量技术标准，均可能导致软件无法达到预期标准，从而引起质量风险。
2、在理解项目标准及范围等问题上，企业管理层、项目组以及技术性人员的接不一致，导致计划与资金安排有所改变，因而极易引发风险。
3、潜在的维护、验证、接口、实现以及设计等环节出现的问题，存在技术空白及未知领域，为软件开发工作带来较大的风险。
4、来自于外包项目组、客户、国家政策以及市场等方面的变化及压力，这类风险具有明显的不可控特点，一旦遭遇，应谨慎对待，及时制定解决策略。
风险防范与控制措施
1、出台合理的软件开发模式与相关规程，确保开发工作合理、有序进行，并符合国家出台的相关标准及要求。
2、对于项目组全体成员的开发行为进行严格规范，加强小组成员之间的交流与互动，以免由于沟通与交流不当，引发软件开发风险。
3、定期开展业务和技术交流大会，引导技术人员摒除过于落后、陈旧的工作思想，通过引进先进的技术、设备与验证方式，明确技术人员的预期发展目标，令其不断的改进自我、完善自我，提升技术及设备的质量及效果。
4、对开发所用的方法及技术进行客观、合理的评价，避免由于无法把握技术而引发风险。
5、建立完善的风险应对程序与管理计划，如此一来，才能确保在发生风险的时候，能够快速、合理、技术的作出反映，并通过制定适宜的策略，对风险进行专业性处理。
软件开发管理如何风险管理
风险管理的达成必须包括三个要素：
首先，在项目开发计划中必须制定风险管理计划；
第二，在项目预算中必须包含解决风险所需的经费；
第三，评估风险时，风险的影响也必须纳入项目计划中。
下面就软件开发过程中经常发生的风险，谈谈我们采取的预防措施。
1、需求不明确
需求不明确是软件开发过程中经常可能遇到的问题，这类问题往往表现在需求范围未界定、需求未细化、需求描述不清楚、需求遗漏、需求互相矛盾等多个方面。在软件开发过程的生命周期各阶段中，需求不明确所造成的浪费是最大的，必须尽早尽可能解决。确定用户需求是件非常困难的事情，我们常常从以下几个方面着手处理需求不明确问题：
（1） 让用户参与开发
提供一个协作开发环境，让用户参与开发过程。如果条件不允许，至少应该在每次迭代的需求分析和系统测试阶段，让客户能够参与开发。
在选择参与开发过程的用户时，一方面，要尽可能争取精通业务或计算机技术的用户参与。另一方面，如果开发的产品要在不同规模、不同类型的企业应用，应该选择具有代表性的用户参与。
仅仅让用户参与是不够的，应该采取一定的激励措施，提高用户参与的积极性。
（2） 开发用户界面原型
用户通常不善于精确描述自己的业务需求，系统分析员需要借助白板、白纸等沟通方式，帮助用户清楚表述需求。然后，开发一个用户界面原型，以便用户确认需求。用户界面原型的作用仅仅是收集用户需求，不应该再作它用，也不要给用户造成系统快要实现的错觉。
（3） 需求讨论会议
对于用户分布广、用户量大的项目，要全面收集用户需求，往往很困难，通常采取需求研计会议方式进行需求确认。通过在会议前几周调查各地、各部门用户需求意见，然后集中各地或各部门的用户代表，举办一次需求研讨会，通过会议方式收集需求。本方法适合于具有一定信息系统使用经验的用户。
（4） 强化需求分析与评审
首先，需求分析是项目成功的基础，需要引起足够的重视，并分配充足的时间和人力，要让有经验的系统分析员负责，切忌让项目新手或程序员负责。其次，要进行需求评审，尽可能让用户参与需求评审，不要让需求评审流于行式。第三，也是最重要的一点，通过评审的需求规格说明书，要让用户方签字，并作为项目合同的附件，对双方都具有约束力。在公司内部要将通过评审的需求规格说明书，纳入配置管理。
2、项目缺少可见性
当一个项目经理或一名开发者说已经完成了80%的任务，您必须保持审慎的态度。因为剩下的20%可能还需要80%的时间，甚至永远都不能完成[1]。软件开发项目，往往在项目进度和软件质量方面缺少可见性，项目越缺少可见性，项目就越难以控制，项目就越有可能失败。我们可以通过迭代开发、技术评审、持续集成来增强项目的可见性。
（1） 迭代开发
采用迭代的开发模型，将产品的交付过程分为多个阶段，按照功能递增式交付。以下是一些典型的迭代：
一次简短的先期迭代，以建立规模和前景并确定商业理由；
一次精化迭代，其间将为稳定的构架划定基线；
一次构建迭代，其间将实现用例并充实构架；
几次产品化迭代，将产品转移到用户群。
每次迭代，都要充分接收用户的评审意见，以便为自我纠正。渐近式的功能交付，有利于降低开发人员的压力，增加用户的满意度，有利于增强项目的可见性，是最好的进展报告。
（2） 技术评审
技术评审是确保软件质量的重要环节，技术评审包括代码走查、会议评审和同行专家评审。代码走审可以是开发人员之间的交叉审查，或者是高级开发人员对普通开发人员的审查；会议评审一般应至少每两周进行一次，每次评审时间不宜太长；同行专家评审包括技术和业务两个方面的专家，经常性地让精通业务的用户专家参与项目评审，是项目成功的重要保证。
另外，充分利用质量审查的工具软件，也有利于提高代码质量。例如：在Eclipse开发环境中，可以集成Findbug、Checkstyle、PMD插件检查代码编写质量。
（3） 持续集成
持续集成能够把最终的一次大规模的集成调试过程分散到项目开发时间表的每一周、每一天、甚至每个小时。让项目中的各个人员都能够随时掌握当前的整体进度，并迅速发现集成过程中出现的问题并进行解决[1]。
开发小组应制定持续集成的制度，一般情况下每日构建一次，可以利用Ant等构建工具进行Java应用程序的构建。小组成员应在每个功能开发完成后，及时向版本控制系统（如CVS）提交代码，而且不应该向版本控制系统提交有问题（编译通不过）的代码。
每日构建、持续集成，让项目进度跟踪工作更加容易。当项目小组每天重新编译系统时，已完成与未完成的功能清楚可见，小组成员能够简单地从软件的表现知道距离整体完成还有多远。
3、新技术引入
技术创新是一种具有探索性、创造性的技术经济活动。在开发过程中引入新技术，不可避免地要遇到各种风险。通过T形软件开发、充分论证、多阶段评审、同行经验等措施可降低新技术风险。
（1） T形软件开发
在项目开发早期，开发小组应该建立系统的架构，解决关键技术难题、开发系统的基础构件，并对系统所需要应用的技术做深度探索。例如：基于JavaEE5构建全国联网售票系统，涉及到分布式事务处理、海量数据存储、异构平台互连等关键问题，应该优先处理这些问题；对开发所涉及到的EJB3、JSF、 JBoss Seam、Eclipse RCP等技术，要做深度探索。
越是技术复杂度高的项目，就越应该早地处理技术难题。如果在项目开发的中期或后期才发现架构有问题或是关键技术难题不能解决，则为时已晚。
（2） 充分论证
新技术开发是探索性很强的工作，潜在着许多失败的风险。在可行性分析阶段，要广泛搜集相关信息，设计多种可行方案，进行充分论证。在制定决策时，情报的数量和质量致关重要。掌握的信息越多、越准确，才能作出正确的的决策，项目失败的风险也就相对减少；反之，承担的风险就会增大。
（3） 同行经验
针对新技术，由于没有经验可借鉴，因此在探索过程中要充分利用互联网，通过搜索同行经验，往往事半功倍。要充分利用世界日益平坦化的优势，对于不能尽快解决的问题，可以先放一放，可能过不了几天，网上就有相类似问题的解决方案了。
4、技术兼容性风险
硬件产品之间、系统软件（操作系统、中间件、数据库管理系统）与主机设备之间、系统软件之间、应用软件与系统软件之间以及应用软件之间，都可能存在兼容性问题。往往系统集成的项目越复杂，兼容性问题就越有可能存在。
（1） 设计先行
在做系统的总体设计方案时，务必把好相关产品的选型关，确保网络、主机、系统软件与应用软件之间不要存在较大的技术兼容性问题。在网络平台建设方案中，明确相关设备的技术参数和配置要求。
（2） 售前产品测试
在做项目招投标工作时，要求投标方在售前提供产品兼容性测试，以避免在项目实施过程中才暴露技术兼容性问题。涉及应用软件开发的集成项目，要在开发工作的早期，做技术兼容性测试，以避免在项目开发后期才暴露技术兼容性问题。
例如，我们在开发深圳市汽车客运站售票及站务联网调度系统时，为了确保技术兼容，在做硬件招标时要求小型机设备厂商提供售前技术兼容性测试工作，并将测试结果做为评标指标。在深圳市软件测试中心对IBM、SUN、HP三家公司提供的小型机进行测试时，暴露了许多应用软件、应用服务器、数据库和操作系统之间的技术兼容性问题，如果这些问题在系统实施时才暴露或处理，势必会拖延项目进度。
5、性能问题
由于先期设计不足，性能问题往往在系统切换或新系统使用一段时间后暴露。出现性能问题往往要进行大量的优化工作，甚至局部的或全面的重新设计。无论是用户还是开发者，谁都不希望出现性能问题。
（1） 性能规划
在系统设计时，应做好前期做性能规划，对可能出现性能问题的环节做到充足的估计。在做数据库设计时，应争取DBA参与。
另外，在技术方法方面，尽可能采取一些性能优化模式，如DTO、AJAX、延迟加载等，尽可能在开发过程中解决了性能问题。不至于到了项目后期才解决性能问题，既费钱又费时。
（2） 性能测试
在开发过程中，要重视性能测试和压力测试，尽可能模拟现实使用环境，搭建测试平台。另外，由于开发环境的计算机往往比生产环境的计算机配置高，在做测试时应尽量找一些配置低的机器、较小的网络带宽进行测试。
（3） 充足的调试时间
在项目开发计划中，为后期性能优化留有余地。在对系统进行性能优化后，要进行性能测试和压力测试，可能还要做几次回归测试。因此，应该留有充足的时间和人力。
6、仓促上线
在项目实施过程中，系统切换上线环节最容易出纰漏。项目好不容易开发完成了，却在最后最后时刻功溃一匮。如果项目小，影响面窄倒不怎么重要；如果是影响面大的项目，则千万不可出现问题。在系统切换前，应充分考虑各种可能出现的问题，做好风险对策。
（1） 应急预案
面对各种不可预知的风险，要做好应急预案。正常运行的车站售票系统在春运、旅游黄金周，都会做好应急预案。新系统切换时，更应该做好应急预案。应急预案中应做好最坏的打算，售票系统不能正常工作时，准备手工票就是最坏的打算。
（2） 分步切换
为了减少风险的影响，可以做系统分步切换的方案。例如：售票系统在切换时，往往用新系统售预售票，或者是用新系统售长途车站，用旧系统暂时售短程票。待新系统运行稳定后，再全面切换到新系统。针对多个用户单位的系统切换，也可分单位进行。
（3） 交叉培训
新旧系统切换过程中，用户都存在适应过程。除了在切换前做好操作培训外，还要在新旧系统切换过程中做好交叉培训。让用户提前一些时间上班，让早班的用户在交班时培训中班的用户，中班的用户培训晚班的用户。做好交叉培训能够让系统平衡过渡。
7、可用性问题
软件的可用性包括软件的使用是不是高效、是否容易学习、是否容易记忆、是否令人愉快、是否不易出错等诸多因素。往往由于软件的可用性差，导致用户不满意，甚至被市场淘汰。在项目开发中应注意可用性问题，避免软件出现可用性方面的风险。
（1） 了解用户
到用户工作现场，了解目标用户使用软件的真实目的，从用户的角度、从用户的立场出发，了解如何通过软件系统替代用户的业务处理流程中，最繁琐、最容易出问题、或者是大量重复劳动的环节，让软件提高用户的工作效能和效率。例如：售票系统中，使用频度最高的界面是售票界面，售票员最关心的是钱不要出错（多了没收、少了要赔），因此，应收款和找余字体的显示应该突出、醒目；同样，票价和到达站也应该较为突出显示。通过快捷键、一键复位、数字小键盘等设计，尽量减少售票员敲击键盘的次数。否则，在日发旅客流量达七、八万人次的大型客运站，如果用户界面设计得不好，售票员一天工作下来，手指都会敲麻木。
（2） 参与型设计
与用户协作，让用户参与用户界面的设计、评审与测试，确保用户能够全面地、及早地发现可用性等方面的问题，并及时纠正。
让客户参与设计，而不要让客户设计，项目经理或高级设计人员应该主导设计。
（3） 竞争性分析
通过对市场上同类竞争性产品进行分析，或者对这些产品进行实验性测试，了解这些产品的用户界面问题，从而对新系统的开发提供启发。竞争性分析并不意味着可以剽窃别人的设计，而是通过分析竞争产品的优势和弱点，能够比以前的设计做得更好[5]。
（4） 一致性
如果用户知道同样的命令或同样的操作总会产生同样的效果，那么他们在使用系统时就会更加自信，同时也鼓励他们进行探索性学习，因为他们已经具备了使用系统新部分的基础知识[Lewis er al。1989]。
开发团队应遵循公司或小组制定的用户界面标准，就可以在很多方面保持一致性，切忌不要一个系统存在多种不同的界面风格。
郑州观致电子商务,拥有有效资源, 多起成功案例, 专业制作水平, 提供微期货平台搭建、分销系统开发、捕鱼游戏开发、第三方支付软件开发、商城网站建设、电商网站建设、网站定制开发、手机app软件开发、微信小程序开发、电商系统开发、办公系统软件开发一系列服务。精英团队为您以后保驾护航!
8、结论
在信息系统集成项目中，风险是多种多样的，是无处不在的。在项目管理活动中，要积极面对风险，要培养。越早识别风险、越早管理风险，就越有可能规避风险，或者在风险发生时能够降低风险带来的影响。特别是在项目参与方多、涉及面广、影响面大、技术含量高的复杂项目，应加强风险管理。如果不主动驾驭风险，就会面临风险。
如何对软件项目开发过程中的风险进行风险控制？
识别和分析风险并不是软件风险管理的最终目标。针对所发现的每一个软件风险，尤其是高危险度的软件风险，风险管理还需要对它们进行有效的控制，包括：（1） 制定风险管理计划：针对各个重要风险制定风险管理计划，并确保它们的一致性；（2）化解风险：执行风险管理计划，以缓解或消除风险；（3）监控风险：监控风险化解的过程。 n�0�2�0�2�0�2�0�2�0�2�0�2 制定风险管理计划 针对每一个重要的软件风险，制定相应的处理该软件风险的计划。风险管理计划主要描述有关软件风险处理的以下内容-�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2 软件风险名称 -�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2 软件风险由谁引起 -�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2 软件风险发生后的处理措施 n�0�2�0�2�0�2�0�2�0�2�0�2 风险化解方式 执行风险管理计划，以缓解或消除风险。一般地，软件风险化解有以下几种方式。 -�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2 避免风险 采取主动和积极的措施来规避软件风险，将软件风险发生的概率控制为零。例如针对用户可能没有时间参加需求评审这一软件风险，项目组可以考虑选择用户方便的时间来进行需求评审，这样“用户不能出席需求评审会”这一软件风险就不会发生。 -�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2 转移风险 将可能或者潜在的软件风险转移给其它的单位或个人，从而使得自己不再承担该软件风险。例如如果开发某个子系统存在技术和人力资源方面的风险，可以考虑将它外包给其它软件开发公司，从而将该软件风险从项目中转移出去。 -�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2�0�2 消除发生软件风险的根源 如果知道导致软件风险发生的因素，那么针对这些因素，采取手段消除软件风险发生的根源。例如如果发现导致小刘离开项目组的主要原因是薪酬太低，那么可以通过给小刘增加薪酬来消除发生软件风险的根源。�0�2 n�0�2�0�2�0�2�0�2�0�2�0�2 风险监控 在风险评估和控制过程中，项目组人员和负责人必须对软件风险的化解程度及其变化（如发生概率、可能导致的损失和危险度）进行检查和监控，并对收集到的有关软件风险信息进行记录，以促进对软件风险的持续管理。 风险监控的主要内容包括：监控和跟踪重要软件风险，记录这些软件风险危险度的变化以及软件风险化解的进展，确认软件风险是否已经得到化解和消除，是否有新的软件风险发生等等。
IT项目管理中有哪些常见的风险，如何规避？
一般IT项目管理中常见的风险有以下几类：
需求变更风险。需求变更是软件项目经常发生的事情。一个看似很有“钱途”的软件项目，往往由于无限度的需求变更而让项目承建方苦不堪言，甚至最终亏损。预防这种风险的办法是项目建设之初就和用户书面约定好需求变更控制流程、记录并归档用户的需求变更申请。
进度风险。有些项目对进度要求非常苛刻，但对于进度要求不高的项目，同样要考虑该风险。项目进度的延迟意味着违约或市场机会的错失，预防这种风险的办法一般是分阶段交付产品、增加项目监控的频度和力度、多运用可行的办法保证工作质量避免返工。
质量风险。有些项目和用户对软件质量有很高的要求，如果项目组成员同类型项目的开发经验不足，则需要密切关注项目的质量风险。一般需要经常和用户交流工作成果、采用符合要求的开发流程、认真组织对产出物的检查和评审、计划和组织严格的独立测试等。
技术风险。在软件项目开发和建设的过程中，技术因素是一个非常重要的因素。项目组一定要本着项目的实际要求，选用合适、成熟的技术，千万不要无视项目的实际情况而选用一些虽然先进但并非项目所必须且自己又不熟悉的技术。如果项目所要求的技术项目成员不具备或掌握不够，则需要重点关注该风险因素。
在应对IT项目的风险方面，可以借助信息化项目管理系统解决，比如8Manage PPM，能够对项目进行全程的风险跟踪，自动检测项目各种系统性风险及其影响，包括项目计划，成本，资源以及质量的风险，并且能根据现有影响自动推测最终的影响，做到自动监测超时和超支风险、自动监测使用不恰当资源与资源短缺的风险等工作，并提供集成的风险登记表和预警提示，使项目人员可清楚地知道若不及时恰当地管理这些风险的严重性。同时，8Manage支持记录用户自定义风险并跟踪风险从开始到结束的整个过程。系统会自动根据风险发生几率的高低和采取行动前后风险的的影响来分类和评估每个风险，以便项目人员更快速有效地确定行之有效的方案来避免风险，为IT项目的成功研发保驾护航。
软件项目风险管理控制措施
摘要 ：软件项目开发需要投入大量的人力、物力和财力，但在开发的过程中存在着诸多不确定性和可变性，因而有必要对软件项目风险进行管理与控制。本文通过对软件项目全程的风险识别、分析、应对及监测，在项目开发各阶段积极做好风险防控工作，以达到降低项目风险、减少风险损失的目的。
关键词 ：软件项目开发；风险管理；风险防控
1引言
风险是指在某项活动开展的过程中，一些突发的、不确定的因素对活动参与者造成损害、对自然环境造成破坏的概率[1]。与其他工程项目一样，软件项目的开发也存在着各种各样的风险，如项目资金透支、工期延长、系统不能满足需求等。因而在软件开发的过程中，做好风险管理将有助于降低开发风险，保证开发质量。
2软件项目风险分类
2.1技术风险
软件在分析、设计、测试及实施过程中，可能发生的潜在技术问题给软件项目带来的危害称为技术风险，如采用了陈旧或尚不成熟的技术、系统文档编制不规范等。
2.2管理风险
管理风险是指由于项目在预算、人员、进度、资源等方面缺乏计划、控制与管理，从而对软件项目产生的不良影响。
2.3商业风险
商业风险又称为市场风险，包括开发出来的软件产品不符合市场需求、对软件产品定位不清从而缺乏市场竞争力、市场竞品较多竞争激烈等。
2.4安全风险
安全风险主要包括自然风险、人为风险、外部环境风险，如盗版、病毒等。
3软件项目风险管理步骤
3.1风险识别
风险识别阶段需要识别出哪些风险会影响软件项目的开发，包括这些风险的类别、因素、出处、后果等内容[2]。风险识别的常用方法包括以下几种。
（1）专家调查法。就软件项目开发风险问题，征询项目相关行业领域专家的意见，将收集到的意见和建议整理形成报告，随后将报告发送给各位专家再次进行征询。如此反复，经历数轮后，当专家们的意见趋于一致时就可以得出最后结论。
（2）头脑风暴法。将项目开发小组成员、立项单位代表、邀请的专家顾问召集起来，通过会议的方式，就项目开发风险展开讨论交流，以期对项目风险进行准确识别、分析和预测。
（3）风险检测表法。设计并使用各类条目式风险检测表，帮助项目小组识别各种风险。如开发人员风险检测表，可以罗列出诸如开发人员技术水平如何、开发人员是否具有类似项目开发经验、开发人员的人数是否合适、开发人员是否能够自始至终地参加软件开发工作、开发人员是否能集中全部精力投入软件开发工作、开发人员是否接受过必要的培训、开发人员的人员流动是否能保证工作的连续性等条目。通过对这些问题的分析与回答，可以识别出人员因素对软件项目带来的风险。
3.2风险分析
风险分析主要是针对风险事件发生概率及其后果进行评估[3]。为完成对各种风险的评估，需建立风险度量指标体系，明确各种风险带来的后果与损失，估算风险对软件项目的影响程度，最终给出风险估算的结果[4]。风险分析时，常使用四元组[R,P,I,W]来对风险进行描述。其中R代表风险，P代表风险发生的概率，I代表风险带来的影响，W代表风险对项目影响的权重。由于能否按照合同规定的软件性能、时间和金额等条款完成软件开发工作，对项目的顺利验收起着至关重要的作用。因而重点选取成本、进度、软件性能三个方面对软件项目风险进行度量，当某一方面的度量值达到或超过临界点时，软件项目将被迫终止。
通常风险评估的过程可分为四步：
（1）根据风险识别的结果，分析每种风险的发生概率，每种风险对项目成本、进度、软件性能三方面影响的大小，依据风险后果的严重程度为每种风险赋予不同的风险权重。
（2）定义每种风险的四元组[R,P,I,W]。
（3）定义项目被迫终止的临界点。
（4）预测风险组合对项目的综合影响[5]。
3.3风险应对
对可能发生的各种风险需拟定相应的应对策略。常用的应对策略有预防风险、风险转移、风险回避等。预防风险通常指通过提高软件项目各阶段的可靠性和规范性，从而降低风险发生的概率。风险转移是指利用合同、保险、担保、出售、发包等方式[6]，将风险发生时的部分损失转移至第三方，以降低己方风险损失。风险回避是指当某些风险的发生不可避免且后果较严重时，可对项目方案进行调整，更甚者则主动放弃该项目，以免造成不可挽回的损失。在完成风险识别、分析和应对策略选择后，应形成一个易于理解的风险分析与应对表，如表1所示。
3.4风险监控
风险监控是指依据前期风险分析结果，监控风险应对措施的实施情况，加强对项目全过程风险的管控[7]。风险监控的目的是监测风险管理策略和应对措施的实际执行效果，看其是否达到预期目标，同时根据当前风险监控结果及时修正风险分析与应对表，或对项目中新识别的风险进行分析并制定相应的风险应对措施[8]。
4风险防控措施
4.1需求分析阶段
软件需求是软件开发的依据，也是软件验收的标准，因此对软件需求的精准确定就属于软件项目开发的重点和难点。一方面用户开始时很难完整且清楚地对软件系统的功能、性能、运行环境等方面的需求进行准确表达。但随着项目的深入，用户对软件的需求可能会越来越明确，也越来越多，甚至有时到测试阶段还会出现有用户要求更改软件需求的情况。这对系统分析人员和软件开发人员来说是难以接受的。另一方面，用户、系统分析人员和软件开发人员对软件需求描述的方式也各不相同。用户希望使用自然语言对软件需求进行描述，而专业人员则希望采用结构化的说明语言，如数据流图、数据字典等。这样既可以避免自然语言容易引起的二义性和不确定性，又能为下一步软件设计工作提供便利。
针对这类情况的防控措施包括：
（1）加强对立项单位的组织结构、工作流程和现有软件系统的了解。
（2）系统分析人员需掌握一些获取用户需求的技术和方式。
（3）可将公司已投入使用的类似软件作为软件原型，提交给用户使用，便于系统分析人员对用户需求的收集。
（4）组织由立项单位、系统分析人员和系统设计人员共同参与的需求评审会，最终形成达成一致的需求分析阶段的结果——需求规格说明书。
（5）对需求分析阶段完成后用户提出的新需求，可采取留在以后版本升级中处理，如立项单位要求必须加入的，则可与客户商量延长开发时间、增加合同金额。
4.2设计与开发阶段
如果软件产品采用原型法进行开发，虽能降低因需求不明确带来的项目风险，但由于原型法采用循环迭代的方式来不断满足用户需求，这样可能会导致软件的设计与开发超出预期的花费和时间，并且在反复修改的过程中，容易使客户对项目是否能够顺利完成产生疑虑。针对这类风险，一方面可将生命周期法与原型法结合在一起，互为补充，软件开发中以结构化生命周期法为主要方法，在部分环节则利用原型法来快速获取用户反馈信息[9]。另一方面做好与客户的沟通，及时告知客户软件设计与实现的进度与过程[10]。
4.3测试阶段
测试阶段常面临的风险为测试用例不完善。这样可能导致测试不够全面，软件中存在的错误未能发现，使得软件性能降低。可采取的防控措施包括：
（1）对测试人员进行软件需求的培训。
（2）加强对测试用例的评审。
（3）在条件允许的情况下，可以邀请用户参与软件测试。
4.4实施阶段实施阶段可能会面临客户过于依赖技术人员，迟迟不肯验收项目的风险。采取的防控措施包括：
（1）形成规范的《用户手册》，加强对软件用户的培训。
（2）做好领导层的工作。
（3）宣讲公司后期的服务范围和服务管理的规范性。新旧系统切换的过程中也存在一定的风险。如果转换工作缺乏规范的管理和可靠的安全保障，势必会造成严重的后果，甚至影响正常工作。面对这种情况，一是需要特别注意原系统和新系统的文件保护工作，加强人员的管理和数据的备份；二是根据用户要求、立项单位状况、转换过程中的进展情况调整系统切换进程。
5结束语
软件开发过程中存在着各式风险，对每种风险都需要实施风险管理。由此可见，风险管理本身也可构成软件项目中的一个子项目。科学地制定软件项目风险管理计划，在必要的人力资源和经费的支持下，持续完成风险识别、分析、应对和监控等风险管理步骤[11]，做好项目开发各阶段的风险防控工作，从而达到将风险控制在最低限度，减少风险对软件项目的影响，更好地控制软件开发成本和进度的目的。
参考文献
[1]杨一平,卢山.管理信息系统.北京:机械工业出版社,2018
[2]索红军.软件项目风险分析与研究.软件导刊,2017,16(08):128-131
[3]顾单.S公司战略型物料采购策略研究[硕士学位论文].上海交通大学,上海,2015
[4]百度文库.软件项目的风险分析.
[5]韩最蛟.软件工程基础.北京:清华大学出版社,2009
[6]王慧.公路工程施工阶段成本风险管理与分析控制.建材与装饰,2019(24):259-260
[7]梅旭东.M公司卡拉奇核电站项目风险管理研究[硕士学位论文].东华大学,上海,2018
[8]刘强管理.基于国际工程项目全生命周期的风险管理.土木工程与管理学报,2017,34(06):1-9+16
[9]苑隆寅.图书馆在城乡统筹发展中的作用与知识服务研究[硕士学位论文].重庆大学,重庆大学,2012
[10]马兴鹏.高校综合分析平台项目的系统分析与设计[硕士学位论文].东北大学,辽宁,2011
[11]詹红艳.软件项目管理中风险控制策略研究.软件,2019,40(06):230-232
作者：杨辉 单位：湖北交通职业技术学院交通信息学院
关于软件开发的技术风险及规避方案和软件项目开发的风险和措施的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
