With generative AI becoming widespread, the existence of AI-based programming assistants for developers is no surprise. Developers increasingly use them for their work, including generating code to fulfil the data protection requirements (privacy) of the apps they build. We wanted to know if the reality is the same as expectations of AI-based programming assistants when trying to fulfil software privacy requirements, and the challenges developers face when using AI-based programming assistants and how these can be improved. To this end, we conducted a survey with 51 professional developers worldwide. We found that AI-based programming assistants need to be improved in order for developers to better trust them with generating code that ensures privacy. In this paper, we provide some recommendations including model and system-level improvements and some key further research directions to improve AI-based programming assistants for developing secure code.

Abstract There has been great interest in better understanding software engineer emotions during development. But how to do this? We built a prototype AI-powered Emotion-centric Developer Insights Platform, EmoReflex, to support developers to report and reflect how they feel when working on various tasks across different metrics. It also assists their managers to get insights into their team’s emotional health, and provides them with recommendations to guide them handle the team’s emotional wellbeing. We present our tool prototype and evaluation results generated by a user study conducted with two user groups consisting of twenty developers and twenty managers. We present some design implications derived from our user study that can be used to inform design decisions in emotion-centric software development tools.

Abstract The use of diverse mobile applications among senior users is becoming increasingly widespread. However, many of these apps contain accessibility problems that result in negative user experiences for seniors. A key reason is that software practitioners often lack the time or resources to address the broad spectrum of age-related accessibility and personalisation needs. As current developer tools and practices encourage one-size-fits-all interfaces with limited potential to address the diversity of senior needs, there is a growing demand for approaches that support the systematic creation of adaptive, accessible app experiences. To this end, we present AdaptForge , a novel model-driven engineering (MDE) approach that enables advanced design-time adaptations of mobile application interfaces and behaviours tailored to the accessibility needs of senior users. AdaptForge uses two domain-specific languages (DSLs) to address age-related accessibility needs. The first model defines users’ context-of-use parameters, while the second defines conditional accessibility scenarios and corresponding UI adaptation rules. These rules are interpreted by an MDE workflow to transform an app’s original source code into personalised instances. We also report evaluations with professional software developers and senior end-users, demonstrating the feasibility and practical utility of AdaptForge .

Empirical software engineering researchers are committed to investigating better ways of improving software engineering practice. To do this, gathering data about software professionals’ experiences and perspectives on the researched topic is crucial. However, in the last decade, our experience of recruiting software professionals as potential participants in our studies has met with fluctuating success. Therefore, we had to explore multiple possibilities when recruiting participants. This cost us more effort and time than anticipated. In this paper, we briefly discuss the challenges we faced when recruiting participants for empirical research in software engineering, the solutions we implemented to address these challenges, and a concise list of strategies for garnering the interest of potential participants.

Background: Research shows that emotional intelligence (EI) should be used alongside cognitive intelligence during requirements change (RC) handling in Software Engineering (SE), especially in agile settings. Objective: We wanted to study the role of EI in-depth during RC handling. Method: We conducted a mixed-methods study (an interview study followed by a survey study) with 124 software practitioners. Findings: We found the causal condition, intervening condition and causes lead to key direct consequences of regulating own emotions, managing relationships, and extended consequences of sustaining productivity, setting and sustaining team goals. We found several strategies of supporting EI during RC handling. Further, we found strong correlations between six strategies and one being aware of own emotions, regulating own emotions, sustaining team productivity, and setting and sustaining team goals. Conclusion: Empathising with others and tracking commitments and decisions as a team are key strategies that have strong correlations between managing emotions, between sustaining team productivity, and between setting and sustaining team goals. To the best of our knowledge, the framework we present in this paper is the first theoretical framework on EI in SE research. We provide recommendations for software practitioners to consider during RC handling.

Abstract Human values such as honesty, social responsibility, fairness, privacy, and the like are things considered important by individuals and society. Software systems, including mobile software applications (apps), may ignore or violate such values, leading to negative effects in various ways for individuals and society. While some works have investigated different aspects of human values in software engineering, this mixed-methods study focuses on honesty as a critical human value. In particular, we studied (i) how to detect honesty violations in mobile apps, (ii) the types of honesty violations in mobile apps, and (iii) the perspectives of app developers on these detected honesty violations. We first develop and evaluate 7 machine learning (ML) models to automatically detect violations of the value of honesty in app reviews from an end-user perspective. The most promising was a Deep Neural Network model with F1 score of 0.921. We then conducted a manual analysis of 401 reviews containing honesty violations and characterised honesty violations in mobile apps into 10 categories: unfair cancellation and refund policies; false advertisements; delusive subscriptions; cheating systems; inaccurate information; unfair fees; no service; deletion of reviews; impersonation; and fraudulent-looking apps. A developer survey and interview study with mobile developers then identified 7 key causes behind honesty violations in mobile apps and 8 strategies to avoid or fix such violations. The findings of our developer study also articulate the negative consequences that honesty violations might bring for businesses, developers, and users. Finally, the app developers’ feedback shows that our prototype ML-based models can have promising benefits in practice.

