The risk factors affecting to the software quality failures in Sri Lankan Software industry
由于技术故障、质量故障、缺乏最终客户验收等原因，以及缺乏适当的管理，软件项目的失败和取消率日益增加。软件项目失败的原因有很多。经验证据表明，测试资源不足是导致测试质量低下的主要因素之一。本研究的主要目的是研究影响软件质量的风险因素，以提供一些建议，以尽量减少质量差的风险。影响软件质量的主要因素有三个，即适当的测试、测试计划和QA团队，它们直接影响软件质量风险。为了进行这项研究，我采用了一个开放式的问卷调查收集定性数据的答复分析，他们使用主题的方法。有经验的参与者仅同意需求清晰度和明确定义的验收标准，而不同意充分的单元测试，最后，还同意不进行回归测试会导致质量故障。在数据分析方面，没有适当的正式测试计划，初始测试计划不现实，没有遵循质量风险管理，没有适当的过程和应急行动计划也会导致项目质量差的风险。据与会者补充说，以下因素也是软件质量不足的原因。经验丰富和技术熟练的员工离开公司，因为没有适当的QA流程，团队成员没有风险管理意识。
2017-06-04 cs.SE
Analysing software failure using runtime verification and LTL
本文提出一种基于运行时验证的方法，在组件层面诊断四类软件错误，并通过mRUBIS仿真验证其在自修复系统中检测故障的有效性。
2024-02-15 cs.SE
FAIL: Analyzing Software Failures from the News Using LLMs
提出 FAIL 系统，利用 LLM 自动收集、聚类并按分类体系分析新闻报道的软件故障，在大规模语料中识别 2457 起故障并揭示其复发与严重性趋势。
2024-09-18 cs.SE
Failures and Fixes: A Study of Software System Incident Response
本文介绍了与软件系统故障相关的研究结果，目的是了解我们如何更好地发展，维护和支持软件系统的生产。我们对30起事故进行了定性分析：其中15起是通过对工程师的深入访谈收集的，另外15起是从公开发布的事故报告（通常是作为事后审查的一部分产生的）中抽取的。我们的分析重点是了解和分类故障是如何发生的，以及如何检测、调查和缓解它们。我们还以11个关键观察的形式捕捉了与实践现状和相关挑战相关的分析见解。例如，我们观察到故障可能会通过系统级联导致重大中断;并且工程师通常不了解他们所支持的系统的扩展限制，直到这些限制被超过。我们认为，我们已经确定的挑战可以导致系统的设计和支持方式的改进。
2020-08-25 cs.SE
How Bad Can a Bug Get? An Empirical Analysis of Software Failures in the OpenStack Cloud Computing Platform
云管理系统提供用于以编程方式配置云基础设施的抽象和API。不幸的是，这些系统中残留的软件错误可能会导致严重的故障，例如长时间的停机和数据丢失。在本文中，我们调查的背景下，广泛的OpenStack云管理系统的故障的影响，通过执行故障注入和分析所产生的故障的影响方面的故障停止行为，故障检测通过日志记录，故障传播组件。分析指出，大多数故障没有及时检测和通知;此外，许多这些故障可以随着时间的推移并通过云管理系统的组件悄悄传播，这需要更彻底的运行时检查和故障遏制。
2019-07-09 cs.SE
A Software Reliability Model Based on a Geometric Sequence of Failure Rates
软件可靠性模型是软件质量管理和发布计划的重要工具。有大量不同的模式，往往在不同的领域表现出优势。本文提出了一种基于故障率几何序列（或级数）的模型。在西门子等公司的实践中观察到了故障过程的这种特性，并导致了所提出的模型的发展。它被详细描述并使用标准标准进行评估。最重要的是，该模型在几个项目中的预测有效性方面一直表现良好。
2016-12-12 cs.SE
PREVENT: An Unsupervised Approach to Predict Software Failures in Production
本研究提出无监督方法PREVENT，无需预定义规则或故障训练数据即可预测定位分布式企业应用故障，在商用云系统中表现优于或不亚于监督方法，更稳定可靠且实用性更强。
2024-09-17 cs.SE
K-Detector: Identifying Duplicate Crash Failures in Large-Scale Software Delivery
在开发人员提交代码后，相应的测试用例会出现，以确保软件交付的质量。在此期间可能会发生测试失败，例如崩溃、错误和超时。由于开发人员需要时间来解决它们，因此在此期间会发生许多重复故障。在SAP HANA的交付实践中，紧急分流被认为是最耗时的任务。如果可以自动识别重复的碰撞故障，自动化程度将大大提高。为了找到这样的重复，我们提出了一个基于训练的数学模型，利用SAP HANA的组件信息，以实现更好的崩溃相似性比较。我们在一个名为基于知识的检测器（K-Detector）的工具中实现了我们的方法，该工具通过11，208个样本进行了验证，AUC为0.986。此外，我们已经将K-Detector部署到生产环境中，它可以节省97%的事故分类统计工作。
2022-06-01 cs.SE
Software Assumptions Failure Tolerance: Role, Strategies, and Visions
在我们的命令或其他情况下，当我们的软件正在执行时，各种各样的设计假设不断地与当前条件的真相相匹配。虽然存在标准和工具来表达和验证其中的一些假设，但在实践中，大多数假设最终要么被过滤掉，要么隐藏在我们的代码中。在整个系统层中，一个复杂的、有时模糊的假设网络决定了我们的软件与其部署平台和运行时环境的匹配质量。我们的立场是，它变得越来越重要，能够设计软件系统的架构和结构技术，允许软件被分解，以降低其复杂性，但没有隐藏在过程中的重要假设和假设。在本文中，我们讨论了这个问题，介绍了三个潜在的危险后果的否认，并提出了三个战略，以促进他们的治疗。最后，我们提出了一个新的整体的方法来软件开发，以克服碎片化的意见，假设失败的问题所提供的缺点，我们的愿景。
2016-04-11 cs.SE
Success and Failure in Software Engineering: a Followup Systematic Literature Review
本文针对软件工程中成功与失败现象进行后续深入系统文献综述，提出包含500+因素的扎根理论、14个人工验证因素集群及组织结构质量模型，为管理者提供风险预测与细粒度参数分析。
2020-06-22 cs.SE
The Unnecessity of Assuming Statistically Independent Tests in Bayesian Software Reliability Assessments
在评估基于软件的系统时，对运行测试数据进行贝叶斯统计推断的结果可以为软件可靠性声明提供强有力的支持。对于推理，通常假设这些数据（即软件成功和失败）出现在独立同分布（i.i.d.）方式在本文中，我们将展示如何保守的贝叶斯方法使这个假设不必要的，通过将一个人的怀疑的假设到评估。当操作测试显示没有故障时，我们推导出系统按需故障概率（pfd）的保守置信区间。的一般性和效用的置信区间的核电厂安全保护系统的评估中说明，根据不同程度的怀疑i.i.d.。假设分析表明，i.i.d.假设可以使贝叶斯可靠性评估非常乐观-这种评估没有明确说明软件如何在广泛的操作测试期间很可能不出现故障，尽管软件的PFD非常大。
2022-12-22 cs.SE
Failures to be celebrated: an analysis of major pivots of software startups
在软件初创公司的背景下，项目失败被积极接受，并被认为对于获得可导致支点的有效学习至关重要。支点是一个商业概念，产品或商业模式的不同元素的战略变化。为了使软件创业团队在混乱和不可预测的环境中做出更好的决策，需要更好地了解不同类型的支点以及导致失败和触发支点的不同因素。由于该主题的新生性质，现有的研究和知识的支点的软件创业公司是非常有限的。在这项研究中，我们的目的是确定软件初创公司在启动过程中所做的主要类型的枢轴，并强调失败的软件项目和触发枢轴的因素。为了实现这一点，我们进行了一个案例调查研究的基础上发生在49个软件创业公司的主要支点的二手数据。确定了10种枢轴类型和14种触发因素。研究结果显示，顾客需求枢轴是所有枢轴类型中最常见的。与客户细分枢纽一起，它们是常见的市场相关枢纽。与产品相关的主要枢轴是放大和技术枢轴。确定了几种新的枢轴类型，包括市场放大、完整和副项目枢轴。我们的研究还表明，负面的客户反应和有缺陷的商业模式是触发软件初创公司支点的最常见因素。本研究拓展了软件启动枢纽类型和枢纽触发因素的研究知识。同时，它为软件创业公司提供了实用知识，他们可以利用这些知识来指导他们有效地进行枢转决策
2017-10-11 cs.SE
Exploring the extent of similarities in software failures across industries using LLMs
University of New Mexico（新墨西哥大学）
本文利用大语言模型对软件故障新闻文章进行行业和故障类型分类，并可视化分析跨行业故障相似性，为识别常见漏洞和预防风险提供资源。
2024-08-08 cs.AI cs.SE
RepoMiner: a Language-agnostic Python Framework to Mine Software Repositories for Defect Prediction
来自开源软件项目的数据为提高软件质量提供了宝贵的信息。在软件缺陷预测的范围内，最具挑战性的部分之一是从这些存储库中提取有关易失败软件组件的有效数据，这可以帮助开发更健壮的软件。特别是，从这些存储库中收集数据、计算度量和合成结果是一项乏味且容易出错的任务，这通常需要理解所挖掘的存储库中涉及的程序设计语言，最终导致特定于语言的数据挖掘软件的激增。本文介绍了RepoMiner，语言无关的工具，开发支持软件工程研究人员在创建数据集，以支持任何研究缺陷预测。RepoMiner自动从软件组件中收集故障数据，将其标记为易故障或中性，并计算用作缺陷预测模型基础事实的指标。我们提出了它的实现，并提供了它的应用程序的例子。
2021-11-23 cs.SE
Initial and Eventual Software Quality Relating to Continuous Integration in GitHub
对新功能和错误修复的持续需求迫使软件项目缩短周期并更快地交付更新，同时保持软件质量。廉价的虚拟化云计算的可用性通过支持按需持续集成（CI）帮助缩短了时间表。像GitHub这样的平台支持云中的CI。在使用CI的项目中，用户提交拉取请求会触发CI步骤。除了加速构建和测试之外，这还意外地创建了大量构建和测试成功和失败的档案。CI是一个相对较新的现象，这些档案允许对CI进行详细的研究。暴露出多少问题？它们发生在哪里？哪些因素会影响CI失败？CI确定的“初始质量”是否能预测代码中以后会出现多少bug（“最终质量”）？在本文中，我们对这些记录进行了大规模的精细分辨率研究，以更好地了解CI过程，CI失败的性质和预测因素，以及CI失败与代码最终质量的关系。我们发现：a）CI失败似乎集中在几个文件中，就像正常的bug一样; b）CI失败与最终失败的相关性不是很高; c）在pull请求中使用CI并不一定意味着该请求中的代码质量良好。
2016-06-02 cs.SE
Exhaustive Exploration of the Failure-oblivious Computing Search Space
软件系统的高可用性要求在出现错误时自动处理崩溃。故障无关计算是一种旨在实现高可用性的技术。我们注意到，失败遗忘还没有被深入研究，也很少有研究有助于理解为什么失败遗忘技术有效。为了使失效不经意计算在实践中产生影响，我们需要深入了解软件中的失效不经意行为。在本文中，我们研究，设计和执行一个实验，分析的大小和多样性的失败遗忘行为。我们的实验包括穷举计算的搜索空间的16个领域失败的大型开源Java软件。这个实验的结果是更好地理解当使用故障无关计算时会发生什么，这开辟了新的有前途的研究方向。
2018-03-23 cs.SE
Reflecting on Recurring Failures in IoT Development
随着物联网系统被赋予更多的责任和自主权，它们提供了更大的好处，但也带来了更大的风险。我们相信这种趋势会重新提出软件工程的一个老挑战：如何在市场压力下安全可靠地开发高风险的软件密集型系统？作为第一步，我们对最近的物联网故障进行了系统分析，以确定工程挑战。我们收集并分析了22篇新闻报道，研究了物联网系统故障的来源、影响和修复策略。我们观察了应用程序域内部和跨应用程序域的故障趋势。我们还观察到，失败主题随着时间的推移而持续存在。为了缓解这些趋势，我们概述了针对物联网开发的故障感知软件开发生存周期的研究议程。我们提出了一个百科全书的故障和经验的基础上，系统事后分析，辅以适当的自动化工具。
2022-09-19 cs.SE
Detection Software Content Failures Using Dynamic Execution Information
现代软件系统变得过于复杂，无法进行测试和验证。在运行时检测复杂系统中的软件部分故障有助于处理软件非预期行为，避免灾难性软件故障并提高软件运行时可用性。这些检测技术的目的是发现故障的表现形式之前，他们最终导致不可避免的故障，从而支持以下运行时容错技术。本文通过对国内外相关文献的回顾，发现内容故障在各类软件故障中占绝大多数，但对其检测方法的研究却很少。在这项工作中，我们提出了一种新的故障检测指标的基础上，软件运行时的动态执行信息的软件内容故障。在软件执行期间记录运行时信息，然后将其转换为称为运行时熵的度量，并最终馈送到机器学习模型中。建立机器学习模型是为了对目标软件系统的预期和非预期行为进行分类。在多个开源项目上进行了一系列的控制实验，证明了该方法的可行性。我们还评估了在这项工作中构建的机器学习模型的准确性。
2021-10-13 cs.SE cs.SY eess.SY
Software is infrastructure: failures, successes, costs, and the case for formal verification
Université Paris Cité（巴黎西岱大学）；University of Malta（马耳他大学）；University of Southern Denmark（南丹麦大学）；King’s College London（伦敦国王学院）
本文探讨了软件在现代社会中的重要性及质量缺陷带来的成本，主张通过形式验证和程序分析来提升软件可靠性。
2026-01-29 cs.CY cs.SE
Failure Mechanism Traceability and Application in Human System Interface of Nuclear Power Plants using RESHA
近年来，已经做出了相当大的努力，用数字仪器和控制系统使现有的和新的核电站现代化。然而，行业和监管机构对这些系统的风险和后果分析也相当关注。值得关注的是数字共因故障，特别是由于软件缺陷。软件的这些故障可能发生在系统的控制和监视中。虽然已经提出了许多方法来识别软件故障模式，如系统理论过程分析，数字系统的危害和后果分析等，这些方法主要集中在系统的控制动作路径上。相比之下，信息反馈路径缺乏不安全控制动作，这些动作通常与软件基本事件相关;因此，此类系统中软件基本事件的评估不清楚。在这项工作中，我们提出的想法，中间处理器和不安全的信息流（UIF），以帮助安全分析师跟踪故障机制的反馈途径，以及如何将它们集成到一个故障树，以提高评估能力。提出的概念证明了两个全面的案例研究，一个智能传感器集成平台的无人驾驶自动驾驶汽车和另一个代表性的先进的人类系统接口的安全关键工厂监控。定性的软件基本事件的识别，并进行故障树分析的基础上，一个改进的Redundancy引导系统理论的危险分析方法。案例研究表明，使用UIF和中间处理器的故障树，以提高高度复杂的数字仪表反馈的软件故障的可追溯性。改进后的方法阐明了当系统中存在多个部件依赖时故障树的构造。
2022-05-24 cs.SE
PExReport: Automatic Creation of Pruned Executable Cross-Project Failure Reports
本文提出PExReport，自动生成精简可执行的跨项目失败报告，利用构建工具精简代码与依赖，在74个项目198个失败中成功创建184个报告，平均减少72.97%的类。
2023-05-11 cs.SE
Reliability Testing Strategy - Reliability in Software Engineering
本文介绍了软件工程中可靠性的核心原则-概述了为什么可靠性测试是至关重要的，并指定了测量可靠性的过程。本文为软件工程领域的新手和专家提供了评估软件系统失效强度和预测软件系统失效的见解。测量是通过利用来自操作配置文件的信息来进行的，以进一步增强测试计划和测试用例，所有这些本文都演示了如何实现。
2016-05-03 cs.SE
Improving the Testability of Object-oriented Software during Testing and Debugging Processes
可测试性是在程序中存在错误的情况下，测试是否会检测到错误的概率。如何有效地发现故障取决于软件的可测试性。许多研究人员提出了定性和定量的技术来提高和衡量软件的可测试性。在文献中，大量的可靠性增长模型已被用于评估和衡量软件在测试和运行阶段的定量质量评估。了解软件故障分布及其复杂性可以提高软件的可测试性。通过了解故障分布和故障复杂度，可以使测试工作量的分配变得容易，这将简化从软件中发现故障的过程。因此，软件的可测试性将得到改善。文中给出了该模型的参数以及不同复杂度的故障在软件中所占的比例，并利用在开源环境下开发的两个面向对象软件MySQL for python和Squirrel SQL Client的故障数据进行了估计
2013-08-15 cs.SE
Incorporating Failure Knowledge into Design Decisions for IoT Systems: A Controlled Experiment on Novices
物联网（IoT）系统允许软件直接与物理世界交互。最近的物联网故障可以归因于反复出现的软件设计缺陷，这表明物联网软件工程师可能没有从过去的失败中吸取教训。我们研究了使用失败案例来改进物联网系统设计。我们进行了一项实验，以评估失败相关的学习治疗设计决策的影响。我们的实验采用了新手（计算机工程专业的学生）完成设计问卷的主题之间的比较。有三种治疗方法：对照组（N=7）;考虑一组设计指南（N=8）;考虑失败故事（建议治疗，N=6）。我们衡量了他们的设计决策和设计原理。所有受试者都做出了类似的决定。他们的理由因治疗而异：接受指南和失败故事治疗的受试者更多地使用关键性作为理由，而接受失败故事治疗的受试者更频繁地使用安全性作为理由。基于这些发现，我们提出了几个研究方向，以实现故障感知物联网工程过程。
2023-03-20 cs.SE
Application of Orthogonal Defect Classification for Software Reliability Analysis
采用数字仪表和控制系统（DI&C）对现有和新建核电厂进行现代化改造是一个最近的热门话题。然而，美国（U.S.）核管理委员会（NRC）和工业界。在这项工作中，我们开发了一种方法，称为软件可靠性评估（ORCAS）的软件缺陷分类，以量化的DI&C系统中的各种软件故障模式的概率。该方法采用公认的行业质量保证方法，并通过实验证据进行验证。本质上，该方法结合了语义故障分类模型和可靠性增长模型来预测软件系统故障模式的概率。案例研究是在一个代表性的I&C平台（Chibios）上进行的，该平台运行由弗吉尼亚联邦大学（VCU）开发的智能传感器采集软件。应用了ORCAS中的测试和证据收集指南，发现了软件中的缺陷。定性证据，如修改的条件决策覆盖率，被用来衡量的完整性和可信度的评估，而定量证据被用来确定软件故障概率。然后估计软件的可靠性，并将其与传感器设备的现有操作数据进行比较。它表明，通过使用ORCAS，可以开发一个语义推理框架，以证明如果软件是可靠的（或不可靠的），同时仍然利用现有方法的强度。
2022-05-24 cs.SE
Using rule engine in self-healing systems and MAPE model
针对软件故障带来的风险与维护成本问题，提出一种基于规则引擎的故障修复方法，并在mRUBIS仿真中验证其有效性，从而提升软件系统的可靠性、安全性与适应性。
2024-02-18 cs.SE
Exploratory Test Agents for Stateful Software Systems
对有状态软件系统进行充分的测试是一项困难而昂贵的工作。由复杂的有状态交互导致的故障可能具有很高的影响，并且很难复制由错误的有状态交互导致的故障。以自动化的方式解决这个问题将节省成本和时间，并提高行业中软件系统的质量。在本文中，我们提出了一种方法，使用代理来探索软件系统的意图，找到故障和获得知识。
2020-04-17 cs.SE
Demonstrating Software Reliability using Possibly Correlated Tests: Insights from a Conservative Bayesian Approach
本文提出保守贝叶斯方法，在软件执行可能相关时评估可靠性，揭示独立性假设的影响，并指出运行测试的徒劳性与故障敏感性，应用于核电站和自动驾驶安全。
2023-10-11 cs.SE
AI Failures in the Eyes of the Downstream Developer: A First Look at Concerns, Practices, and Challenges
The University of Melbourne（墨尔本大学）；Socket Inc.（Socket公司）；Purdue University（普渡大学）；Singapore Management University（新加坡管理大学）
研究探讨下游开发者在使用预训练模型时对AI失败的担忧、实践及挑战，通过混合方法研究揭示实际应用中的问题与应对策略。
2026-04-30 cs.SE
Optimising the reliability that can be claimed for a software-based system based on failure-free tests of its components
本文介绍了一种数值方法，用于优化系统可靠性的保守置信区间的基础上，测试其单个组件。这是Bishop和Povyakalo（RESS 2020）中确定的算法方法的替代方案。对于给定的最大部件测试次数，数值方法可以导出任意系统结构的最优测试计划。优化方法是基于线性规划，这是更有效的替代整数规划。此外，对于任何给定的系统结构，优化过程只需要执行一次，因为该解决方案可以被重新用于计算不同的最大数量的组件测试的最佳整数测试计划。这种方法可能有更广泛的应用，通常使用整数规划方法实现的其他优化问题。
2022-01-30 cs.SE
Fault Localization in a Software Project using Back-Tracking Principles of Matrix Dependency
故障识别和测试一直是软件开发领域最具体的关注点。为了识别和验证错误，我们应该知道故障的来源或任何不必要的问题。在本文中，我们试图提取故障的位置，并试图应付的错误。利用有向图的方法，尝试获取实时环境中多个活动之间的依赖关系，以跟踪故障的来源。软件开发涉及一系列活动，我们试图展示多个活动之间的依赖关系。关键活动被认为是导致整个系统功能异常的活动。本文讨论了软件失效依赖活动对关键活动的优先级问题。选择活动的矩阵表示作为软件的一部分，使用依赖性概念来确定故障的根源。它可以随网络拓扑和软件环境而变化。当故障发生时，可能的征兆将以故障本身的高概率反映在依赖矩阵中。因此，独立故障位于依赖矩阵的主对角线上。
2014-05-05 cs.SE
Software Engineering Antipatterns in Start-Ups
本文分析了88份初创企业经验报告，提出三种软件工程反模式，揭示看似商业或市场相关的初创企业失败场景实则源于产品工程不足。
2023-11-20 cs.SE
Bug propagation and debugging in asymmetric software structures
软件依赖网络被证明是无标度和不对称的。然后，我们研究如何软件组件的失败，其中之一的影响，以及定位故障组件的逆问题。对于一个随机的单个组件的故障，所有级别的软件都是脆弱的。如果故障只影响其最近的邻居，则定位故障组件很容易，而如果故障进一步传播，则很难。
2003-11-24 cond-mat.dis-nn cond-mat.stat-mech cs.SE
How Far Does the Predictive Decision Impact the Software Project? The Cost, Service Time, and Failure Analysis from a Cross-Project Defect Prediction Model
背景：跨项目缺陷预测（CPDP）模型正在开发中，以优化测试资源。目的：提出了一个集成分类框架的CPDP，许多现有的模型缺乏更好的性能和分析的主要目标的CPDP从建议的分类框架的结果。方法：对于分类任务，我们提出了一种基于自举聚合的混合诱导集成学习（HIEL）技术，使用概率加权多数表决（PWMV）策略。为了了解HIEL对软件项目的影响，我们提出了三个特定于项目的性能指标，如完美清洗百分比（PPC），非完美清洗百分比（PNPC）和错误遗漏率（FOR），从预测中计算出节省的成本，剩余服务时间和目标项目中失败的百分比。结果如下：在PROMISE、NASA和AEEEM库的许多目标项目上，所提出的模型在F-度量方面优于最近的工作，如TDS、TCA+、HYDROGEN、TPTL和CODEP。在AUC方面，TCA+和HYDRONIC模型是HIEL模型的强有力竞争对手。结论：为了更好地预测，我们建议CPDP模型采用集成学习方法。而且，为了估计CPDP模型的好处，我们建议采用上述项目特定的绩效指标。
2022-09-28 cs.SE
An Study of The Role of Software Project Manger in the Outcome of the Project
本文介绍了一个深入的分析成功和不成功的软件项目和软件项目经理的作用，成功。软件项目成功的主要原因之一是管理者。软件公司在这方面投入太多，但软件项目的平均失败率偏高。项目经理的经验、技术知识和技能通常不足以取得成功。在本文中，我们进行了一项调查，涉及不同的项目经理所使用的方法，他们的方法和技术，他们的项目的成功率，以及他们在项目期间采取的步骤。我们将探讨软件项目成功的核心原因，然后将建议软件项目经理采取的关键步骤，以交付一个成功的软件项目。
2020-09-29 cs.SE
Lessons from the Failure and Subsequent Success of a Complex Healthcare Sector IT Project
本文认为，IT故障诊断为错误的技术或项目管理水平往往错误地指向故障的症状，而不是一个项目的潜在的社会复杂性（复杂性导致的人和团体的相互作用），这通常是实际的失败的根源。我们提出了一种新的方法，利益相关者影响分析，可用于识别与社会复杂性相关的风险，因为它是基于社会科学，心理学和管理科学的见解。本文以1992年伦敦救护车服务计算机辅助调度项目为例，证明了利益相关者影响分析的有效性，并表明，如果我们的方法被用来识别风险，并减轻风险，它会降低项目失败的风险。本文的原始贡献包括扩大现有的帐户的失败，通过检查失败的粒度级别没有看到其他地方，使潜在的社会复杂性的风险源被确定。
2010-05-14 cs.SE
Greedy Scheduling: A Neural Network Method to Reduce Task Failure in Software Crowdsourcing
内容：高度动态和竞争的众包软件开发（CSD）市场可能会由于不可预见的原因而遇到任务失败，例如共享供应商资源的竞争加剧，或与动态工人供应相关的不确定性。现有分析显示，软件众包市场的平均任务失败率为15.7%。目标：本研究的目的是提供一个软件众包平台的任务调度推荐模型，以提高软件众包的成功率和效率。方法：提出了一种基于神经网络的任务调度方法，并开发了一个可以预测和分析任务到达时失败概率的系统。更具体地说，该模型使用了一系列的输入变量，包括在平台上的开放任务的数量，到达任务和开放任务之间的平均任务相似度，获胜者的奖金，和任务持续时间，来预测在计划的到达日期和两个剩余的日子任务失败的概率。此预测将提供与最低任务失败概率相关联的推荐日期以发布任务。该模型基于Topcoder的工作流程和数据，Topcoder是主要的软件众包平台之一。结果如下：我们提出了一个模型，建议最好的建议到达日期为项目中的任何任务，每个任务在项目中的两天盈余。该模型平均每个项目的故障率降低了4%。
2021-02-19 cs.DC cs.HC cs.SE
Why Early-Stage Software Startups Fail: A Behavioral Framework
软件创业公司是新创建的公司，几乎没有运营历史，并以生产尖端产品为导向。由于他们的时间和资源极其稀缺，一个失败的项目可能会让他们破产，初创公司需要有效的实践来面对这些独特的挑战。然而，只有少数科学研究试图解决失败的特点，特别是在早期阶段.通过这项研究，我们的目的是提高我们的早期阶段的软件创业公司的失败的理解。这项实践调查是通过文献综述和多病例研究方法进行的。研究结果提出了如何管理策略和执行之间的不一致可能导致失败的行为框架。尽管战略揭示了首先需要了解问题/解决方案的适合性，但实际执行优先考虑产品的开发，以尽快推出市场，以验证产品/市场的适合性，忽略了必要的学习过程。
2017-09-14 cs.SE
What Soft Skills Software Architect Should Have? A Reflection from Software Industry
软件架构师的工作在软件开发的生存周期中被认为是非常关键的，因为软件架构在成本和质量方面对软件项目的成功和失败起着举足轻重的作用。人们具有不同的人格特质，他们感知、计划和执行任何任务的方式都受到人格特质的影响，这些人格特质以软技能为特征。大多数时候，软件开发是一个团队工作，涉及几个人执行不同的任务。软件项目的成功和失败的故事揭示了人的因素是至关重要的。在这项工作中，我们提出了一个探索性的研究软技能要求的软件架构师的工作。我们分析了124个软件架构师职位的招聘信息，并探讨了软技能要求。调查结果有助于了解软件架构师工作的软件技能要求，并介绍了他们在招聘广告中的使用现状。
2015-08-28 cs.SE
Where did we fail? -- Reproducing build failures in embedded open source software
Ericsson AB（爱立信）；KTH Royal Institute of Technology（皇家理工学院）；Mälardalen University（马尔默达尔大学）；Carleton University（卡尔顿大学）
研究针对嵌入式系统中CI构建失败问题，提出PhantomRun框架，通过统一抽象层和可重用数据集标准化构建日志的检索、存储与重现，实现91.8%的构建重现率。
2026-04-29 cs.SE
Using Dynamic Binary Instrumentation to Detect Failures in Robotics Software
自动化和机器人系统（ARS）广泛、复杂，并且越来越多地与公众接触。这些系统中的许多都是安全关键型的，检测软件错误以防止损害至关重要。我们提出了一个家庭的新技术来检测不寻常的程序执行和不正确的程序行为。我们通过在运行时间收集低级信号并使用这些信号构建机器学习模型来对执行行为进行建模。这些模型可以识别以前看不见的执行，这些执行更有可能出现错误。我们描述了一个易于处理的方法收集动态二进制运行时信号的ARS，允许系统吸收大部分的开销从动态仪器。ARS的体系结构特别适合于隐藏插装的开销。我们在ARDUPILOT（一种流行的开源自动驾驶软件系统）和HUSKY（一种无人驾驶地面车辆）的仿真中展示了这些方法的效率。我们对执行进行检测，以收集数据，并从中构建执行的监督机器学习模型，并评估这些模型的准确性。我们还分析了开发具有不同准确度的模型所需的训练数据量，测量使用分析工具的执行所增加的开销，并分析哪些运行时信号对于检测被测程序上的异常行为最有用。此外，我们还分析了时间延迟对ARS功能行为的影响。
2022-01-29 cs.SE
Representative Dataset Generation Framework for AI-based Failure Analysis during real-time Validation of Automotive Software Systems
Technische Universität Clausthal（克劳斯塔尔工业大学）
本研究提出基于HIL仿真与实时FI方法的框架，生成汽车软件系统实时验证中ML应用的代表性故障数据，可生成序列与文本数据，能有效模拟捕获故障下的系统行为。
2026-08-11 cs.SE
An Application of a Modified Beta Factor Method for the Analysis of Software Common Cause Failures
本文提出了一种对数字仪器和控制（I&C）系统中的软件共因故障（CCF）进行建模的方法。CCF由两个或多个组件之间的并发故障组成，这是由于共享的故障原因和耦合机制。这项工作强调了识别以软件为中心的属性的重要性，这些属性与冗余软件组件同时发生故障所需的耦合机制有关。共享耦合机制的组件组称为共同原因组件组（CCCG）。大多数国家合作框架模型依赖于业务数据，以此作为确定气候变化协调小组参数和预测国家合作框架的基础。这项工作的动机是由两个主要问题：（1）缺乏估计软件CCF模型参数的操作和CCF数据;（2）需要同时模拟单个组件作为多个CCCG的一部分。开发了一种混合方法，通过利用现有技术来解决这些问题：修改后的β因子模型允许将单个组件放置在多个CCCG中，而第二种技术为每个CCCG提供特定于软件的模型参数。这种混合方法提供了一种手段，以克服传统方法的局限性，同时提供支持的设计决策下的有限数据的情况下。
2022-06-22 cs.SE cs.SY eess.SY
"So Am I Dr. Frankenstein? Or Were You a Monster the Whole Time?": Mitigating Software Project Failure With Loss-Aversion-Aware Development Methodologies
Engprax Ltd（Engprax有限公司）
研究通过对600名英美软件工程师项目成功经验的大规模研究，发现开发前明确需求、让工程师自由讨论解决问题与项目成功相关，支持开发更关注人为因素防失败的软件开发方法。
2026-07-07 cs.HC cs.SE
Selecting Best Software Reliability Growth Models: A Social Spider Algorithm based Approach
软件可靠性被认为是软件系统的重要组成部分;它涉及测量系统发生故障的概率;因此，它与软件质量密切相关。软件可靠性增长模型用于表示软件完成后遇到的预期故障数量，它也是软件交付准备就绪的指标。本文提出了一种根据现有数据集选择最佳软件可靠性增长模型的方法。几个比较标准用于产生一个排名方法，用于指出最好的模型。社会蜘蛛算法SSA，一个新引入的群体智能算法，用于估计两个数据集的SRGMs的参数。结果表明，使用SSA是有效的，在协助过程中的标准加权，以找到最佳的模型和最佳的整体排名的就业模式。
2020-01-01 cs.SE
The failure tolerance of mechatronic software systems to random and targeted attacks
University of Sydney（悉尼大学）；Oregon State University（俄勒冈州立大学）
本文通过复杂网络方法研究机电软件系统在硬件和/或软件故障下的容错性，发现介数中心性攻击对系统鲁棒性影响最大，且设计架构并不比随机架构更容错。
2013-09-27 cs.DC cs.SE cs.SY
Using Cluster Curves to Control Software Development Projects
在可预测和可控的软件项目执行的漫长道路上，项目数据的在线解释和可视化变得越来越重要。本文概述了软件开发项目的Sprint I控制方法，并给出了初步的评估结果。该方法基于面向上下文的聚类曲线的使用，并集成到软件项目控制中心的框架中。
2014-03-14 cs.SE
Work Breakdown Structure: A Tool for Software Project Scope Verification
软件项目范围验证是软件项目范围管理中的一个重要过程，为了避免项目返工和范围蠕变，需要正确、全面地进行范围验证。此外，软件范围验证在准确交付客户要求的内容和最小化项目范围更改的过程中至关重要。定义良好的软件范围简化了范围验证的过程，并有助于项目的成功。此外，面向交付的WBS提供了一个路线图，以明确定义的软件工作范围。在此基础上，本文将面向可交付成果的工作分解结构应用于范围验证过程。本文认为，面向可交付成果的工作分解结构是一种软件范围验证的工具。
2013-08-13 cs.SE
FailureMem: A Failure-Aware Multimodal Framework for Autonomous Software Repair
Nanjing University（南京大学）；SenseTime（秒速）；The Chinese University of Hong Kong（香港中文大学）；University of Texas at Dallas（德克萨斯大学达拉斯分校）
本文提出FailureMem框架，通过融合工作流代理、主动感知工具和故障记忆库，提升多模态自动程序修复的效率与准确性，实验表明其在GUI修复任务中解决率提升3.7%。
2026-03-18 cs.AI cs.SE
Runtime Failure Hunting for Physics Engine Based Software Systems: How Far Can We Go?
The Chinese University of Hong Kong, China（香港中文大学）；State Key Laboratory of Blockchain and Data Security, Zhejiang University（浙江大学区块链与数据安全国家重点实验室）
本文针对基于物理引擎的软件存在的语义复杂物理故障检测不足的问题，开展首项大规模实证研究，提出故障分类体系，评估多种检测方法并提炼改进洞见，同时发布相关数据集与材料。
2025-07-29 cs.AI cs.CV cs.MM
Applying Software Craftsmanship Practices to a Scrum Project: an Experience Report
软件工匠宣言定义了软件开发团队应该遵循的价值观和原则，以提供满足功能和非功能需求的高质量软件，而无需处理大量的技术债务。软件开发的软件工艺方法优先考虑技术实践，以提供干净的代码库。这项工作分析了一组实践，可以应用于一个旨在纳入软件工艺价值观的SocketProject。所描述的过程实现对于那些也打算在他们的项目中实现Software Craftsman的软件开发团队来说可能是一个有用的贡献。
2016-11-17 cs.SE
Impact Analysis of Allocation of Resources by Project Manager on Success of Software Projects
成功的软件项目的生成是软件产业的首要考虑因素之一。工程高质量的软件产品进一步受到几个因素的影响，如预算，进度，资源限制等项目经理负责估计和分配这些资源在一个项目中。因此，项目经理的角色对项目的成功有着至关重要的影响。本研究包括一个基于CMMI 5级软件公司的产品和服务开发的几个项目的实证研究。调查结果表明，上述因素对软件的成功和公司的重大影响。分析进一步指出了项目经理在优化软件开发资源分配中的重要作用。本文引入了项目经理在有效配置资源，如时间，成本，开发人员的数量等的效率的影响分析，在资源的优化配置的项目经理的效率水平的认识，使人们能够实现期望的质量水平。
2014-07-20 cs.SE
AgentFM: Role-Aware Failure Management for Distributed Databases with LLM-Driven Multi-Agents
针对分布式数据库故障管理忽视角色差异且依赖小模型的问题，本文提出LLM驱动的多智能体框架AgentFM，通过系统、数据和任务三类角色及元智能体协调实现角色感知的故障管理，并在Apache IoTDB上初步验证其有效性。
2025-04-09 cs.SE
A Survey of AIOps for Failure Management in the Era of Large Language Models
本文综述LLM时代面向故障管理的AIOps，梳理任务定义、数据源、基于LLM的方法、子任务适配方案及挑战与未来方向。
2024-06-24 cs.SE
