Cross-Dataset Design Discussion Mining
能够识别主要关于设计的软件讨论，我们称之为设计挖掘，可以改进软件系统的文档和维护。现有的设计挖掘方法使用自然语言处理（NLP）技术具有良好的分类性能，但这些方法的结论稳定性普遍较差。到目前为止，在软件项目的给定数据集上训练的分类器在不同的工件或不同的数据集上工作得不好。在这项研究中，我们复制和综合这些早期的结果在荟萃分析。然后，我们应用最近的工作在迁移学习的自然语言处理的设计挖掘的问题。然而，对于我们的数据集，这些深度迁移学习分类器的性能并不比不太复杂的分类器好。最后，我们讨论了设计挖掘的迁移学习方法背后的一些原因。
2020-01-06 cs.SE
Using Developer Discussions to Guide Fixing Bugs in Software
The University of Texas at Austin（德克萨斯大学奥斯汀分校）
自动修复软件错误是一项具有挑战性的任务。虽然最近的工作表明，自然语言上下文在指导bug修复模型方面很有用，但这种方法需要提示开发人员提供这种上下文，这是通过在bug修复代码更改后编写的提交消息来模拟的。相反，我们建议使用bug报告讨论，这在任务执行之前就可以使用，并且也是自然发生的，避免了对开发人员任何额外信息的需求。为此，我们用bug报告讨论来增加标准的bug修复数据集。使用这些新编译的数据集，我们证明了从这些讨论中派生的各种形式的自然语言上下文可以帮助修复错误，甚至可以提高性能，而不是使用对应于Oracle错误修复提交的提交消息。
2022-11-11 cs.CL cs.SE
Developer Discussion Topics on the Adoption and Barriers of Low Code Software Development Platforms
低代码软件开发（LCSD）是一种新兴的方法，可以使来自不同背景的软件从业者的应用程序开发民主化。康文署平台以拖放界面和最少的手工编程促进快速应用程序开发。由于这是一个相对较新的模式，因此研究开发商在采用康文署平台时遇到的困难至关重要。软件工程师经常使用在线开发人员论坛Stack Overflow（SO）寻求技术问题的帮助。我们观察到，在统计处，与文康署有关的职位数目不断增加。本文提出了一个实证研究，约33 K SO职位包含38个流行的康文署平台的讨论。我们使用主题建模来确定这些帖子中讨论的主题。此外，我们还研究了这些主题如何分布在敏捷软件开发生存周期（SDLC）的各个阶段，以及LCSD的哪个部分最受欢迎和最具挑战性。我们的研究提供了几个有趣的发现。首先，我们找到40个LCSD主题，我们分为五个类别：应用程序定制，数据库和文件管理，平台采用，平台维护和第三方API集成。其次，虽然应用程序定制（30\%）和数据存储（25\%）\rev{topic}类别是最常见的，但与其他几个类别（例如，平台采用\rev{topic}类别）近年来获得了相当大的关注。第三，所有主题类别都在迅速发展，特别是在新冠肺炎大流行期间。这项研究的结果对所有三个LCSD利益相关者都有影响：LCSD平台供应商，LCSD开发人员/从业人员，研究人员和教育工作者。研究人员和LCSD平台供应商可以合作改进LCSD的不同方面，…
2022-09-02 cs.SE
An Empirical Study of Developer Discussions on Low-Code Software Development Challenges
低代码软件开发（LCSD）是一种新兴的范式，它将最小的源代码与交互式图形界面相结合，以促进快速的应用程序开发。康文署的目标是让不同背景的软件从业员参与应用程序开发。鉴于康文署是一个相对较新的范例，了解开发商在采用康文署平台时面临的挑战至关重要。在线开发者论坛Stack Overflow（SO）在软件开发人员中很受欢迎，他们可以寻求技术问题的解决方案。我们观察到在SO中有越来越多的帖子讨论康文署的平台。在本文中，我们提出了一个实证研究约5K SO职位（问题+接受的答案），其中包含九个流行的康文署平台的讨论。我们在帖子上应用主题建模来确定讨论的主题类型。我们在SO中找到13个与LCSD相关的主题。这13个主题分为四个类别：定制、平台采用、数据库管理和第三方集成。超过40%的问题是关于定制的，即，开发人员经常面临定制由康文署平台提供的用户界面或服务的挑战。"自定义"类别下的"动态事件处理"主题是最受欢迎的（就该主题每个问题的平均查看次数而言），也是最困难的。这意味着开发人员经常搜索自定义解决方案，例如如何将动态事件附加到低代码UI中的表单，但他们的大多数问题（75.9%）仍然没有可接受的答案。我们从帖子中手动标记900个问题，以确定主题在康文署各阶段的挑战普遍性。我们发现大多数问题都与开发阶段有关，低代码开发人员也面临着自动化测试的挑战。
2021-03-21 cs.SE
Descriptions of issues and comments for predicting issue success in software projects
软件开发任务必须成功地执行，以达到软件质量和客户满意度。了解软件任务是否可能失败对于确保软件项目的成功至关重要。问题跟踪系统存储软件任务（问题）和评论的信息，这可能有助于预测问题的成功;然而，几乎没有关于这个主题的研究存在。这项工作研究的有用性的文字描述的问题和评论，预测问题是否会得到成功解决或不。从四个流行的问题跟踪系统中提取了588个软件项目的问题和评论。7个机器学习分类器在30 k个问题和超过120 k条评论上进行了训练，并进行了超过6000次实验，以预测三种类型问题的成功：错误，改进和新功能。结果提供的证据表明，问题和评论的描述是有用的预测问题的成功与超过85%的准确性和精确度，并随着时间的推移，问题的成功预测不同。与软件开发相关的词语与预测问题成功特别相关。其他沟通方面及其与软件项目成功的关系必须使用来自软件工具的数据进行详细研究。
2020-06-02 cs.SE
What Pulls the Strings? Understanding the Characteristics and Role of Argumentation in Open-Source Software Usability Discussions
Polytechnique Montreal（蒙特利尔高等理工学院）
研究分析了开源软件可用性讨论中论证的特点和作用，发现论证质量影响参与者行为，揭示了开源社区在可用性方面的集体智慧不足。
2025-12-08 cs.HC cs.SE
The Impact of Dynamics of Collaborative Software Engineering on Introverts: A Study Protocol
背景：自从采用敏捷方法以来，软件工程师之间通过团队中的面对面讨论进行合作得到了促进。然而，这些讨论可能会降低内向的软件工程师的贡献，可能会导致次优的解决方案，并创造有利于外向的工作环境。目的：我们的目标是评估是否为软件工程师提供单独工作的时间，并对集体问题进行推理，这是一种使内向者更舒适地进行互动和贡献的设置，最终导致更好的解决方案。方法：我们计划进行一项受试者间研究，控制组的团队在团队讨论会议中设计软件架构，治疗组的团队在参与会议之前单独工作。我们将评估和比较内向者的贡献量，他们的主观经验，以及设计的解决方案。局限性：由于外向者在两组中都存在，我们无法得出结论，更好的解决方案仅仅是由于内向者的参与增加。对他们的主观经验和捐款数额的分析可能会提供证据，说明观察到的差异的原因。
2020-04-01 cs.SE
Incivility Detection in Open Source Code Review and Issue Discussions
针对开源代码评审与Issue讨论中的不文明内容检测问题，对比6种经典机器学习模型与BERT的检测效果，评估上下文信息和跨平台场景下的性能，发现BERT最优且F1达0.95，上下文未提升其效果，跨平台场景下所有模型表现均一般。
2023-12-19 cs.SE
Untold Stories: Unveiling the Scarce Contributions of UX Professionals to Usability Issue Discussions of Open Source Software Projects
本研究分析了五个开源软件项目的数据集，发现UX专业人员在可用性问题讨论中虽参与稀缺，但能更广泛、理性地处理问题并提供事实依据与澄清，为提升社区可用性和用户满意度提供了参考。
2025-03-03 cs.HC cs.SE
Using Students as Experimental Subjects in Software Engineering Research -- A Review and Discussion of the Evidence
学生是否应该作为软件工程的实验对象？鉴于学生在许多情况下是现成的和便宜的，这是毫不奇怪的，在软件工程控制实验的绝大多数使用他们。但是，他们可以被认为是一个方便的样本，可能不代表目标人群（通常是“真正的”开发人员），特别是在经验和熟练程度方面。这使得许多研究者（和评论者）对以学生为基础的实验的外部效度持保留态度，并声称不应该使用学生。基于对将学生与专业人士进行比较的已出版作品的广泛审查，我们发现，由于两个主要原因，挑选“学生”是适得其反的。第一，按地位对实验对象进行分类，只不过是对更重要和更有意义的分类的替代，比如按能力对他们进行分类，应该努力定义和使用这些更有意义的分类。第二，在许多情况下，使用学生是完全合理的，学生的主题可以用来获得可靠的结果和进一步的研究目标。特别是，当研究涉及基本的编程和理解技能时，当比较不需要广泛学习曲线的工具或方法时，以及在大型工业研究计划的初始形成阶段-换句话说，在许多情况下，适合于有限范围的受控实验。
2015-12-28 cs.SE
Conclusion Stability for Natural Language Based Mining of Design Discussions
开发人员的讨论范围从面对面的走廊聊天到bug报告的评论链。能够识别涉及软件设计的讨论将有助于文档和重构软件。设计挖掘是机器学习技术的应用，用于正确地标记给定的讨论工件，例如拉取请求，作为与设计相关（或不相关）。在本文中，我们演示了一个简单的例子，设计挖掘的工作原理。然后，我们展示了结论的稳定性是如何在不同的工件类型和不同的项目差。我们展示了两种技术--增强和上下文特异性--可以大大提高设计挖掘的结论稳定性和跨项目相关性。我们的新方法在数据集内分类上实现了0.88的AUC，在跨数据集分类任务上实现了0.80的AUC。
2021-06-17 cs.SE
When Conversations Turn Into Work: A Taxonomy of Converted Discussions and Issues in GitHub
针对 GitHub Issue 与 Discussion 互转现象，本文实证分析 NPM 与 PyPI 仓库，提出两类转换原因分类并量化转换耗时，以完善渠道使用指南。
2023-07-14 cs.SE
TimeLess: A Vision for the Next Generation of Software Development
针对软件开发复杂性、耗时和高成本问题，提出TimeLess系统愿景，利用多AI agents在会议中实时捕捉讨论并执行开发任务，将会议转为行动导向，加速下一代软件开发。
2024-11-13 cs.SE
Detecting Discussions of Technical Debt
技术债（TD）是指软件开发过程中以牺牲长期质量为代价实现短期目标的次优选择。尽管开发人员经常非正式地讨论TD，但在大多数存储库中描述问题时，这个概念还没有具体化为一个一致应用的标签。我们应用机器学习来了解开发人员在问题跟踪器中讨论票证时对TD的见解。我们生成专家标签，指示在Chromium问题跟踪器中的1，900多个票据的样本中，与每个票据相关的自由文本中是否出现了TD的讨论。然后，我们使用这些标签来训练分类器，该分类器估计剩余475，000张票的标签。我们的结论是，TD的讨论出现在约16%的跟踪铬问题。如果我们能够有效地对与贸易和发展有关的问题进行分类，我们就可以集中精力研究哪些做法对及时解决这些问题最有用。
2022-01-28 cs.SE
Looking for related discussions on GitHub Discussions
软件团队越来越多地采用不同的工具和沟通渠道来帮助软件协作开发模型和协调任务。在这些资源中，基于编程社区的问答（PCQA）论坛已被开发人员广泛使用。这样的环境使开发人员能够获取和共享技术信息。由于对支持开源软件（OSS）项目的开发和管理感兴趣，GitHub宣布推出GitHub Discussions -一个本地论坛，以促进用户和平台上托管的社区成员之间的协作讨论。由于GitHub讨论类似于PCQA论坛，因此它面临着与此类环境类似的挑战，其中包括相关讨论的发生（重复或几乎重复的帖子）。虽然重复的帖子有相同的内容-并且可能是完全相同的副本-但近似重复的帖子共享类似的主题和信息。两者都可能给平台带来噪音，并损害项目知识共享。在本文中，我们解决了在GitHub讨论中检测相关帖子的问题。为此，我们提出了一种基于句子BERT预训练模型的方法：RD检测器。我们使用来自不同OSS社区的数据评估了RD-Detector。OSS维护人员和软件工程（SE）研究人员手动评估了RD-Detector的结果，其精度达到了75%到100%。此外，维护人员指出了这种方法的实际应用，例如合并讨论的线程并将讨论作为彼此的评论。OSS维护人员可以从RD-Detector中受益，以解决手动检测相关讨论并多次回答同一问题的劳动密集型任务。
2022-06-23 cs.CY cs.SE
Robotics Meets Software Engineering: A First Look at the Robotics Discussions on Stackoverflow
University of Manitoba（曼尼托巴大学）
研究分析StackOverflow上500个机器人相关问题，发现机器人社区规模小导致问题曝光少，且问题关注度低，但发现机器人运动和执行器等主题持续占据讨论主导地位。
2026-03-22 cs.SE
Recommending Bug-fixing Comments from Issue Tracking Discussions in Support of Bug Repair
在实践中，开发人员在面对新的bug时会搜索相关的早期bug及其相关的讨论线程。通常情况下，这些讨论线程由注释甚至bug修复注释组成，这些注释旨在捕获线索，以促进新bug报告的调查和根本原因。随着时间的推移，这些讨论可能会变得非常冗长和难以理解。不可避免的是，这些讨论线程会导致错误修复评论与不相关的评论混合在一起的情况。然而，在处理大量的错误报告时，这项任务带来了进一步的挑战。大型软件系统每天都受到数千个错误报告的困扰。因此，有效地调查这些错误报告变得非常耗时。为了解决这一差距，本文建立了一个基于排名的自动化工具，我们称之为RETRORANK。具体来说，RETRORANK建议在用户查询相关性、积极语言的使用和评论之间的语义相关性的上下文中，从问题跟踪讨论线程中修复错误的评论。通过使用向量空间模型（VSM），情感分析（SA）和TextRank模型（TR）的组合，我们展示了如何过去的固定错误和他们的相关错误修复评论相对积极的情绪可以语义连接，以调查一个新的错误的根本原因。我们通过综合研究和用户研究评估了我们的方法。结果表明，与基线VSM相比，RETRORANK显著提高了性能。
2021-05-24 cs.SE
Thinging for Software Engineers
本文的目的是促进术语thing和thinging（指的是在现实的某个部分周围定义一个边界并给它贴上名称的行为）作为有价值的概念，在软件工程建模中发挥重要作用。此外，我们试图为术语事物、对象、过程和事物提供操作定义。实质性的讨论是基于一个（抽象的）机器的概念，命名为思维机（TM），在几个研究工作中使用。TM创造、处理、接收、释放和转移事物。因此，TM的图形表示用于模拟现实。在讨论部分，本文阐明了软件工程中与概念建模相关的有趣问题。本文的内容和结论表明，思考应该更有意义地强调作为一个有价值的研究和教学课题，至少在软件开发周期的需求分析阶段。
2018-07-27 cs.SE
From Threads to Trajectories: A Multi-LLM Pipeline for Community Knowledge Extraction from GitHub Issue Discussions
The University of Texas at Dallas（德克萨斯大学达拉斯分校）
本文提出SWE-MIMIC-Bench数据集，通过多LLM管道从GitHub讨论生成问题轨迹，用于提取复杂问题的结构化知识，提升软件工程社区的协作理解与LLM训练效果。
2026-04-28 cs.SE
Predicting the Objective and Priority of Issue Reports in Software Repositories
开发人员协作讨论、实现、使用和共享托管在软件存储库上的软件实体。正确的文档在成功的软件管理和维护中起着重要的作用。用户利用问题跟踪系统（一种软件存储库工具）跟踪问题报告，管理工作量和流程，最后记录团队工作的亮点。问题报告是协作管理的软件知识的丰富来源，可以包含报告的问题，对新功能的请求，或者仅仅是关于软件产品的问题。随着这些问题数量的增加，手动管理它们变得越来越困难。GitHub提供了标记问题的标签，作为问题管理的一种手段。然而，在GitHub的前1000个存储库中，大约有一半的问题没有任何标签。我们的目标是自动化软件团队管理问题报告的过程。我们提出了一个两阶段的方法来预测背后的目标打开一个问题，它的优先级使用功能工程方法和国家的最先进的文本分类。据我们所知，我们是第一个微调Transformer以进行问题分类的公司。我们在基于项目和跨项目的环境中对模型进行训练和评估。后一种方法提供了一个通用的预测模型，适用于任何看不见的软件项目或几乎没有历史数据的项目。我们提出的方法可以成功地预测问题报告的目标和优先级，分别为82%和75%的准确率。此外，我们对六个看不见的GitHub项目中未标记的问题进行了人工标记和评估，以评估跨项目模型在新数据上的性能。该模型达到90%的准确率。我们获得85%的平均百分比协议和71%的伦道夫的自由边际Kappa转化为大量的协议之间的贴标机。
2021-09-28 cs.SE
Challenges and issues in collaborative software developments
软件开发过程相对于开发大型和复杂应用程序中的问题已经发展。现在出现了向协作发展的模式转变，因此有必要对这种做法进行评价。许多工具用于协作软件开发（CSD），包括社交媒体和Web 2.0功能。协作开发设施由IDE和项目托管网站提供。在本文中，我们提出了一个调查的合作开发的项目，并讨论在CSD的挑战和问题。我们分析了沟通，协调，支持，生命周期管理的各种问题，并讨论其对软件质量的影响。
2019-03-19 cs.SE
Developer Reactions to Protestware in Open Source Software: The cases of color.js and es5.ext
本文以 colors.js 和 es5-ext 为例，研究开源社区对抗议软件讨论的传播、接收与响应，通过主题分析684条帖子识别五类主题，揭示抗议软件讨论的复杂面貌。
2024-10-18 cs.SE
What Skills Do You Need When Developing Software Using ChatGPT? (Discussion Paper)
本研究针对当前关于LLM编程工具作用的无根据言论，通过实验发现计算思维技能可预测使用LLM工具开发软件的能力，并呼吁学界通过实验进一步明确不同场景下使用LLM开发软件所需的技能。
2023-10-09 cs.CY cs.SE
G-Issue: Analyzing Lifetime and Evolution of Issue-related Artifacts from Open Source Repositories
University of Texas at El Paso（德克萨斯大学埃尔帕索分校）
提出G-Issue工具用于挖掘问题相关工件，通过对比实验和演化分析，发现其挖掘速度快但内存消耗大，并基于问题生命周期和演化可辅助优先级排序。
2026-06-23 cs.SE
Evaluating Language Model Applications for Identifying Solution-Related Content in Issue Report Discussions
William & Mary（威廉玛丽学院）
本文利用语言模型自动识别问题讨论中的解决方案内容，通过三种应用（嵌入、提示、微调）评估不同分类器性能，发现微调大语言模型效果最佳，且模型迁移能提升其他项目的效果。
2026-03-23 cs.SE
Survey on Essential and Accidental Real-Time Issues in Software Engineering
软件产品线是近年来被认为是提高软件开发效率的最有前途的方法之一。不同的研究工作有助于支持参数和谈判的问题，产生一个完美的软件计划。传统的方法或回收软件不能有效地解决软件竞争力问题。随着软件工程在过去几年中的快速发展，研究表明，一些方法在工业界和大学都得到了广泛的关注。这种方法被归类为软件产品线改进，支持大型组织中的软件重用。不同行业正采用新产品开发的生产线，以提高效率和减少运营开支。本研究论文的目的是对软件工程的复杂性、一致性、易变性、不可见性、时间限制、预算限制和安全性等问题进行深入研究。我们通过走访不同的专业软件开发机构进行了各种调研，并从专业软件工程师那里获得反馈，分析他们在软件系统开发过程中所面临的实时的【形】问题。调查结果表明，复杂性是大多数软件开发人员在开发软件应用程序时面临的最常见的问题。此外，根据调查，隐形是很少发生的问题。
2017-03-10 cs.SE
Hybrid Work in Agile Software Development: Recurring Meetings
本文通过爱立信两部门的单案例访谈研究，揭示大规模敏捷混合办公中例行会议应按会议意图选择现场或远程形式，并给出社区会议与摄像头使用建议。
2025-03-17 cs.SE
Studying and Automating Issue Resolution for Software Quality
William & Mary（威廉与玛丽学院）
本研究通过提升issue报告质量、表征开发者工作流程和自动化解决任务，推动AI驱动的issue解决，提升软件质量。
2025-12-11 cs.SE
Characterizing Usability Issue Discussions in Open Source Software Projects
本研究通过实证分析五个开源项目中的问题讨论，揭示可用性讨论集中于效率与美学，且多由经验成员发起，并提出改进社区参与的建议。
2023-11-09 cs.HC cs.SE
Facets of Software Doping
本文提供了一个非正式的讨论软件兴奋剂的正式方面。
2018-03-27 cs.LO cs.SE
A Survey on Software Testing Techniques using Genetic Algorithm
软件行业的总体目标是确保向最终用户交付高质量的软件。为了保证软件的高质量，需要对软件进行测试。测试确保软件满足用户规范和要求。然而，软件测试领域存在许多需要解决的潜在问题，例如测试用例的有效生成、测试用例的优先级排序等。这些问题需要测试的努力，时间和成本。已经提出了不同的技术和方法来处理这些问题。利用进化算法自动生成测试一直是许多研究人员感兴趣的领域。遗传算法（GA）就是这样一种进化算法。在这篇研究论文中，我们提出了一个调查的GA方法来解决软件测试过程中遇到的各种问题。
2014-11-05 cs.SE
Understanding the Issue Types in Open Source Blockchain-based Software Projects with the Transformer-based BERTopic
本研究通过BERTopic对1,209个开源区块链项目的497,742个问题进行分析，识别出49个主题并归类为11个子类别，发现钱包问题最常见且解决最慢，机制问题解决最快，问题频率在2016年后激增、2022年后下降，为区块链软件维护提供了洞见。
2025-09-25 cs.SE
The "Shut the f**k up" Phenomenon: Characterizing Incivility in Open Source Code Review Discussions
代码评审是软件开发过程中一项重要的质量保证活动。开发人员和维护人员之间的代码审查讨论可能会很激烈，有时会涉及人身攻击和不必要的不尊重评论，因此，表现出不礼貌。虽然公共讨论中的不文明行为越来越受到不同领域研究人员的关注，但在软件开发的背景下，更具体地说，代码审查中，有关不文明沟通的特征，原因和后果的知识仍然非常有限。为了解决文献中的这一差距，我们利用成熟的社会结构的不文明作为一个镜头，以了解对抗性的冲突，在开源代码审查的讨论。为此，我们对Linux内核邮件列表（LKML）中与被拒绝更改相关的1，545封电子邮件进行了定性分析。我们发现，超过一半的66.66%的非技术性电子邮件包含不文明的功能。特别是，沮丧，辱骂和不耐烦是不文明电子邮件中最常见的特征。我们还发现，有民事替代方案来解决争论，而任何人在讨论任何话题时都可能发表不文明的评论。最后，我们确定了这种不文明沟通的各种原因和后果。我们的工作是第一个关于开源软件开发中的不文明现象的研究，为软件工程活动背景下的协作和交流研究开辟了一条新的道路。
2021-08-23 cs.HC cs.SE
Editorial: Special Issue on Collaborative Aspects of Open Data in Software EngineeringJohan
对于软件工程师来说，高质量的数据在设计和实施当今的软件时变得越来越重要，例如，作为机器学习算法和基于可视化和分析的功能的输入。开放数据-即，根据许可证共享数据，使用户有权研究、处理和向任何人分发数据，并用于任何目的-提供了一种满足这一需求的机制。数据可能来自多个来源，无论是众包、政府机构共享还是商业实体之间共享，无疑是当今公共部门、商业和工业的所有业务和收入模式所固有的。在这篇关于软件工程中开放数据协作方面的特刊的客座社论中，我们探讨了软件工程中开放数据的协作方面。我们强调这些方面如何使组织受益，可能存在哪些挑战以及如何根据当前实践解决这些问题，并介绍本特刊中包含的四篇论文。
2022-07-31 cs.SE
Communicating on Security within Software Development Issue Tracking
本研究聚焦软件开发中非安全专家使用问题追踪工具的安全沟通问题，通过界面分析和用户研究发现现有工具缺乏安全相关界面，提出加入类CVSS提问可改善安全交互。
2023-08-25 cs.SE
Strategic Issues on Implementing a Software Process Improvement Program
软件技术对全球经济和当代社会的许多部门都有很大的影响。作为一个产品，使最多样化的日常活动，软件产品必须生产反映高品质。软件质量取决于它的开发，它是基于一个大的软件开发过程集。然而，针对软件产品的软件过程的实施和持续改进应该由软件开发组织（如软件工厂、测试工厂、V&V组织等）仔细地制度化。软件过程改进计划（SPI）等计划的制度化需要战略规划，本文从特定模型和框架的角度以及基于软件过程工程模型和标准的反思来解决这一问题。此外，还提出了一套战略驱动因素，以协助实施SPI计划的战略计划，各组织在启动此类计划之前可以考虑这些战略驱动因素。
2022-01-15 cs.SE
Model based Software Develeopment: Issues & Challenges
软件设计的目标之一是以一种易于理解的方式对系统进行建模。当今软件开发的趋势正在从手工编码向自动代码生成转变，即向基于模型的方向发展。这是对软件危机的反应，在这场危机中，硬件的成本下降了，相反，软件开发的成本急剧增加。允许这种变化的方法是基于模型的，因此将人类从详细的编码中解放出来。实现这一目标还有很长的路要走，但世界各地都在努力实现这一目标。本文介绍了与建模相关的巨大变化以及在MBSD中反复出现的重要挑战性问题和技术。
2012-03-06 cs.SE
Work Issues in Software Engineering
作者利用对软件开发人员的网络调查数据，试图从公司实践和管理方面确定软件行业中“死亡行军”项目和过度工作时间的根本原因。特别强调的是业务/技术主管背景的因素。方差分析显示，这些主管组之间的显着差异，就“尖头发的老板”（PHB）的情绪指数。这种差异，结合项目失败和使用软件工程实践的PHB指数和端点之间的相关性，表明一些差异的适合性的业务背景的主管管理软件开发项目相比，他们的技术背景的同行。其他调查数据表明，提高项目管理技能是有商业背景的管理者的最大需求。
2013-03-11 cs.SE
A Versatile Dataset of Agile Open Source Software Projects
敏捷软件开发是当今开源和工业软件项目中广泛采用的实践。敏捷团队通常严重依赖问题管理工具来记录新问题并跟踪未解决的问题，此外还存储技术细节，工作量估计，开发人员分配等。以前的工作利用存储在问题管理系统中的历史信息用于各种目的;然而，当研究人员公开他们的经验数据时，它通常仅与研究目标相关。在本文中，我们提出了一个更加全面和通用的数据集，其中包含来自44个开源敏捷软件的50多万个问题的丰富信息，使其非常适合几种研究途径，以及其中的交叉分析，包括工作量估计，问题优先级，问题分配等等。我们在GitHub上公开这些数据，以便于易用性，维护性和可扩展性。
2022-02-02 cs.SE
Incivility in Open Source Projects: A Comprehensive Annotated Dataset of Locked GitHub Issue Threads
本文构建了一个包含 404 个锁定议题线程和 5961 条评论的标注数据集，用于分析开源项目中的不文明行为，并识别其常见特征、触发因素、目标和后果，为自动检测工具提供资源。
2024-02-06 cs.SE
Understanding the Characteristics of Visual Contents in Open Source Issue Discussions: A Case Study of Jupyter Notebook
大多数开源软件开发的问题跟踪系统都包括社区成员嵌入可视内容的功能，如图像和视频，以增强讨论。虽然扮演着重要的角色，有一点知识的视觉内容的特点，以支持他们的使用。为了解决这一差距，我们进行了一项实证研究，对笔记本电脑项目。我们发现，超过四分之一的问题，在笔记本电脑项目包括视觉内容。此外，在评论中有视觉内容但在问题帖子中没有的问题往往会有更长的讨论时间，并有更多的讨论者参与。在我们的定性分析中，我们在样本中确定了八种类型的视觉内容，其中约60%包括主要产品的屏幕截图或模型。我们还发现，视觉内容服务于不同的目的，触及问题和解决问题的空间。我们的努力是在开放源码软件问题讨论中全面了解视觉内容特征的重要一步。我们的研究结果提供了一些设计问题跟踪系统，以更好地促进视觉内容的使用。
2022-04-28 cs.HC cs.SE
Understanding Quantum Software Engineering Challenges An Empirical Study on Stack Exchange Forums and GitHub Issues
随着量子计算的发展，量子软件对于探索量子计算系统的全部潜力至关重要。近年来，量子软件工程（QSE）成为一个新兴的领域，受到越来越多的关注。然而，目前尚不清楚软件工程社区面临的量子计算的挑战和机遇是什么。这项工作旨在了解开发人员所感知的QSE相关挑战。我们在Stack Exchange论坛上进行了实证研究，开发人员在那里发布了QSE相关的问题和答案，Github发布了开发人员在实际量子计算项目中提出QSE相关问题的报告。基于Stack Overflow上现有的问题类型分类，我们首先对Stack Exchange论坛上提出的QSE相关问题类型进行定性分析。然后，我们使用自动化主题建模来揭示与QSE相关的Stack Exchange帖子和GitHub问题报告中的主题。我们的研究强调了QSE的一些特别具有挑战性的领域，这些领域与传统的软件工程不同，例如解释量子计算代码背后的理论，解释量子程序输出，弥合量子计算和经典计算之间的知识差距，以及相关的机会。
2022-05-06 cs.SE
Issue Auto-Assignment in Software Projects with Machine Learning Techniques
通常，软件项目中的经理或技术负责人手动分配问题。随着问题描述更加详细，此任务可能会变得更加复杂。这种复杂性也可能使该过程更容易出错（误分配）和耗时。在文献中，许多研究旨在通过使用机器学习策略来解决这个问题。虽然没有适用于所有公司的特定解决方案，但经验报告可用于指导工业自动分配项目的选择。本文介绍了一个全球性的电子公司，旨在尽量减少所花费的时间和错误，可能会出现在问题分配过程中进行的工业倡议。作为主要贡献，我们提出了一个文献综述，工业报告比较不同的算法，并在项目中吸取的经验教训。
2021-04-05 cs.SE
Repeatability, Reproducibility, Replicability, Reusability (4R) in Journals' Policies and Software/Data Management in Scientific Publications: A Survey, Discussion, and Perspectives
本文调查200篇论文与16种计算机科学期刊，分析出版政策、工件指南、软件与数据管理中的4R差距，并提出期刊政策建议及统一可复现性投稿指南。
2023-12-18 cs.SE
Practical relevance of software engineering research: Synthesizing the community's voice
软件工程（SE）研究应该与工业实践相关。自20世纪80年代以来，SE社区一直在定期讨论这个问题，由Robert Glass等先驱领导。当我们最近通过了“软件工程50年“的里程碑时，最近在这个方向上做出了一些积极的努力，例如，在几次SE会议上建立“工业”轨道。然而，许多研究人员和从业人员认为，我们作为一个社区，仍然在努力与研究的相关性和实用性。本文的目的是综合迄今为止在SE社区中关于这一主题的证据和基于经验的意见，并鼓励社区进一步反思研究相关性并采取行动。为此，我们对54个系统选择的来源（论文和非同行评审文章）进行了多声音文献综述（MLR）。MLR不是依赖和考虑每个来源中提到的关于研究相关性的个人意见，而是旨在综合和提供关于该主题的“整体”观点。我们的MLR发现的重点如下。在社区中讨论的低相关性的三大根本原因是：（1）研究人员在实践中对SE有简单化的看法（或错误的假设）;（2）缺乏与行业的联系;（3）错误识别研究问题。提高研究相关性的三大建议是：（1）使用适当的研究方法，如行动研究;（2）选择相关的研究问题;（3）与产业合作。通过综合迄今为止关于这一重要主题的所有讨论，本文旨在鼓励社区进一步讨论和行动，以加强我们的集体努力，提高研究的相关性。
2020-01-21 cs.SE
A Cross-Company Ethnographic Study on Software Teams for DevOps and Microservices: Organization, Benefits, and Issues
内容：DevOps和微服务被认为是解决当代软件需求的重要新范式，并为快速可靠的软件开发提供能力。行业报告显示，它们很快被大型软件公司采用。然而，由于技术和组织的要求，许多困难对有效地实施这两个出现在真正的软件团队。目的：本研究旨在从身临其境的角度发现使用DevOps和微服务的软件团队的组织、好处和问题。方法：在三家具有不同业务、规模、产品、客户和全球化程度的公司中进行人种学研究。这三家公司都声称他们采用了DevOps和微服务。进行了7个月（累积）的参与者观察和9次与从业者的访谈，以收集与DevOps和微服务相关的软件团队的数据。通过对档案数据的分析，运用扎根理论进行了跨公司的实证研究。结果如下：DevOps和微服务的采用带来了快速交付、能力提升和减轻负担的好处，但也出现了成本高和缺乏实践指导的问题。此外，我们的观察和访谈反映出，在软件团队中，DevOps和微服务之间的关系并不显著，这与之前研究中描述的关系不同。根据我们的研究结果，对从业人员和研究人员的四个启示进行了讨论。结论：我们的研究结果有助于从软件团队的沉浸式角度理解采用DevOps和微服务的组织，好处和问题。
2022-05-03 cs.SE
Analyzing developer discussions on EU and US privacy legislation compliance in GitHub repositories
University of Cyprus（塞浦路斯大学）；Singapore Management University（新加坡管理大学）
借助GitHub仓库中开发者问题数据，通过挖掘分析32820个问题（部分自动、部分手动），探究开源软件开发者为遵守隐私立法所讨论的问题，构建分类法助从业者、教育界和研究界应对隐私合规。
2026-07-07 cs.SE
How are Diverse End-user Human-centric Issues Discussed on GitHub?
许多软件系统无法满足社会上不同最终用户的需求，并且容易产生问题，例如可访问性和可用性问题。其中一些问题（部分）源于在软件开发过程中未能考虑不同最终用户的特性，限制和能力。我们把这类问题称为以人为中心的问题。尽管它们很重要，但对开发人员遇到的以人为中心的问题类型的理解有限。深入了解这些以人为中心的问题是设计软件系统，更好地满足其不同的最终用户的需求。本文旨在为软件开发和研究社区提供见解，其中以人为本的问题是GitHub上开发人员讨论的主题。我们进行了一项实证研究，从12个不同的项目中提取并手动分析了1，691条问题评论，从小型到大型项目，包括为有挑战性的最终用户设计的项目，例如，视障人士和有阅读障碍的人士。我们的分析表明，开发人员讨论了八类以人为中心的问题。这些包括包容性，隐私和安全性，兼容性，位置和语言，偏好，满意度，情感方面和可访问性。在我们的研究结果的指导下，我们强调了一些影响和未来可能的路径，以进一步理解和纳入以人为本的问题，在软件开发，能够设计软件，满足不同的最终用户在社会上的需求。
2022-01-15 cs.SE
The TechDebt Game -- Enabling Discussions about Technical Debt
本文设计了一款名为TechDebt的棋盘游戏，将技术债务概念具体化，并通过46名实践者的评估表明，该游戏能促进技术与非技术利益相关者之间的讨论，帮助参与者获得新见解并改变对技术债务管理的态度。
2025-02-04 cs.SE
Investigating the use of Snowballing on Gray Literature Reviews
本研究调查在灰色文献综述中对问答网站应用滚雪球法，提出基于链接和相似性的两种方法，显著增加了有效讨论的识别数量，提高了综述数据集规模。
2024-07-20 cs.SE
REAgent: Requirement-Driven LLM Agents for Software Issue Resolution
School of Computer Software, Tianjin University（天津大学计算机软件学院）；The International Joint Institute of Tianjin University, Tianjin University（天津大学国际联合学院）；HUAWEI Technologies（华为技术有限公司）
本文提出REAgent框架，通过引入问题导向的需求作为结构化任务规范，提升补丁生成准确性，实验表明其在问题解决率上平均提升17.40%。
2026-04-08 cs.SE
The Dual-Edged Sword of Technical Debt: Benefits and Issues Analyzed Through Developer Discussions
本研究通过灰色文献综述和自然语言处理技术分析2,213篇论坛帖子，识别出技术债务的8个主要主题和43个子主题，综合调查了从业者的正负面意见，揭示了TD管理中的挑战与益处。
2024-07-30 cs.SE
From Issues to Insights: RAG-based Explanation Generation from Software Engineering Artifacts
University of Cologne（科隆大学）；University of Duisburg-Essen（杜伊斯堡-埃森大学）
本文首次应用RAG方法从问题跟踪数据生成解释，实现90%的人工解释一致性，展示了结构化问题数据在提升软件系统可解释性方面的潜力。
2026-01-09 cs.SE
Issue Link Label Recovery and Prediction for Open Source Software
现代开源软件开发严重依赖问题跟踪系统来管理其功能请求、错误报告、任务和其他类似工件。这些“问题”共同构成了一个相互联系的复杂网络。问题的异质性导致链接类型的多样性，这给用户手工创建和维护链接标签带来了很大的挑战。大多数现有的自动化问题链接构造技术的目标仅限于检查问题之间的链接的存在。在这项工作中，我们专注于下一个重要的问题，我们是否可以通过数据驱动的方法自动评估问题链接的类型。我们使用问题跟踪系统分析了66个开源项目的问题和它们的标签之间的联系。使用三个项目，我们展示了有前途的结果时，使用监督机器学习分类的链接标签恢复的任务，仔细的模型选择和调整，实现F1得分0.56-0.70之间的三个研究项目。此外，当有足够的历史数据时，我们的方法用于未来链接标签预测的性能是令人信服的。我们的工作标志着系统地管理和维护实践中面临的问题环节的第一步。
2021-08-10 cs.SE
