英语原文共 26 页，剩余内容已隐藏，支付完成后下载完整资料
软件开发项目中的风险因素：系统的文献综述
Juacute;lioMenezes Jr 克里斯汀·古斯芒＆赫曼诺·莫拉（Hermano Moura）
软件质量杂志 卷 27， 页1149 - 1174年（ 2019）引用本文
541次访问
摘要
风险是任何软件项目的固有部分。在软件开发项目的环境中存在风险需要感知，以便相关的因素不会导致项目失败。对这些因素的正确识别和监视对于软件开发项目和软件质量的成功至关重要。但是，在实践中，软件开发项目中的风险管理仍然经常被忽略，原因之一是由于对风险因素的了解不足，导致对环境的了解不足。本文旨在确定并绘制软件开发项目环境中的风险因素。我们通过数据库搜索进行了系统的文献综述，并对所选研究的质量进行了评估。所有这些过程都是通过研究方案进行的。我们确定了41个研究。在这些工作中，我们根据软件工程学院（SEI）开发的软件开发分类法对风险因素进行了提取和分类。总共对148个不同的危险因素进行了分类。发现的证据表明，与软件需求有关的风险因素是最经常出现和引用的。此外，我们强调指出，最常提及的风险因素是员工缺乏技术技能。因此，结果表明需要对这些因素进行更多的研究，以作为降低软件开发项目故障水平的基本项目。我们根据软件工程学院（SEI）开发的软件开发分类法对风险因素进行了提取和分类。总共对148个不同的危险因素进行了分类。发现的证据表明，与软件需求有关的风险因素是最经常出现和引用的。此外，我们强调指出，最常提及的风险因素是员工缺乏技术技能。因此，结果表明需要对这些因素进行更多的研究，以作为降低软件开发项目故障水平的基本项目。我们根据软件工程学院（SEI）开发的软件开发分类法对风险因素进行了提取和分类。总共对148个不同的危险因素进行了分类。发现的证据表明，与软件需求有关的风险因素是最经常出现和引用的。此外，我们强调指出，最常提及的风险因素是员工缺乏技术技能。因此，结果表明需要对这些因素进行更多的研究，以作为降低软件开发项目故障水平的基本项目。我们着重指出，最常提及的风险因素是员工缺乏技术技能。因此，结果表明需要对这些因素进行更多的研究，以作为降低软件开发项目故障水平的基本项目。
关键字：软件风险管理，风险因素，项目管理，系统的文献综述
1 引言
可以理解的是，只要能够按进度和成本成功地完成项目目标，并获得良好的客户接受度，就可以控制组织内部政治和标准范围的变化，并且可以用作参考模型（Wysocki 2011年； Kerzner，2017年）。考虑到多种因素，我们可以推断出项目管理不是一件容易的事。有效地应用项目管理技术对于项目实现其目标至关重要。
在软件开发项目中，没有什么不同。软件项目管理通常集中在四个支柱上：人员，产品，过程和项目（Pressman 2005），也就是说，软件工程活动由与工件交付相关的人为因素组成，使用一组控制项目计划并且必须是可靠的方法和工具。从这个角度来看，我们可以肯定，软件项目本身是有风险的投资（查瑞特1989 ;贝姆1991 ;德马尔科1997年 ;奥利维拉等人2012）。从这个意义上讲，软件开发项目具有特定的特征，从管理的角度来看，它们使其变得复杂。在这些特征中，三个突出：人与人之间的互动，高度的复杂性和产品的多功能性（Sarigiannidis和Chatzoglou 2014； Jorgensen 1999； Subramanian等2007）。根据Charette（2005），导致软件项目失败的最常见因素是不切实际的目标，错误的估计，定义不明确的系统要求，项目状态表示不当以及未管理的风险，也就是说，即使在不同领域中的广泛应用，软件开发在失败方面享有盛誉（Savolainen等人2012）。这样，至关重要的是将至少要设法识别和监视可能导致软件开发项目性能下降或故障的因素的战略系统化。
风险或风险因素的识别被认为是风险管理中最有影响力的活动（De Bakker等，2010；Loacute;pez和Salmeron 2012），并广泛用于敏捷和传统软件开发方法中（Neves等，2014）。风险因素被定义为可能对成功完成软件开发项目构成严重威胁的条件（March＆Shapira 1987）。复杂系统开发中风险识别过程的低效率被认为是项目失败的主要原因之一（Reeves等人，2013年））。几项研究指出，实际上，风险管理与软件开发项目的成功与否之间存在直接的关系（Jiang和Klein，2000； Jiang，2001； Raz等，2002； Wallace和Keil，2004；Jack等。Wallace等，2004a； De Bakker等，2010； Han和Huang，2007）。这些研究表明，至少应该识别和控制风险因素，以使项目实现其目标。因此，风险因素的识别在软件开发项目的成功与执行中起着至关重要的作用。
在这种情况下，本文旨在通过系统的文献综述来绘制软件开发项目的风险因素。这项工作的主要目的是通过全面而严格的文献综述来查找和分类软件开发项目风险因素的证据。使用系统的文献综述可以扩大结果的范围，并在软件开发项目的背景下更深入地了解最新技术。因此，我们要对此系统文献进行调查的推测是，对软件开发项目环境中的风险因素有一个全面的了解非常重要。
这项工作是博士学位的一部分。一项主要目标是提出和评估指标的研究，该指标旨在使用两个信息源（即风险因素和项目特征因素）在多个软件开发项目的背景下衡量项目的风险水平。博士建议的前提是：使用指标可以有助于更好地理解风险因素，从而可以更好地制定决策，从而避免项目失败。因此，本文旨在对信息源进行识别和分类，以衡量项目的风险水平，并更好地支持软件开发项目环境中的风险识别、分析、控制和风险响应策略。因此，本文的结果使用风险因素的信息来源来衡量软件开发项目的风险水平，一旦最普遍的类别的风险因素，例如，可能暗示更高的类别的资源在软件开发项目的风险衡量过程中。
在这一介绍部分后，本文组织如下：第2节介绍了有关软件风险管理和风险因素，以及相关的作品呈现的理论基础。第3节中详细描述了进行的研究方法。第4节介绍了结果。第5节分深入讨论了发现，并对研究人员和从业人员提出了问题和启示。最后，第6节介绍了结论，局限性和未来的工作。
2理论基础
本节为系统文献综述中进行的数据收集提供了确凿的基础，并介绍了相关工作。
2.1软件开发项目中的风险和风险管理
项目管理不是一件容易的事。为了保证项目成功或提高项目绩效，必须使用一系列定量和定性因素。毫无疑问，风险实际上贯穿于项目的整个生命周期，其最大的信息来源是不确定性。“风险”一词源自意大利早期的风险，意为“敢于冒险 ”（Gerrard and Thompson 2002）。作为一门科学，风险诞生于十六世纪的文艺复兴时期，几乎为概率论奠定了基础（Hall 1998）。
一些作者，特别是在软件工程领域的作者，专注于将风险度量与不利因素度量相关联的认识（Hall 1998），使用损失的概率和损失情况下的后果作为参数，其中产品被称为风险暴露。Pfleeger等。（2001）和Boehm（1989）提出与软件风险相关的三个方面：（i）与事件相关的损失，（ii）事件发生的可能性，和（iii）我们可以改变软件风险的程度。事件的后果，定义为风险暴露，即损失造成的可能性的乘积。
风险管理是指运用技能，知识，工具和技术将威胁降低到可接受的水平，同时又将机会最大化（Heldman，2010年）。软件项目中的风险管理是对影响软件项目，过程和产品的风险进行评估和控制的实践（Hall 1998）。在软件项目中要考虑的重要一点是沟通，尤其是技术风险的沟通，这种沟通通常是众所周知的，但沟通不畅（Carr等，1993）。据认为是软件项目风险管理之父的Barry Boehm所说，“风险管理特别重要，因为它可以帮助人们避免灾难，返工和项目取消，并有助于激发软件项目成功的态势。” （Boehm 1989）。
有关软件风险管理的文献报道的大多数研究都集中于风险的识别和分析，即风险评估（Boehm 1991； Fairley 1994； Dorofee等1996； Hall 1998； Kontio 2001； Goguen等2002）。； DoD 2006； Van Loon 2007）。然而，根据Bannerman（2015年）的观点，很少有研究专注于在软件开发项目中采用风险管理，因为人们已经意识到使用风险管理的实践，但是应用却不多。
近年来，出现了一些与人工智能技术在风险评估中的应用相关的工作，例如灰色关联（Qinghua 2009），概率术语（Fu等人2012），模糊理论（Tang and Wang 2010； Salmeron and Lopez 2012），贝叶斯网络（Fan和Yu 2004）以及基于案例的推理（Trigo等人，2008）。）。这些技术中的大多数将风险因素用作预测风险的信息源。软件项目中的风险管理领域，即使被认为很重要，在研究和实践中仍然需要取得一些进步。其他研究表明，明确的风险管理实践有助于改善绩效并提高项目的成功率（Jiang和Klein 2000； Jiang等2001； Raz等2002； Wallace和Keil 2004； Wallace等2004a； Wallace等人2004b； De Bakker等人2010； Han和Huang 2007）。
2.2软件开发项目中的风险因素
从根本上讲，危险因素是每种危险的来源和原因（Silva 2011； Braziliano 2009）。它们是造成和/或影响风险发生的内部和外部因素。从这个角度来看，风险是一组风险因素的总和，这些风险因素一旦实现，便构成危害。因此，风险因素有助于降低风险的抽象级别。例如，某个特定的组织在不遵循开发方法或编码标准的情况下开发软件，更不用说制定培训政策了。我们可以肯定它们是导致返工危害的条件，也就是说，风险可以理解为导致一定危害的一系列因素。在图1中更好地呈现了这种情况。
单凭一个风险因素并不能充分汇总项目管理中的价值；仅当有明确的发生概率以及相关的影响和后果的概念时，它才有意义。因此，使用风险分类对于更好地识别风险来源很重要。风险分解结构（RBS）是一种有趣的工具，因为它是一种以风险为导向的分组，它以结构化的方式组织，分类和定义已识别项目风险的暴露程度，从而提供了潜在风险因素的层次结构（Hillson 2002）。RBS针对软件开发项目的一项已知提议是Carr等人提出的风险分类法。（ 剩余内容已隐藏，支付完成后下载完整资料
资料编号：[235477]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
