Software defect prediction is crucial for prioritising quality assurance tasks, however, there are still limitations to the use of defect models. For example, the outputs often do not provide the defect type, severity, or the cause of the defect. Current models are also often complex in implementation (they use low transparency classifiers such as random forest or support vector machines) and primarily output binary predic- tions. They lack directly actionable outputs, that is, outputs that provide additional information (e.g., defect severity or defect type) to aid in fixing the defect. One approach is to utilise tools of explainable AI. In order to improve current models and plan the direction for explainability in software defect prediction, we need to understand how explainable current models are. Starting from 861 papers from multiple databases, we inves- tigated a sample of 132 papers in a systematic literature review. We extracted the following information to answer our research questions: (i) information about the outputs (e.g., how informative they were) and ex- plainability methods used, (ii) how explainability and performance is mea- sured and (iii) explainability in future research. Our results were sum- marised by manually labelling the data so that trends could be analysed across selected papers, along with a thematic analysis. We found that 71% of current models used binary outputs, while 68% of models were not yet utilising any explainability techniques. Only 7% of studies considered explainability in their future research sug- gestions. There is still a lack of awareness among researchers for the need for explainability and motivation to invest further research into more explainable and more informative software defect prediction models.

While the software engineering community (i.e., those involved with engineering software) is constantly in search of insights into team atmosphere and group dynamics and the way these issues impact team performance, little opportunities typically exist to explore this issue. Student projects offer an opportunity for us to understand these issues, and particularly if these students are on the verge of leaving university for post-study work and using similar practices to those used in industry. We explore a range of student software development projects’ data and students’ open-ended responses to five group dynamics categories: communication, time management, commitment, problem analysis and solving, and initiative and involvement. We analyse both quantitative and qualitative data to study the variation in group dynamics across teams developing different software and how these variations correlated with team satisfaction. We also explore the group dynamics themes that evolve from students’ open responses in relation to the five categories. Furthermore, we relate the prevalence of the themes to various software development performance metrics, before exploring the opportunity of predicting an optimum team dynamics. We observe variations in the way different teams work, but higher performing teams also committed more to their projects. Various group dynamics themes were evident among functional teams, and specific patterns were more pronounced when teams were productive. Further, while there is no specific group dynamics pattern that predicts project success, successful teams were most organised and reflective. Competence may set the tone for positive group dynamics and team performance. Also, an achievement-driven orientation is as important as the soft skills and interpersonal aspects.

Abstract A key function of a software system is its ability to facilitate the manipulation of data, which is often implemented using a flavour of the Structured Query Language (SQL). To develop the data operations of software (i.e, creating, retrieving, updating, and deleting data), developers are required to excel in writing and combining both SQL and application code. The problem is that writing SQL code in itself is already challenging (e.g., SQL anti-patterns are commonplace) and combining SQL with application code (i.e., for SQL development tasks) is even more demanding. Meanwhile, we have little empirical understanding regarding the characteristics of SQL development tasks. Do SQL development tasks typically need more code changes? Do they typically have a longer time-to-completion? Answers to such questions would prepare the community for the potential challenges associated with such tasks. Our results obtained from 20 Apache projects reveal that SQL development tasks have a significantly longer time-to-completion than SQL-unrelated tasks and require significantly more code changes. Through our qualitative analyses, we observe that SQL development tasks require more spread out changes, effort in reviews and documentation. Our results also corroborate previous research highlighting the prevalence of SQL anti-patterns. The software engineering community should make provision for the peculiarities of SQL coding, in the delivery of safe and secure interactive software.