Abstract During the last decades, software traceability has been studied in a large number of studies, from different perspectives (e.g., how to create traces and what are its benefits). This large body of knowledge needs to be better explored and exploited by both practitioners and researchers: We need an overview of different aspects of traceability and a structured way to assess and compare existing work in order to extend it with new research or apply it in practice, Thus, we have conducted a secondary study on this large corpus of primary studies, focusing on empirical studies on software traceability, without setting any further restrictions in terms of investigating a specific domain or concrete artifacts. The study explores the goals of existing approaches and the empirical methods used for their evaluation. Its main contributions are the investigation of (a) the type of artifacts linked through traceability approaches; (b) the benefits of using artifact traceability approaches; (c) the ways of measuring their benefit; and (d) the research methods used. The results of the study suggest that (i) requirements artifacts are dominant in traceability; (ii) the research corpus focuses on the proposal of novel techniques for establishing traceability; and (iii) the main benefits are the improvement of software correctness and maintainability. Finally, although many studies include some empirical validation, there is still room for improvements and research methods that can be used more extensively. The obtained results are discussed under the prism of both researchers and practitioners and are compared against the state‐of‐the‐art.

Empirical evidence has pointed out that Extract Method refactorings are among the most commonly applied refactorings by software developers. The identification of Long Method code smells and the ranking of the associated refactoring opportunities is largely based on the use of metrics, primarily with measures of cohesion, size and coupling. Despite the relevance of these proper-ties to the presence of large, complex and non-cohesive pieces of code, the empirical validation of these metrics has exhibited relatively low accuracy (max precision: 66%) regarding their predictive power for long methods or extract method opportunities. In this work we perform an empirical validation of the ability of cohesion, coupling and size metrics to predict the existence and the intensity of long method occurrences. According to the statistical analysis, the existence and the intensity of the Long Method smell can be effectively predicted by two size (LoC and NoLV), two coupling (MPC and RFC), and four cohesion (LCOM1, LCOM2, Coh, and CC) metrics. Furthermore, the integration of these metrics into a multiple logistic regression model can predict whether a method should be refactored with a precision of 89% and a recall of 91%. The model yields suggestions whose ranking is strongly correlated to the ranking based on the effect of the corresponding refactorings on source code (correl. coef. 0.520). The results are discussed by providing interpretations and implications for research and practice.

Documentation issues in software projects have been recently classified as a type of technical debt (TD), a concept that express-es how shortcuts during software development result in additional maintenance and evolution effort. The specific type of TD is termed documentation debt, and is among the most prevalent ones in practice and research. In this study we propose a tool-based approach for preventing documentation TD during requirements engineering, by: (a) integrating requirements specifications into the IDE, and (b) enabling the real-time creation of traces between requirements and code. To this end, we collaborated with a small/medium software company and conducted a qualitative case study to: (a) analyze the current process and identify existing TD types, (b) collect the requirements and implement a tool that aims at preventing the accumulation of documentation TD, and (c) investigate whether the tool successfully meets its goal. The results of the study suggest that the developers are motivated to use the developed tool, since they feel that they can develop, maintain and utilize requirements specifications and traces as part of their daily routine.

`Extract Method' is considered one of the most frequently applied and beneficial refactorings, since the corresponding Long Method smell is among the most common and persistent ones. Although Long Method is conceptually related to the implementation of diverse functionalities within a method, until now, this relationship has not been utilized while identifying refactoring opportunities. In this paper we introduce an approach (accompanied by a tool) that aims at identifying source code chunks that collaborate to provide a specific functionality, and propose their extraction as separate methods. The accuracy of the proposed approach has been empirically validated both in an industrial and an open-source setting. In the former case, the approach was capable of identifying functionally related statements within two industrial long methods (approx. 500 LoC each), with a recall rate of 93 percent. In the latter case, based on a comparative study on open-source data, our approach ranks better compared to two well-known techniques of the literature. To assist software engineers in the prioritization of the suggested refactoring opportunities the approach ranks them based on an estimate of their fitness for extraction. The provided ranking has been validated in both settings and proved to be strongly correlated with experts' opinion.

Stability refers to a software system's resistance to the “ripple effect”, i.e., propagation of changes. In this paper, we investigate the stability of classes that participate in instances/occurrences of GoF design patterns. We examine whether the stability of such classes is affected by (a) the pattern type, (b) the role that the class plays in the pattern, (c) the number of pattern occurrences in which the class participates, and (d) the application domain. To this end, we conducted a case study on about 65.000 Java open-source classes, where we performed change impact analysis on classes that participate in zero, one (single pattern), or more than one (coupled) pattern occurrences. The results suggest that, the application of design patterns can provide the expected “shielding” of certain pattern-participating classes against changes, depending on their role in the pattern. Moreover, classes that participate in coupled pattern occurrences appear to be the least stable. The results can be used for assessing the benefits and liabilities of the use of patterns and for testing and refactoring prioritization, because less stable classes are expected to require more effort while testing, and urge for refactoring activities that would make them more resistant to change propagation.

Context: Investing on Open Source Software (OSS) as a "code reuser", involves certain risks, such as the difficulty in understanding the level of OSS design quality Aim: We investigate the levels of design quality of OSS projects, across different application domains. Method: We conducted a case study, which is the most fitting research method for observing a phenomenon in its real context, which is active for a long period of time, and for which variables cannot be controlled. Results: We present the values for seven design quality metrics of 546 OSS projects, as well as the statistically significant differences across application domains. Conclusions: The results of the study suggest that OSS application domains correlate with several design quality characteristics, in the sense that projects within one application domain appear to have similar levels of design quality. In addition to that, the results reveal application domains with high and low levels of design quality.