Chetan Arora’s research while affiliated with Monash University (Australia) and other places

Large language models (LLMs) are increasingly used to generate software artifacts, such as source code, tests, and trace links. Requirements play a central role in shaping the input prompts that guide LLMs, as they are often used as part of the prompts to synthesize the artifacts. However, the impact of requirements formulation on LLM performance remains unclear. In this paper, we investigate the role of requirements smells-indicators of potential issues like ambiguity and inconsistency-when used in prompts for LLMs. We conducted experiments using two LLMs focusing on automated trace link generation between requirements and code. Our results show mixed outcomes: while requirements smells had a small but significant effect when predicting whether a requirement was implemented in a piece of code (i.e., a trace link exists), no significant effect was observed when tracing the requirements with the associated lines of code. These findings suggest that requirements smells can affect LLM performance in certain SE tasks but may not uniformly impact all tasks. We highlight the need for further research to understand these nuances and propose future work toward developing guidelines for mitigating the negative effects of requirements smells in AI-driven SE processes.

Large Language Models (LLMs), such as GPT models, are increasingly used in software engineering for various tasks, such as code generation, requirements management, and debugging. While automating these tasks has garnered significant attention, a systematic study on the impact of varying hyperparameters on code generation outcomes remains unexplored. This study aims to assess LLMs' code generation performance by exhaustively exploring the impact of various hyperparameters. Hyperparameters for LLMs are adjustable settings that affect the model's behaviour and performance. Specifically, we investigated how changes to the hyperparameters: temperature, top probability (top_p), frequency penalty, and presence penalty affect code generation outcomes. We systematically adjusted all hyperparameters together, exploring every possible combination by making small increments to each hyperparameter at a time. This exhaustive approach was applied to 13 Python code generation tasks, yielding one of four outcomes for each hyperparameter combination: no output from the LLM, non executable code, code that fails unit tests, or correct and functional code. We analysed these outcomes for a total of 14,742 generated Python code segments, focusing on correctness, to determine how the hyperparameters influence the LLM to arrive at each outcome. Using correlation coefficient and regression tree analyses, we ascertained which hyperparameters influence which aspect of the LLM. Our results indicate that optimal performance is achieved with a temperature below 0.5, top probability below 0.75, frequency penalty above -1 and below 1.5, and presence penalty above -1. We make our dataset and results available to facilitate replication.

Context: Human-centric defects (HCDs) are nuanced and subjective defects that often occur due to end-user perceptions or differences, such as their genders, ages, cultures, languages, disabilities, socioeconomic status, and educational backgrounds. Development teams have a limited understanding of these issues, which leads to the neglect of these defects. Defect reporting tools do not adequately handle the capture and fixing of HCDs. Objective: This research aims to understand the current defect reporting process and tools for managing defects. Our study aims to capture process flaws and create a preliminary defect categorisation and practices of a defect-reporting tool that can improve the reporting and fixing of HCDs in software engineering. Method: We first manually classified 1,100 open-source issues from the GitHub defect reporting tool to identify human-centric defects and to understand the categories of such reported defects. We then interviewed software engineering practitioners to elicit feedback on our findings from the GitHub defects analysis and gauge their knowledge and experience of the defect-reporting process and tools for managing human-centric defects. Results: We identified 176 HCDs from 1,100 open-source issues across six domains: IT-Healthcare, IT-Web, IT-Spatial, IT-Manufacturing, IT-Finance, and IT-Gaming. Additionally, we interviewed 15 software practitioners to identify shortcomings in the current defect reporting process and determine practices for addressing these weaknesses. Conclusion: HCDs present in open-source repositories are fairly technical, and due to the lack of awareness and improper defect reports, they present a major challenge to software practitioners. However, the management of HCDs can be enhanced by implementing the practices for an ideal defect reporting tool developed as part of this study.

Fairness is one of the socio-technical concerns that must be addressed in software systems. Considering the popularity of mobile software applications (apps) among a wide range of individuals worldwide, mobile apps with unfair behaviors and outcomes can affect a significant proportion of the global population, potentially more than any other type of software system. Users express a wide range of socio-technical concerns in mobile app reviews. This research aims to investigate fairness concerns raised in mobile app reviews. Our research focuses on AI-based mobile app reviews as the chance of unfair behaviors and outcomes in AI-based mobile apps may be higher than in non-AI-based apps. To this end, we first manually constructed a ground-truth dataset, including 1,132 fairness and 1,473 non-fairness reviews. Leveraging the ground-truth dataset, we developed and evaluated a set of machine learning and deep learning models that distinguish fairness reviews from non-fairness reviews. Our experiments show that our best-performing model can detect fairness reviews with a precision of 94%. We then applied the best-performing model on approximately 9.5M reviews collected from 108 AI-based apps and identified around 92K fairness reviews. Next, applying the K-means clustering technique to the 92K fairness reviews, followed by manual analysis, led to the identification of six distinct types of fairness concerns (e.g., ‘receiving different quality of features and services in different platforms and devices’ and ‘lack of transparency and fairness in dealing with user-generated content’). Finally, the manual analysis of 2,248 app owners’ responses to the fairness reviews identified six root causes (e.g., ‘copyright issues’) that app owners report to justify fairness concerns.