Building Bridges: Establishing a Dialogue Between Software Engineering Research and Computational Science
计算科学与工程（CSE）社区对参与软件工程研究（软件系统及其开发，操作和维护的系统研究）以解决科学软件开发中的挑战越来越感兴趣。从历史上看，科学计算和该领域之间几乎没有互动，这阻碍了进步。随着科学软件团队的队伍扩大到包括软件工程研究人员和实践者，我们可以努力建立通往软件科学的桥梁，并在软件开发中获得基于证据的实践的回报。
2022-01-11 cs.CE cs.SE
A Quantitative Study of Java Software Buildability
研究人员、学生和从业人员经常遇到第三方软件系统的构建过程失败的情况。在本文中，我们的目的是证实这一观察目前主要是作为轶事证据。使用模拟程序员的虚拟环境，我们尝试从超过7，200个开源Java项目的源代码中完全自动地构建目标归档。我们发现超过38%的构建以失败告终。构建日志分析显示，大部分错误都与依赖性相关。我们还对影响构建成功的因素进行了关联研究。
2017-12-04 cs.PL cs.SE
An Exploratory Study of V-Model in Building ML-Enabled Software: A Systems Engineering Perspective
本文从系统工程视角探索V模型在构建机器学习使能系统中的应用，通过从业者访谈提出8条命题，发现V模型特性能有效应对跨学科协作挑战，并建议未来研究利用其系统分解、清晰边界和V&V一致性开发新过程模型与工具。
2024-05-05 cs.SE
A Benchmark for Language Models in Real-World System Building
Peking University（北京大学）；Nankai University（南开大学）；Microsoft（微软）；Tsinghua University（清华大学）
本文提出一个面向现实世界系统构建的语言模型基准，用于评估跨不同架构和语言的软件包构建修复能力，揭示了该领域仍需进一步改进的挑战。
2026-01-19 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
Software Architecture Overview
什么是软件架构？帮助构造、构建和测试一个重要软件的规则、范例和模式。它是抽象层次上的实践经验。软件架构建立在系统工程和伽利略建立的科学方法之上：测量你能测量的，使你不能测量的。实验比推理更重要。关于软件架构的信息片段遍布互联网。本文尽可能多地使用引文。其目的是汇集一个概览，而不是重新措辞。
2005-07-24 cs.SE
Building Living Software Systems with Generative & Agentic AI
该观点论文提出以生成式 AI 和智能体 AI 构建可动态演化的“有生命软件系统”，弥合人类意图与计算操作之间的鸿沟。
2024-08-03 cs.SE
CXXCrafter: An LLM-Based Agent for Automated C/C++ Open Source Software Building
本研究提出CXXCrafter，一种基于LLM的智能体，用于自动化C/C++项目构建，通过实证分析识别挑战并解决依赖管理等问题，在开源软件上达到78%的构建成功率。
2025-05-27 cs.SE
Building Confidence in Scientific Computing Software Via Assurance Cases
保证案例为正确性提供了一个有组织的、明确的论证。它们可以显著提高科学计算软件（SCS）的认证。保证案例已经被有效地用于实时的系统的安全案例。SCS的优势包括吸引领域专家，仅生成必要的文档，并提供可以验证/复制的证据。本文通过3dfim+（一种用于分析大脑活动的现有医学成像应用程序（MIA））的正确性案例说明了SCS的保证案例。选择这个例子的部分原因是最近对功能性磁共振成像（fMRI）研究有效性的担忧。该示例证明了SCS保证案例的价值，因为现有文档显示存在模糊性和遗漏，例如定义不完整的排名功能和缺少坐标系的详细信息。确定了3dfim+的一个严重问题：运行该软件不会产生任何警告，说明必须使用与相关性计算所用参数统计模型相匹配的数据。一般而言，提高SCS的标准，特别是MIA，既可行又必要-当软件影响安全性时，应采用保证案例方法（或同等严格的置信度建立方法）。
2019-12-31 cs.SE
OmniBOR: A System for Automatic, Verifiable Artifact Resolution across Software Supply Chains
本文提出OmniBOR系统，通过构建制品依赖图追踪软件依赖，结合编译器和构建追踪两种实现方式，有效支持CVE检测与SBOM计算，保障软件供应链安全。
2024-02-14 cs.CR cs.SE
Building a Secure Software Supply Chain with GNU Guix
软件供应链正在成为一个广泛的类比，以指定从开发人员发布的源代码到用户运行的可执行程序所采取的一系列步骤。电脑这些步骤中的任何一个安全漏洞都会使用户面临风险，有证据表明，对供应链的攻击变得越来越普遍。在一个依赖于许多相互关联的软件系统的社会中，对软件供应链的攻击可能会造成悲惨的后果，这导致了对供应链安全的研究兴趣和政府激励措施的增加。GNU Guix是一个软件部署工具和软件发行版，支持出处跟踪、可复制的构建和可复制的软件环境。与许多软件发行版不同，它完全由源代码组成：它提供了一组描述如何从源代码构建代码的包定义。这些属性使它与许多以分发二进制文件为中心的部署工具区别开来。本文主要讨论一个研究问题：Guix和类似的系统如何允许用户安全地更新他们的软件？Guix源代码使用Git版本控制系统分发;更新Guix安装的软件包意味着首先更新Guix源代码的本地副本。以前关于安全软件更新的工作主要集中在与Guix非常不同的系统上--如Debian、Fedora或PyPI，其中更新包括获取有关最新二进制工件的元数据--并且在Guix的上下文中基本上不适用。相比之下，Guix的主要威胁是对其源代码存储库的攻击，这可能导致用户运行不真实的代码或降级他们的系统。从Nix到Portage，与Guix更相似的部署工具要么缺乏安全的更新机制，要么存在缺陷。我们的主要贡献是一个模型和工具来验证新的Git版本。我们…
2022-06-28 cs.PL cs.SE
An Approach to Build Consistent Software Architecture Diagrams Using Devops System Descriptors
系统架构图在理解系统架构方面起着至关重要的作用。它们鼓励参与者之间进行更积极的讨论，并使回忆系统细节变得更容易。然而，系统架构图往往偏离软件。因此，它们可能会干扰对软件的理解和维护。我们提出了一种使用DevOps系统描述符构建系统架构图的方法，以提高架构图的一致性。为了产生我们的方法，我们调查了软件行业中架构图的问题，制定了创建架构图的指导方针。接下来，我们为系统描述符概念和将系统描述符转换为体系结构图的过程生成一个分类法。我们通过案例研究来评估我们的方法。在本案例研究中，我们为一个新闻源系统定义了一个Docker Compose描述符，并使用所提出的方法将其转换为一个系统架构图。我们的研究结果表明，目前，系统描述符通常导致一致的图只有在有限的程度。然而，案例研究的观察表明，所提出的方法是有前途的，并表明系统描述符有潜力创建更一致的架构图。为了更详细地检验我们的假设，有必要在控制实验和经验实验中进行进一步的评估。
2022-10-21 cs.SE
Building Your Own Product Copilot: Challenges, Opportunities, and Needs
本研究通过访谈26名软件工程师，揭示了构建产品副驾驶在工程各环节的痛点与挑战，并借助头脑风暴提出面向软件工程社区的机遇和工具设计方向。
2023-12-21 cs.SE
Fairway: A Way to Build Fair ML Software
机器学习软件正越来越多地用于做出影响人们生活的决策。但有时候，这个软件的核心部分（学习模型）会以一种有偏见的方式表现出来，给特定群体带来不必要的优势（这些群体是由性别、种族等决定的）。人工智能软件系统中的这种“算法歧视”已经成为机器学习和软件工程社区严重关注的问题。在软件系统中，已经有一些工作是为了发现“算法偏见“或“伦理偏差”。一旦在人工智能软件系统中检测到偏差，减轻偏差就非常重要。在这项工作中，我们a）解释训练数据中的地面真实偏差如何影响机器学习模型的公平性以及如何在AI软件中发现这种偏差，b）提出一种结合预处理和处理方法的方法Fairway，以消除训练数据和训练模型中的道德偏见。我们的研究结果表明，我们可以在学习模型中发现偏差并减轻偏差，而不会对该模型的预测性能造成太大损害。我们建议（1）测试偏差和（2）偏差缓解应该是机器学习软件开发生存周期的常规部分。Fairway为这两个目的提供了很多支持。
2020-10-06 cs.SE
Software (Re-)Engineering with PSF II: from architecture to implementation
本文介绍了PSF在软件工程和再工程领域的应用研究。我们建立了一个新的实现的PSF工具包的模拟器从一个简单的模拟器的体系结构的PSF规格开始，并扩展它的功能，以获得一个完整的模拟器的体系结构。我们对体系结构的规范应用精炼和约束技术，以获得足够低的规范来构建实现。
2007-12-19 cs.SE
Kettle: Attested builds for verifiable software provenance
Kettle是一种可验证软件来源的构建系统，通过可信执行环境生成加密可验证的来源信息，减少验证时对构建基础设施和分发渠道的信任需求。
2026-05-08 cs.CR cs.SE
Reduce, Reuse, Recycle: Building Greener Sustainable Software
针对软件开发中常被忽视的能耗问题，本文分析基础软件操作的能源影响，证明通过能源意识的编程决策可实现显著节能并推动绿色可持续软件。
2023-11-03 cs.PF cs.SE
Lila: Decentralized Build Reproducibility Monitoring for the Functional Package Management Model
Institut Polytechnique de Paris（巴黎理工学院）
Lila是一个面向功能包管理模型的去中心化系统，用于解决大规模构建可重复性监控问题，通过分布式报告和数据库聚合提升软件分发的透明性和信任。
2026-01-28 cs.SE
BuildBench: Benchmarking LLM Agents on Compiling Real-World Open-Source Software
Arizona State University（亚利桑那州立大学）
针对现有OSS编译基准评估不足，提出包含多样化项目的BUILD-BENCH基准及OSS-BUILD-AGENT智能体，通过增强指令检索实现最先进性能，为复杂编译任务提供评估与指导。
2026-09-18 cs.AI cs.PL cs.SE
Idiomatic and Reproducible Software Builds using Containers for Reliable Computing
容器作为应用程序交付的单元是软件开发世界中的“下一件大事”。它们使开发人员能够创建一个可执行映像，其中包含与所有依赖项捆绑在一起的应用程序，用户可以在具有虚拟化资源的受控环境中运行该应用程序。关键业务应用程序和研究环境的复杂工作流程需要高度的可重复性，这可以使用唯一标识的图像作为计算单元来实现。在这篇论文中，最广泛使用的方法来创建一个图像从预先存在的软件或从源代码缺乏能力，提供idiomaticity在他们使用的技术，以及适当的再现性保障。在第一部分中，现有的方法进行了形式化和讨论，并介绍了一种新的方法。然后使用一套三个不同的例子的方法进行评估。本文提供了一个框架，正式涉及分层文件系统，容器和图像的操作，和一种新的方法来创建图像使用实用工具容器和层穿上满足idiomativity和再现性标准。
2017-02-09 cs.SE
Modern Software Development for JUNO offline software
针对JUNO离线软件长期维护与在线部署等挑战，本文提出基于Git、GitLab、CMake、Docker和Kubernetes的现代开发系统，实现构建简化、环境控制、部分检出、CVMFS部署及持续集成。
2023-09-25 cs.SE physics.ins-det
Build It, Break It, Fix It: Contesting Secure Development
典型的安全竞赛侧重于破坏或减轻有缺陷的系统的影响。我们提出了Build-it Break-it Fix-it BIBIFI竞赛，旨在评估安全构建软件的能力，而不仅仅是破坏它。在BIBIFI中，团队构建指定的软件，目标是最大限度地提高正确性、性能和安全性。当团队试图破坏其他团队的提交时，后者会被测试。优胜者是从最好的建设者和最好的破坏者中选出的。BIBIFI的设计是开放式的-团队可以使用任何他们喜欢的语言、工具、流程等。因此，竞赛结果揭示了与成功构建安全软件和破解不安全软件相关的因素。在此期间，我们进行了三场比赛，涉及到两个不同的编程问题。这些竞赛的定量分析发现，最有效的构建提交使用CC，但以静态类型语言编码的提交不太可能有安全漏洞，具有不同编程语言知识的构建团队也产生了更安全的代码。较短的课程与较好的成绩相关。同时也是构建团队的突破团队在发现安全漏洞方面明显更好。
2016-08-19 cs.CR cs.SE
Causes and Canonicalization of Unreproducible Builds in Java
KTH Royal Institute of Technology（瑞典皇家理工学院）
本文针对Java软件构建不可复现问题，提出六类根因分类法，并开发Chains-Rebuild工具，在12,803个制品上实现26.60%的规范化成功率。
2025-11-10 cs.SE
Mining Software Metrics from Jazz
在本文中，我们描述了提取的源代码度量从Jazz存储库和应用程序的数据采掘技术，以确定最有用的这些指标预测的成功或失败的尝试构建一个工作实例的软件产品。我们目前的结果，从一个系统的研究，使用J48分类方法。结果表明，我们认为只有相对较少的可用软件度量对预测构建的结果有意义。这些重要的指标进行了讨论，并讨论了结果的影响，特别是能够预测失败的构建尝试的相对困难。
2014-07-09 cs.SE
On the Interplay between Non-Functional Requirements and Builds on Continuous Integration
持续集成（CI）意味着整个开发团队在软件项目的主线上一起工作。CI系统自动化软件的构建。有时开发人员签入代码，这会中断构建。一个损坏的构建本身可能不是问题，但它有可能扰乱同事，因此它会影响团队的性能。在这项研究中，我们调查了1,283个软件项目的非功能需求（NFR）和构建状态之间的相互作用。我们发现NFR相关构建状态之间存在显着差异。因此，可以提出一些工具来改进CI，重点是防止CI失败的新方法，特别是与效率和可用性相关的构建。此外，将中断的构建恢复到正常状态所需的时间表明，所有NFR都呈双峰分布，一天内的峰值较高，六周内的峰值较低。我们的研究结果表明，Ruby的可维护性和Java的功能性和可靠性的计划时间表将减少与中断构建相关的延迟。
2017-03-29 cs.SE
Unlocking Reproducibility: Automating re-Build Process for Open-Source Software
针对开源软件供应链中二进制与源代码脱节的安全风险，本文扩展Macaron框架，自动化从源代码重建Maven构件，改进源代码检测与构建规范提取，并分析构建失败根因，提升供应链安全与透明度。
2025-09-10 cs.CR cs.SE
Does Functional Package Management Enable Reproducible Builds at Scale? Yes
LTCI, Télécom Paris Institut Polytechnique de Paris（巴黎电信学院，巴黎理工学院）
本文通过大规模研究Nix功能包管理器，验证了大规模可重复构建的可行性，发现位级可重复性率高达69%-91%，重新构建率超过99%。
2025-05-07 cs.SE
The Devil Is in the Command Line: Associating the Compiler Flags With the Binary and Build Metadata
针对编译器标志不一致引发软件缺陷的问题，提出构建可查询数据库以结构化跟踪编译和链接过程，从而更早检测缺陷并减少调试时间。
2023-12-20 cs.SE
On the Interaction between Software Engineers and Data Scientists when building Machine Learning-Enabled Systems
本文通过探索性案例研究，揭示软件工程师与数据科学家在ML赋能系统构建中的协作挑战，并提出促进协作的解决方案，以改善跨角色交互。
2024-02-08 cs.SE
IsiSPL: Toward an Automated Reactive Approach to build Software Product Lines
在过去的几十年里，软件产品线（SPL）已经证明了系统重用对于提高软件开发生产力和软件产品质量的好处。在三种采用方法中，即提取式、主动式和反应式，反应式方法似乎最适合于实践中的软件开发。这种方法的优点在于它仍然接近经典的软件开发实践。事实上，它避免了对业务领域及其可变性的完整分析（即主动方法），也避免了需要一组覆盖该领域的产品变体（即提取方法）。然而，尽管有这些优点，我们认为，采用反应式方法的主要障碍是其重新设计过程缺乏自动化。本文提出了isisSPL：一种基于反应的方法，有利于建设和维护的SPL。SPL的构建基于准自动过程。SPL的维护可以在由isiSPL生成的白盒SPL实现上进行。isisSPL基于两个步骤：第一，识别新创建产品的人工制品并将其整合到SPL的结构中;第二，选择一组人工制品及其组成，以生成可以部分或完全满足开发人员预期产品要求的新产品。我们已经实现了isiSPL，并使用ArgoUML-SPL和Soduko-SPL的两组不同产品验证了其集成和生成。
2021-07-16 cs.SE
Build Code is Still Code: Finding the Antidote for Pipeline Poisoning
University of Central Florida（中佛罗里达大学）
本文提出开发阶段隔离策略，通过将构建系统建模为程序代码以增强其抗污染能力，并展示了Foreman工具在检测XZ Utils攻击中的有效性。
2026-01-13 cs.SE
Characterizing Build Compromises Through Vulnerability Disclosure Analysis
本文通过大规模CVE挖掘和供应链攻击分析，提出并验证了针对软件构建过程的攻击向量分类法，揭示了23.8%的供应链攻击利用构建漏洞，为防御设计提供系统理解。
2025-11-03 cs.SE
High Level Hardware/Software Embedded System Design with Redsharc
随着用于设计多处理器片上系统（MPSoC）的工具继续发展以满足开发人员的需求，存在必须被弥合以提供更紧密的硬件/软件开发环境的系统性差距。我们提出Redsharc来解决这些问题，并使：系统生成，软件/硬件编译和合成，运行时控制和执行的MPSoC。本文中提出的努力扩展了我们以前的工作，提供了丰富的API，构建基础设施和运行时，使开发人员能够设计一个系统，同时执行内核的软件或硬件，无缝通信。在这项工作中，我们进一步采用Redsharc，以支持更多设备上的更广泛的应用程序，这些设备需要更统一的系统开发环境和构建基础设施。为了实现这一目标，我们利用现有的工具，并通过构建和控制基础设施扩展Redsharc，以减轻系统开发的负担，使软件程序员能够将精力集中在应用程序和内核开发上。
2014-08-20 cs.DC cs.SE
Maximizing Patch Coverage for Testing of Highly-Configurable Software without Exploding Build Times
针对Linux内核补丁测试中现有配置方案构建耗时长且难保证补丁覆盖的问题，提出krepair方法，仅对快速构建但补丁覆盖差的配置做少量修改，即可实现平均98.5%的补丁覆盖率，同时保持构建速度比最大覆盖配置快10.5倍。
2024-04-27 cs.SE
Structure Editor for Building Software Models
针对 Alloy 新手近三分之一模型编译失败的问题，本文提出基于块输入的 Alloy 结构编辑器概念验证，以从设计上消除编译错误。
2024-06-13 cs.SE
Prompts Are Programs Too! Understanding How Developers Build Software Containing Prompts
Carnegie Mellon University（卡内基梅隆大学）
本文通过访谈20名开发者，提出提示词编程概念，发现其与传统软件开发不同，开发者难以建立可靠心智模型，为提示词工具开发提供启示。
2025-04-25 cs.AI cs.HC cs.SE
Probabilistic Software Modeling
软件工程和软件的实现已经成为一项具有挑战性的任务，因为许多工具，框架和语言必须协调成一个功能块。这种复杂性增加了对测试和分析方法的需求，这些方法可以在软件增长和发展时帮助开发人员和工程师。公司用于测试和分析的预算资源是有限的，这突出了自动化对经济软件开发的重要性。我们提出了概率软件建模，软件建模的一个新的范例，建立在这样一个事实，即软件是一个易于监控的环境，统计模型可以建立。概率软件建模在不改变抽象层次的情况下为工程师提供了更多的理解。该方法依赖于面向对象编程的递归分解原理来构建概率模型的层次结构，该概率模型通过在软件系统的运行时收集的观察来拟合。这导致了一个模型网络，它反映了软件系统的静态结构，同时对其动态运行时行为进行建模。由此产生的模型可以用于测试用例生成，异常和离群值检测，概率程序模拟，或状态预测等应用。理想情况下，概率软件建模允许使用软件的整个统计建模和推理范围，从而实现软件的深入分析和生成过程。
2018-06-26 cs.SE
Building Better Quality Predictors Using "$ε$-Dominance"
尽管有广泛的研究，许多方法在软件质量预测仍然表现出一定程度的不确定性，在他们的结果。而不是把这作为一个问题，本文问，如果这种不确定性是一种资源，可以简化软件质量预测。例如，Deb的$ε$ -优势原则指出，如果存在某个$ε$值，低于该值就无法区分结果，那么探索任何小于$ε$的值都是多余的。我们说，对于“大型$ε$问题”，学习的结果空间有效地包含几个区域。如果将许多学习器应用于这样的大型$ε$问题，它们将表现出“条条大路通罗马”的特性;即，许多不同的软件质量预测方法会产生一小部分非常相似的结果。本文探讨DART，特别是选择成功的大型$ε$软件质量预测问题的算法。DART是非常简单的，但在实验中，它显着优于三套最先进的缺陷预测方法。DART在缺陷预测方面的成功引出了一个问题：软件质量预测中有多少其他领域也可以从根本上简化？这将是今后工作富有成果的方向。
2018-03-13 cs.SE
Rethinking Build vs. Buy Decisions in Enterprise Software: Navigating Trade-offs through a Structured Decision-Support Approach
Accenture Inc.（埃森哲）
针对企业软件自建与采购决策的复杂性，提出一种基于本体因素模型、规则推理和参考匹配的结构化决策支持方法，并通过金融案例验证其能提升决策质量、透明度和可审计性。
2026-06-29 cs.SE
PhantomRun: Auto Repair of Compilation Errors in Embedded Open Source Software
Ericsson AB（爱立信公司）；KTH Royal Institute of Technology（皇家理工学院）；Carleton University（卡尔顿大学）；Mälardalen University（马拉达伦大学）
PhantomRun利用大型语言模型自动修复嵌入式开源软件的编译错误，成功修复了45%的CI失败案例。
2026-02-23 cs.SE
RADICAL-Cybertools: Middleware Building Blocks for Scalable Science
RADICAL-Cybertools（RCT）是一组软件系统，作为中间件为科学计算开发高效和有效的工具。具体而言，RCT能够在极端规模和各种计算基础设施上执行多任务应用程序。RCT是构建块，设计为作为独立系统工作，相互集成或与第三方系统集成。RCT在多个领域实现创新科学，包括但不限于生物物理学、气候科学和粒子物理学，消耗数亿核心小时。本文概述了RCT系统、它们的影响、体系结构原则和RCT基础的软件工程
2019-04-05 cs.SE
Can Language Models Go Beyond Coding? Assessing the Capability of Language Models to Build Real-World Systems
Nankai University（南开大学）；Haihe Laboratory of Information Technology Application Innovation（海河信息技术应用创新实验室）；Key Laboratory of Data and Intelligent System Security, Ministry of Education（教育部数据与智能系统安全重点实验室）；Tianjin Key Laboratory of Software Experience and Human Computer Interaction（天津市软件体验与人机交互重点实验室）；Tsinghua University（清华大学）
本文提出Build-bench基准，评估语言模型在跨指令集架构迁移中修复构建失败的能力，发现当前模型最大成功率为63.19%，并揭示了不同模型在工具使用上的差异。
2026-05-08 cs.SE
Continuous Defect Prediction: The Idea and a Related Dataset
我们想介绍我们的连续缺陷预测（CDP）研究的想法以及我们创建和共享的相关数据集。我们的数据集目前是一组超过1100万个数据行，代表持续集成（CI）构建中涉及的文件，这些文件将CI构建的结果与我们从软件存储库中挖掘的数据相结合。我们的数据集包含1265个软件项目，30，022个不同的提交作者和几个软件过程度量，这些度量在早期的研究中似乎对软件缺陷预测有用。在这个特定的数据集中，我们使用TravisTorrent作为CI数据的来源。TravisTorrent综合来自Travis CI服务器和GitHub开源项目存储库的提交级别信息。我们将此数据扩展到文件更改级别，并计算可用于的软件过程度量，例如，作为预测风险软件更改的功能，这些更改如果提交到启用CI的存储库中，可能会破坏构建。
2017-06-22 cs.SE
Mutating the "Immutable": A Large-Scale Study of Git Tag Alterations
Télécom Paris, Institut Polytechnique de Paris（巴黎电信学院，巴黎理工学院）
通过分析3.284亿软件仓库，发现1020万次标签变更影响18.9万仓库，并与Nixpkgs交叉验证表明标签变更导致可重现构建失败，建议使用加密提交哈希固定依赖并建立审计日志。
2026-07-01 cs.SE
Can I use this publicly available dataset to build commercial AI software? -- A Case Study on Publicly Available Image Datasets
Centre for Software Excellence, Huawei Canada（华为加拿大卓越软件中心）；Lassonde School of Engineering, York University（约克大学拉松德工程学院）；Huawei China（华为中国）；University of Victoria（维多利亚大学）
公开可用的数据集是商业AI软件的关键驱动力之一。公开数据集的使用受数据集许可证的约束。这些数据集许可证概述了一个人对给定数据集享有的权利，以及在不违反任何许可证合规性的情况下享有这些权利所必须履行的义务。与标准化的开源软件（OSS）许可证不同，现有的数据集许可证是以临时方式定义的，并且没有明确概述与其使用相关的权利和义务。此外，公共数据集可以被托管在多个位置中并且从多个数据源创建，每个数据源可以具有不同的许可证。因此，不能使用检查OSS许可证合规性的现有方法。在本文中，我们提出了一种新的方法来评估潜在的许可证合规违规行为，如果一个给定的公开数据集被用于构建商业AI软件。我们使用我们的方法对6个常用的公开图像数据集进行了案例研究。我们的研究结果表明，如果将所有研究的数据集用于商业目的，则存在违反许可证的潜在风险。
2022-04-11 cs.AI cs.LG cs.SE
On the Costs and Benefits of Adopting Lifelong Learning for Software Analytics -- Empirical Study on Brown Build and Risk Prediction
本文实证评估了在育碧工业场景中采用终身学习持续更新软件分析模型的效果，证明其相比从头再训练可在保持性能的同时大幅降低计算成本。
2024-02-12 cs.SE
Requirements Engineering Challenges in Building AI-Based Complex Systems
本文识别和解决的挑战时，应用于开发基于人工智能的复杂系统的需求工程学科。由于其复杂的行为，迫切需要为此类系统量身定制的开发过程。然而，仍然没有广泛使用的和专门定制的过程来有效且高效地处理适合于指定使用机器学习的软件解决方案的要求。通过分析软件工程和人工智能领域的相关工作，认识到基于Agent的软件工程和面向目标的需求工程研究以及大型产品开发公司的例子的潜在贡献。对这些挑战进行了讨论，并提出了如何以及何时应对这些挑战的建议。还概述了RE4AI分类，以告知开发过程的裁剪。
2019-08-30 cs.SE
Evolution of ROOT package management
ROOT是一个庞大的代码库，具有一组复杂的构建时依赖关系; ROOT的“核心”和全面部署之间的编译时间有很大的差异。我们目前的内部ROOT包和外部包的“延迟构建”的结果。这使得能够提供一个“轻量级”的ROOT核心，随后通过构建额外的模块来扩展ROOT的功能。作为这项工作的一部分，我们改进了将ROOT代码分离为具有最小依赖性的不同模块和包。这种方法为用户提供了更好的灵活性，并且可以组合各种构建功能，而无需从头开始重新构建。依赖性是软件中，特别是HEP软件生态系统中常见的问题。我们想讨论工件管理（“延迟安装”）系统的改进，作为“依赖地狱”问题的解决方案。HEP软件栈通常由多个具有依赖关系的子项目组成。开发模式往往是分散的，独立的和不连贯的子项目。我们认为，软件的设计应利用现有的其他软件组件，或已设计和实施用于其他地方的软件组件，而不是“重新发明轮子”。在我们的贡献中，我们将介绍我们的方法与一组示例和用例一起ROOT的工件管理系统。
2019-06-11 cs.SE
Local Software Buildability across Java Versions (Registered Report)
本研究通过抽样 2,500 个 GitHub 纯 Java 项目，在 Java 6 至 23 版本下自动构建，实证验证构建失败比例随 Java 版本升高而增长，并探究相关因素。
2024-08-21 cs.PL cs.SE
Reproducibility of Build Environments through Space and Time
针对软件依赖增多导致构建环境难复现的问题，本研究提出函数式包管理器可实现跨时空的构建环境复现，实验验证了其可复现约700万Nix包，对6年前的Nixpkgs修订版中1.4万包的重建成功率达99.94%。
2024-02-01 cs.SE
Realigning Incentives to Build Better Software: a Holistic Approach to Vendor Accountability
本文针对商业软件安全质量不足的问题，提出以软件责任为核心、整合法律、技术与金融机制的整体性技术和政策框架，并结合欧盟环境、OSS、AI 风险及 CrowdStrike 案例分析其作用。
2025-06-10 cs.CR cs.SE econ.TH
Built to Last or Built Too Fast? Evaluating Prediction Models for Build Times
自动化构建是持续集成（CI）软件开发实践的组成部分。在CI中，鼓励开发人员尽早并经常进行集成。然而，当集成频繁时，长的构建时间可能是一个问题。这项研究的重点是在经常集成和保持开发人员的生产力之间找到平衡。我们提出并分析模型，可以预测一个工作的构建时间。这些模型可以帮助开发人员更好地管理他们的时间和任务。此外，项目经理可以探索不同的因素，以确定构建作业的最佳设置，从而将构建等待时间保持在可接受的水平。过渡到CI实践的软件组织可以在实施CI之前使用预测模型来预测构建时间。研究界可以修改我们的预测模型，以进一步了解影响构建时间的因素和关系。
2017-12-19 cs.SE
Continuous Integration Theater
背景：持续集成（CI）系统现在是一些软件开发实践的基础。一些工具，如TravisCI，CircleCI和Hudson，实现CI实践，通常被软件工程师采用。然而，软件工程师使用这些工具的方式可能会导致我们所说的“持续集成剧场”，即软件工程师不能有效地使用这些工具，从而导致不健康的CI实践。目的：本文的目标是了解这些不健康的持续集成实践在实践中的普遍程度。方法：通过检查1，270个使用TravisCI（最常用的CI服务）的开源项目，我们定量研究了使用CI的常见程度（1）不频繁提交，（2）在测试覆盖率差的软件项目中，（3）长期保持中断的构建，以及（4）运行时间过长的构建。结果：我们观察到748个（$sim$ 60%）项目面临不频繁的提交，这基本上使合并过程更加困难。此外，我们能够找到51个项目的代码覆盖率信息。平均代码覆盖率为78%，尽管Ruby项目的代码覆盖率高于Java项目（分别为86%和63%）。然而，我们也发现了一些覆盖率非常小的项目（$sim$ 4%）。尽管如此，我们观察到85%的研究项目至少有一个损坏的构建，需要超过四天的时间才能修复。有趣的是，非常小的项目（多达1,000行代码）是修复损坏的构建所需时间最长的项目。最后，我们注意到，对于大多数被研究的项目，构建都是在10分钟的经验法则下执行的。结论：我们的研究结果是很重要的软件工程师越来越多的社区，采用CI的做法，每天的基础…
2019-07-02 cs.SE
LaForge: Always-Correct and Fast Incremental Builds from Simple Specifications
开发人员依靠构建系统从代码生成软件。至少，构建系统应该从代码的干净副本中生成构建目标。但是，开发人员很少从干净的签出工作。相反，他们会重复地重建软件，有时一天要重建数百次。为了保持快速重建，构建系统以增量方式运行，仅在无法重用构建状态时才执行命令。现有的工具，如使目前的用户与权衡。简单的构建规范很容易编写，但限制了增量工作。更复杂的构建规范产生更快的增量构建，但是编写它们是劳动密集型的并且容易出错。这项工作表明，没有这样的权衡是必要的;构建规范可以既简单又快速。我们介绍LaForge，一种新颖的构建工具，它消除了指定依赖关系或增量构建步骤的需要。LaForge构建很容易指定;开发人员编写一个简单的脚本来运行完整的构建。即使是像gcc src/*.c这样的命令也足够了。LaForge跟踪构建的执行并生成TraceIR语言的记录。在以后的构建中，LaForge会评估TraceIR记录以检测更改并执行高效的增量重建，自动捕获所有构建依赖项。我们通过构建14个软件包来评估LaForge，包括LLVM和memcached。我们的研究结果表明，LaForge自动生成高效的构建从简单的构建规范。与项目的默认完整构建相比，LaForge的完整构建的平均开销为16.1%。LaForge的增量构建始终运行更少的命令，并且大多数比手动指定的增量构建花费不到3.08秒的时间。最后，LaForge总是正确的…
2021-09-02 cs.PL cs.SE