Background:Requirements Changes (RCs) – the additions/modifications/deletions of functional/non-functional requirements in software products – are challenging for software practitioners to handle. Handling some changes may significantly impact the emotions of the practitioners.Objective:We wanted to know the key challenges that make RC handling difficult, how these impact the emotions of software practitioners, what influences their RC handling, and how RC handling can be made less emotionally challenging.Method:We followed a mixed-methods approach. We conducted two survey studies, with 40 participants and 201 participants respectively. The presentation of key quantitative data was followed by descriptive statistical analysis, and the qualitative data was analysed using Strauss–Corbinian Grounded Theory, and Socio–Technical Grounded Theory analysis techniques.Findings:We found (1) several key factors that make RC handling an emotional challenge, (2) varying emotions that practitioners feel when it is challenging to handle RCs, (3) how stakeholders, including practitioners themselves, peers, managers and customers, influence the RC handling and how practitioners feel due to the stakeholder influence, and (4) practices that can be used to better handle RCs.Conclusion:Some challenges are technical and some are social which also belong to aspects of agile practice, emotional intelligence, and likely belong to cognitive intelligence. Therefore, to better handle RCs with positive emotions in socio–technical environments, agility, emotional intelligence, and cognitive intelligence need to work in synergy with each other.

Background:A preliminary study we conducted showed that software practitioners respond to requirements changes (RCs) with different emotions, and that their emotions vary at stages of the RC handling life cycle, such asreceiving, developing,anddeliveringRCs. Furthermore, such developer emotions have direct linkages to cognition, productivity, and decision making. Therefore, it is important to gain a comprehensive understanding the role of emotions in a critical scenarios like handling RCs.Objective:We wanted to study how practitionersemotionallyrespond to RCs.Method:We conducted a world-wide survey with the participation of 201 software practitioners. In our survey, we used the Job-related Affective Well-being Scale (JAWS) and open-ended questions to capture participants’ emotions when handling RCs in their work and query about the different circumstances when they feel these emotions. We used a combined approach of statistical analysis, JAWS, and Socio-Technical Grounded Theory (STGT)for Data Analysisto analyse our survey data.Findings:We identified (1) emotional responses to RCs, i.e., the most commonemotionsfelt by practitioners when handling RCs; (2) differentstimuli– such as the RC, the practitioner, team, manager, customer – that trigger these emotions through their own different characteristics; (3)emotion dynamics, i.e., the changes in emotions during the RC handling life cycle; (4)RC stageswhere particular emotions are triggered; and (5)time related aspectsthat regulate the emotion dynamics.Conclusion:Practitioners are not pleased with receiving RCs all the time. Last minute RCs introduced closer to a deadline especially violate emotional well-being of practitioners. We present some practical recommendations for practitioners to follow, including a dual-purpose emotion-centric decision guide to help decide when to introduce or accept an RC, and some future key research directions.

Requirements Engineering (RE) requires the collaboration of various roles in SE, such as requirements engineers, stakeholders and other developers, and it is thus a very highly human dependent process in software engineering (SE). Identifying how“human aspects”– such as personality, motivation, emotions, communication, gender, culture and geographic distribution – might impact on the RE process would assist us in better supporting successful RE. The main objective of this paper is to systematically review primary studies that have investigated the effects of various human aspects on the RE process. We wanted to identify if any critical human aspects have been found, and what might be the relationships between different human aspects impacting the RE process. A systematic literature review (SLR) was conducted and identified 474 initial primary research studies. These were eventually filtered down to 74 relevant, high-quality primary studies. No primary study to date was found to focus on identifying what are the most influential human aspects on the RE process. Among the studied human aspects, the effects of communication have been considered in many studies of RE. Other human aspects such as personality, motivation and gender have mainly been investigated to date in relation to more general SE studies that include RE as one phase. Findings show that studying more than one human aspect together is beneficial, as this reveals relationships between various human aspects and how they together impact the RE process. However, the majority of these studied combinations of human aspects are unique. From 56.8 percent of studies that identified the effects of human aspects on RE, 40.5 percent identified the positive impact, 30.9 percent negative, 26.2 percent identified both impacts whereas 2.3 percent mentioned that there was no impact. This implies that a variety of human aspects positively or negatively affects the RE process and a well-defined theoretical analysis on the effects of different human aspects on RE remains to be defined and practically evaluated. The findings of this SLR help researchers who are investigating the impact of various human aspects on the RE process by identifying well-studied research areas, and highlight new areas that should be focused on in future research.

Background:Originally, developers aimed to identify most software requirements upfront in software development projects. However, agile methods explicitly encourage software requirements to be changed throughout development, i.e., many Requirements Changes (RCs) occur.Objective:The objective of this study is to better understand RCs and produce a taxonomy of RCs in agile contexts.Method:We ran a mixed-methods approach comprising a series of studies: an interview-based study (10 participants from New Zealand and Australia), a focused literature review, and an in-depth survey (40 participants world-wide).Results:Key characteristics of RCs in agile we found relate to differenttypesandforms, agile RCs have multiplereasonsandsources, they are brought by differentcarriers, and their emergence in agile is via a variety ofevents.Summary:The presented taxonomy provides a guide for software practitioners to use to help manage RC-related issues in agile contexts.