Anmol Bilal

dblp:381/3408 · DBLP profile ↗
← Back
3ranked-venue papers
2as first author
3since 2021 · last 2025
0009-0005-4443-5166ORCID · corroborated

Domains — the database's venue-derived domains; a paper can count in several

Software engineering, systems software and programming languages · 3 · 2 first-author · 3 since 2021
YearPublicationVenuePosition
2025 Ranking guidance actions to support engineers in fulfilling process constraints
abstract
Abstract In safety‐critical systems engineering, regulations such as Automotive SPICE, ISO26262, or ED‐109A mandate software quality assurance measures to provide evidence that the developed system is high quality. The constraints that define quality assurance conditions during the engineering life cycle are often non‐trivial. This paper addresses the challenges, engineers face who are unfamiliar with the precise constraints of various projects (e.g., when newly joining a company or switching between departments). Understanding how to fulfill a constraint is a time‐consuming and challenging task as an engineer needs to determine the most suitable option (out of potentially many) to fulfill a constraint violation. To this end, we propose a guidance action ranking framework to provide engineers with the most relevant guidance actions. Our primary ranking algorithm analyzes in the background the actions that engineers have made in the past to resolve a constraint violation without requiring explicit feedback from them. We evaluated our framework on two real‐world data sets: an open‐source drone management and an industrial air traffic control software system. Concretely, we replay past engineering activities and measured whether, in the case of a constraint violation, our suggested guidance actions were indeed selected by the engineer. The evaluation results revealed that learning from prior guidance actions effectively identifies the most appropriate guidance actions (ranked top 1 or 2) when compared to ranking algorithms based on action simplicity and artifact property change frequency. Specifically, we achieve a median MRR of 0.95 for the first case study and 0.94 for the second case study: an improvement of 80% and 100% over the baseline. Additionally, we observed that the simplicity of a guidance action does not reliably indicate its suitability for fulfilling a constraint, whereas learning from prior change operation property out‐performed simplicity‐based ranking but did not surpass guidance frequency‐based ranking.
Anmol Bilal, Christoph Mayr-Dorn, Alexander Egyed
J. Softw. Evol. Process.1
2025 Generating Quality Assurance Constraints From Natural Language With LLMs
abstract
ABSTRACT This paper addresses the challenge of automating process‐centric quality assurance (QA) in safety‐critical domains, where compliance with regulations is crucial. Currently, QA engineers manually check compliance using tedious methods like browsing engineering artifacts and ad‐hoc scripts. Automated support could improve efficiency, but it requires constraints to be written in structured, executable forms (e.g., in the Object Constraint Language, OCL), whereas engineers prefer natural language. To bridge this gap, we propose the use of large language models (LLMs) to generate OCL from natural language, enhanced by schema‐based prompting and domain‐specific language (DSL)–based repairs. Unlike prior work focused on UML models, this work applies OCL to software process QA. Evaluating six LLMs, we find o1‐mini and Codestral perform best, with our automatic repairs ensuring constraint executability for 22%–44% of an LLM's generated OCL constraints that would otherwise remain nonexecutable due to errors.
Christoph Mayr-Dorn, Anmol Bilal, Cosmina-Cristina Ratiu, Alexander Egyed
J. Softw. Evol. Process.2
2024 Supporting Engineering Process Compliance via Generation of Detailed Guidance Actions
abstract
In regulation-intensive domains, software engineering organizations need to demonstrate compliance with process and traceability guidelines. To this end, novel approaches have emerged that support these activities via the automatic checking of constraints. Yet, engineers still need to decide how to fix violated constraints. While some general-purpose state-of-the-art constraint-checking approaches provide basic support for fixing constraint violations, the provided fixing recommendations often lack crucial details. The approaches typically do not analyze the overall constraint to identify which constraint sub-expressions put a restriction on the possible fixing action. For example, a fix suggests “set the parent of requirement R1 to an issue” rather than additionally stating that the “issue needs to be of type ’Change Request’ and in state ’Released” ’. Engineers, therefore, require mental effort to identify such restrictions by analyzing the constraint in detail or require extra time to try out which action completely fixes the constraint violation.
Anmol Bilal, Christoph Mayr-Dorn, Alexander Egyed
ICSSP1