Mohamed Y. Soliman

Yikun Li, Mohamed Soliman, Paris Avgeriou

Self-Admitted Technical Debt or SATD can be found in various sources, such as source code comments, commit messages, issue tracking systems, and pull requests. Previous research has established the existence of relations between SATD items in different sources; such relations can be useful for investigating and improving SATD management. However, there is currently a lack of approaches for automatically detecting these SATD relations. To address this, we proposed and evaluated approaches for automatically identifying SATD relations across different sources. Our findings show that our approach outperforms baseline approaches by a large margin, achieving an average F1-score of 0.829 in identifying relations between SATD items. Moreover, we explored the characteristics of SATD relations in 103 open-source projects and describe nine major cases in which related SATD is documented in a second source, and give a quantitative overview of 26 kinds of relations.

A. Rezaei, K. B. Nakshatrala, F. Siddiqui et al.

We present a systematic global sensitivity analysis using the Sobol method which can be utilized to rank the variables that affect two quantity of interests -- pore pressure depletion and stress change -- around a hydraulically-fractured horizontal well based on their degree of importance. These variables include rock properties and stimulation design variables. A fully-coupled poroelastic hydraulic fracture model is used to account for pore pressure and stress changes due to production. To ease the computational cost of a simulator, we also provide reduced order models (ROMs), which can be used to replace the complex numerical model with a rather simple analytical model, for calculating the pore pressure and stresses at different locations around hydraulic fractures. The main findings of this research are: (i) mobility, production pressure, and fracture half-length are the main contributors to the changes in the quantities of interest. The percentage of the contribution of each parameter depends on the location with respect to pre-existing hydraulic fractures and the quantity of interest. (ii) As the time progresses, the effect of mobility decreases and the effect of production pressure increases. (iii) These two variables are also dominant for horizontal stresses at large distances from hydraulic fractures. (iv) At zones close to hydraulic fracture tips or inside the spacing area, other parameters such as fracture spacing and half-length are the dominant factors that affect the minimum horizontal stress. The results of this study will provide useful guidelines for the stimulation design of legacy wells and secondary operations such as refracturing and infill drilling.

Yikun Li, Mohamed Soliman, Paris Avgeriou

Technical debt refers to taking shortcuts to achieve short-term goals while sacrificing the long-term maintainability and evolvability of software systems. A large part of technical debt is explicitly reported by the developers themselves; this is commonly referred to as Self-Admitted Technical Debt or SATD. Previous work has focused on identifying SATD from source code comments and issue trackers. However, there are no approaches available for automatically identifying SATD from other sources such as commit messages and pull requests, or by combining multiple sources. Therefore, we propose and evaluate an approach for automated SATD identification that integrates four sources: source code comments, commit messages, pull requests, and issue tracking systems. Our findings show that our approach outperforms baseline approaches and achieves an average F1-score of 0.611 when detecting four types of SATD (i.e., code/design debt, requirement debt, documentation debt, and test debt) from the four aforementioned sources. Thereafter, we analyze 23.6M code comments, 1.3M commit messages, 3.7M issue sections, and 1.7M pull request sections to characterize SATD in 103 open-source projects. Furthermore, we investigate the SATD keywords and relations between SATD in different sources. The findings indicate, among others, that: 1) SATD is evenly spread among all sources; 2) issues and pull requests are the two most similar sources regarding the number of shared SATD keywords, followed by commit messages, and then followed by code comments; 3) there are four kinds of relations between SATD items in the different sources.

Yikun Li, Mohamed Soliman, Paris Avgeriou

Technical debt is a metaphor indicating sub-optimal solutions implemented for short-term benefits by sacrificing the long-term maintainability and evolvability of software. A special type of technical debt is explicitly admitted by software engineers (e.g. using a TODO comment); this is called Self-Admitted Technical Debt or SATD. Most work on automatically identifying SATD focuses on source code comments. In addition to source code comments, issue tracking systems have shown to be another rich source of SATD, but there are no approaches specifically for automatically identifying SATD in issues. In this paper, we first create a training dataset by collecting and manually analyzing 4,200 issues (that break down to 23,180 sections of issues) from seven open-source projects (i.e., Camel, Chromium, Gerrit, Hadoop, HBase, Impala, and Thrift) using two popular issue tracking systems (i.e., Jira and Google Monorail). We then propose and optimize an approach for automatically identifying SATD in issue tracking systems using machine learning. Our findings indicate that: 1) our approach outperforms baseline approaches by a wide margin with regard to the F1-score; 2) transferring knowledge from suitable datasets can improve the predictive performance of our approach; 3) extracted SATD keywords are intuitive and potentially indicating types and indicators of SATD; 4) projects using different issue tracking systems have less common SATD keywords compared to projects using the same issue tracking system; 5) a small amount of training data is needed to achieve good accuracy.

Ruiyin Li, Mohamed Soliman, Peng Liang et al.

The phenomenon of architecture erosion can negatively impact the maintenance and evolution of software systems, and manifest in a variety of symptoms during software development. While erosion is often considered rather late, its symptoms can act as early warnings to software developers, if detected in time. In addition to static source code analysis, code reviews can be a source of detecting erosion symptoms and subsequently taking action. In this study, we investigate the erosion symptoms discussed in code reviews, as well as their trends, and the actions taken by developers. Specifically, we conducted an empirical study with the two most active Open Source Software (OSS) projects in the OpenStack community (i.e., Nova and Neutron). We manually checked 21,274 code review comments retrieved by keyword search and random selection, and identified 502 code review comments (from 472 discussion threads) that discuss erosion. Our findings show that (1) the proportion of erosion symptoms is rather low, yet notable in code reviews and the most frequently identified erosion symptoms are architectural violation, duplicate functionality, and cyclic dependency; (2) the declining trend of the identified erosion symptoms in the two OSS projects indicates that the architecture tends to stabilize over time; and (3) most code reviews that identify erosion symptoms have a positive impact on removing erosion symptoms, but a few symptoms still remain and are ignored by developers. The results suggest that (1) code review provides a practical way to reduce erosion symptoms; and (2) analyzing the trend of erosion symptoms can help get an insight about the erosion status of software systems, and subsequently avoid the potential risk of architecture erosion.

Mohamed Soliman, Matthias Galster, Paris Avgeriou

Software developers use issue trackers (e.g. Jira) to manage defects, bugs, tasks, change requests, etc. In this paper we explore (a) how architectural knowledge concepts (e.g. architectural component behavior, contextual constraints) are textually represented in issues (e.g. as adjectives), (b) which architectural knowledge concepts commonly occur in issues, and (c) which architectural knowledge concepts appear together. We analyzed issues in the Jira issue trackers of three large Apache projects. To identify ``architecturally relevant'' issues, we linked issues to architecturally relevant source code changes in the studied systems. We then developed a code book by manually labeling a subset of issues. After reaching conceptual saturation, we coded remaining issues. Our findings support empirically-grounded search tools to identify architectural knowledge concepts in issues for future reuse.