Abstract Context Security issues in Open-Source (OS) software systems emerge from everyday coding activities carried out by developers. As security best practices evolve toward “shift-left” paradigms—emphasizing early and continuous integration of security into the development process—understanding how these issues are introduced and fixed has become increasingly important. Objective Our primary goal is to study the spread and evolution of security issues that lie in the source code of OS Python software systems at commit level. Method We conducted a mining study in which we quantitatively analyzed the commit histories of 361 OS Python software systems, whose repositories were publicly available on GitHub , for a total of 380,931 commits analyzed. To identify security issues at the commit level, we used SonarQube , a popular and widely used both in academic and industrial contexts Static Application Security Testing ( SAST ) tool. Results We observed that security issues are spread in OS Python software systems (on average, there are about 14 security issues per commit) and tend to survive for 11 days and 14 commits. Critical security issues, despite their high severity level, are the most spread and tend to survive the most. Furthermore, we noticed that 55 kinds of security issues—belonging to 62 OWASP Top 10 and CWE security classes—were introduced, and the top six (per number of introductions) are mostly critical and account for 77% of all introduced security issues. Conclusions Python developers need to give utmost importance to security issues, particularly critical ones. To that end, we can suggest developers that use secure coding practices, automated tools, or even DevSecOps to limit/avoid the introduction of security issues into their source code or fix them as soon as possible.

In this paper, we present the preliminary findings from a qualitative study (i.e., semi-structured interviews) on how a Mindfulness-Based Stress Reduction (MBSR) program, carried out in the Software Development (SD) working context, is perceived by the software developers of a multinational company who participated in the MBSR program and by the instructor who led it. MBSR is a deeply personal and experiential practice in helping individuals manage stress, particularly in high-pressure environments such as workplaces, healthcare settings, education, and other demanding professional or personal situations. Although MBSR has been experimented in different working contexts; surprisingly, it has never been studied in the SD working context where there are several stress factors that developers experience (e.g., time pressure and uncertainty about the content of a particular task and its outcome). In this respect, qualitative research can generate valuable insights into the application of MBSR in the SD working context that cannot be captured by standardized quantitative measures. Being MBSR instructors and software developers the key stakeholders in delivering an MBSR program in the SD working context, understanding their first-hand experiences can provide a more detailed picture of the investigated phenomenon. The most important takeaway result of our research can be summarized as follows: despite initial skepticism, the developers recognized personal improvements due to the MBSR practice, though the integration of MBSR techniques in the working context remained challenging.

Most Software Engineering (SE) human-based controlled experiments rely on students as participants, raising concerns about their external validity. Specifically, the realism of results obtained from students and their applicability to the software industry remains in question. In this short paper, we bring further evidence on this controversial point. To do so, we compare 62 students and 42 software professionals on a bug-fixing task on the same Java program. The students were enrolled in a Bachelor’s program in Computer Science, while the professionals were employed by two multinational companies (for one of them, the professionals were from two offices). Some variations in the experimental settings of the two groups (students and professionals) were present. For instance, the experimental environment of the experiment with professionals was more realistic; i.e., they faced some stress factors such as interruptions during the bug-fixing task. Considering the differences between the two groups of participants, the gathered data show that the students outperformed the professionals in fixing bugs. This diverges to some extent from past empirical evidence. Rather than presenting definitive conclusions, our results aim to catalyze the discussion on the use of students in experiments and pave the way for future investigations. Specifically, our results encourage us to examine the complex factors influencing SE tasks, making experiments as more realistic as possible.

The increasing adoption of Artificial Intelligence (AI) in any kind of software has highlighted the need for greater transparency, security, and traceability within the AI supply chain. The AI Bill of Materials (AIBoM) extends the Software Bill of Materials (SBoM) concept by incorporating AI-specific components such as models, datasets, dependencies, and metadata. In this paper, we introduce ALOHA, a novel tool that automatically generates AIBoM from AI models hosted on Hugging Face (HF), leveraging the CycloneDX standard for software transparency and security. ALOHA extracts relevant metadata from model cards and maps them to a structured AIBoM format, ensuring compliance with existing SBoM frameworks. We conducted a preliminary empirical evaluation on a statistically significant sample of 312 AI models to assess ALOHA. Our initial findings indicate that while ALOHA successfully retrieves and structures essential AIBoM fields, challenges remain regarding metadata completeness and standardization of model cards. This work represents a step towards enhancing AI supply chain security and governance, providing a foundation for future advancements in AIBoM generation.

Background: Static Code Analysis (SCA) tools are widely adopted to enforce code quality standards. However, little is known about how open-source projects use and customize these tools. Aims: This paper investigates how GitHub projects use and customize a popular SCA tool, namely SonarQube Cloud. Method: We conducted a mining study of GitHub projects that are linked through GitHub Actions to SonarQube Cloud projects. Results: Among 321 GitHub projects using SonarQube Cloud, 81% of them are correctly connected to SonarQube Cloud projects, while others exhibit misconfigurations or restricted access. Among 265 accessible SonarQube Cloud projects, 75% use the organization's default quality gate, i.e., a set of conditions that deployed source code must meet to pass automated checks. While 55% of the projects use the built-in quality gate provided by SonarQube Cloud, 45% of them customize their quality gate with different conditions. Overall, the most common quality conditions align with SonarQube Cloud's “Clean as You Code” principle and enforce security, maintainability, reliability, coverage, and a few duplicates on newly added or modified source code. Conclusions: Many projects rely on predefined configurations, yet a significant portion customize their configurations to meet specific quality goals. Building on our initial results, we envision a future research agenda linking quality gate configurations to actual software outcomes (e.g., improvement of software security). This would enable evidence-based recommendations for configuring SCA tools like SonarQube Cloud in various contexts.

Large Language Models (LLMs) are currently used for various software development tasks, including generating code snippets to solve specific problems. Unlike reuse from the Web, LLMs are limited in providing provenance information about the generated code, which may have important trustworthiness and legal consequences. While LLM-based assistants may provide external links that are “related” to the generated code, we do not know how relevant such links are. This paper presents the findings of an empirical study assessing the extent to which 243 and 194 code snippets, across six programming languages, generated by Bing CoPilot and Google Gemini, likely originate from the links provided by these two LLM-based assistants. The study leverages automated code similarity assessments with thorough manual analysis. The study’s findings indicate that the LLM-based assistants provide a mix of relevant and irrelevant links having a different nature. Specifically, although 66% of the links from Bing CoPilot and 28% from Google Gemini are relevant, LLMs-based assistants still suffer from serious “provenance debt”.

A software supply chain consists of anything needed to develop and deliver a software project, including (third-party) components. Software Composition Analysis (SCA) allows for managing the security of software supply chains by identifying such components and their (security) vulnerabilities. The main goal of the empirical study presented in this paper is to investigate the effects of adopting/using over time an SCA tool like OWASP Dependency-Check (OWASP DC) in the context of the security of the software supply chain. To this end, following a cohort design, we analyzed the vulnerabilities affecting the components of the open-source (OS) Java Maven projects owned by the Apache Software Foundation (ASF) and publicly hosted on GitHub. These projects could adopt (or not) OWASP DC. The results indicate that the adoption of OWASP DC appears to be causing a significant reduction in the overall number/score of vulnerabilities, including those with a high Common Vulnerability Scoring System (CVSS) severity level. The use of OWASP DC also increased the vulnerabilities with a low severity level. Our results seem to encourage practitioners to adopt SCA to improve the security of their software supply chains.

GitHub’s dependency graph is a tool that eases Software Composition Analysis (SCA), and it is leveraged not only by other tools or by practitioners in their analyses but also by researchers when conducting studies on open-source projects. However, its potential inaccuracy may seriously harm its applicability and usefulness. This paper quantitatively and qualitatively analyzes the accuracy of GitHub’s dependency graphs for Java and Python projects, how such accuracy has changed over time, and what the likely pitfalls and limitations of the dependency graph are. After creating statistically significant samples of Java and Python projects, we analyzed their dependency graph in two directions, forward (by looking at dependencies), backward (by looking at dependents), and inspected their manifest/lock files. Results indicate that in our sample, dependencies have over 27% of inaccuracy, and dependents up to 10%. Errors depend on several reasons, among others, an oversimplified processing of manifest/lock files by the dependency graph generator. Our results provide (i) guidelines for researchers to understand the threats arising in studies based on the dependency graph and (ii) insights to practitioners and tool builders to enhance their SCA, given the current limitations of the dependency graph. • We show that GitHub dependency graph is inaccurate ( ≃ 20% errors in dependencies and ≃ 10 errors in dependents). • We report a qualitative categorization of dependency graph inaccuracies root causes. • The findings of our research warn about the accuracy of tools and studies leveraging the dependency graph.

Context: Test-Driven Development ( TDD ) is an agile development approach where the writing of unit tests precedes the writing of production code. Some software engineers have been advocating the use of TDD to develop Embedded Systems ( ESs ) despite the lack of empirical evidence on TDD applied to ES development. Objectives: Our overarching objective is to start building knowledge on TDD applied to ES development. Specifically, we investigated: (i) the claimed benefits of TDD ( i.e., increased external quality of ESs and developers’ productivity) and (ii) how developers apply TDD when developing ESs. Method: We conducted two empirical investigations. The former investigation, comprising two experiments, aimed to study the claimed benefits of TDD. To that end, we asked Computer Science (CS) Master’s students to fulfill ES development tasks by using TDD or a non-TDD approach. The latter investigation consisted of an ethnographically-informed study to gain insights into how developers apply TDD when developing ESs. In this study, we involved CS Master’s students, who were observed while fulfilling an ES development task. The participants in the two empirical investigations were different. Results: We found that the external quality of the developed ESs increased when using TDD as compared to a non-TDD approach, while there was not a substantial difference in developers’ productivity. However, TDD is perceived as more difficult to apply, and the development task is deemed more challenging with TDD. Several patterns emerged about how developers approach TDD when developing an ES ( e.g., the participants did not always develop in conformity with TDD). Conclusion: TDD seems to be a promising approach to the development of ESs, even though further research is needed. In this regard, we believe that our results can pave the way for future research with the involvement of software companies and professionals.

Context: A deprecated API ( Application Programming Interface ) is an API that its original developers no longer recommend using. Although deprecated APIs ( i.e., deprecated fields, methods, and classes) are still implemented, they are likely to be removed in future implementations. Consequently, developers are advised against using deprecated APIs in newly written code and are encouraged to update existing code to remove any deprecated API usage. Objective: We aimed to gather preliminary empirical evidence on deprecated API usages in open-source Java applications. Methods: To pursue such a goal, we conducted an exploratory Mining-Software-Repository ( MSR ) study in which we quantitatively analyzed the commit histories of 14 applications whose software projects were top-starred on GitHub. Results: The most important takeaway results of our study can be summarized as follows: (i) deprecated API usages are pretty widespread in the studied software applications; (ii) only in half of these applications, developers remove deprecated API usages as soon as possible; (iii) consuming their own deprecated APIs is a prevalent phenomenon in half of the studied applications; (iv) the introductions and removals of deprecated API usages are mostly due to changes performed by senior contributors; (v) developers mostly introduce and remove deprecated API usages when they are far from publishing a release version; and (vi) the introductions and removals of deprecated API usages are often undocumented in commit messages. Conclusion: The outcomes of our study suggest that developers should better handle deprecated API usages.

A Software Bill of Materials ( SBOM ) formally lists the open-source and proprietary components that constitute a software product, including their licenses, versions, vendors, vulnerabilities, and supply chain relationships. SBOMs enable software producers and consumers to gain visibility into the software supply chain and monitor the risks associated with software security, licensing, and more. This paper presents the results of an exploratory mining study investigating the adoption of SBOMs by open-source software projects. To that end, we mined GitHub and identified 186 public software repositories using SBOM generation tools owned by SPDX and CycloneDX . Although the adoption of SBOMs is low, it is increasing. Moreover, SBOMs are under version control or available in public release versions of less than half the software projects analyzed. Finally, only a limited fraction of SBOMs contain minimum/recommended information, and some SBOMs are also uncompliant with existing SBOM standards. Our study reveals that software producers are paying more attention to SBOMs, but even so, these may be incomplete. We urge software producers to adopt SBOMs and meet the new software supply chain standards. As for researchers, we foster further investigations on adopting SBOMs and their correct use.

As our lives, our businesses, and indeed our world economy become increasingly reliant on the secure operation of many interconnected software systems, the software engineering research community is faced with unprecedented research challenges, but also with exciting new opportunities. In this roadmap article, we outline our vision of software security analysis for the systems of the future. Given the recent advances in generative AI, we need new methods to assess and maximize the security of code co-written by machines. As our systems become increasingly heterogeneous, we need practical approaches that work even if some functions are automatically generated, e.g., by deep neural networks. As software systems depend evermore on the software supply chain, we need tools that scale to an entire ecosystem. What kind of vulnerabilities exist in future systems and how do we detect them? When all the shallow bugs are found, how do we discover vulnerabilities hidden deeply in the system? Assuming we cannot find all security flaws, how can we nevertheless protect our system? To answer these questions, we start our roadmap with a survey of recent advances in software security, then discuss open challenges and opportunities, and conclude with a long-term perspective for the field.

In this folklore-confirmation short paper, we present the results of a study on the removal of dead code. We aim to gather evidence on the impact of dead-method removal on the internal structure of source code and the usage of resources such as compilation time and space to store executable code. To that end, we studied 23 open-source Java desktop applications hosted on GitHub. We cleaned up each of these applications from its dead methods to obtain two versions: one with dead methods (i.e., original version) and another one without them (i.e., cleaned version). For each of these applications, we compared its versions (original and cleaned) to determine whether, and to what extent, the removal of dead methods affects the internal structure of source code and the usage of resources. We observed that, after removing dead methods, the internal structure of source code significantly improves, while the time to compile source code significantly diminishes as well as the space to store executable code.

GitHub’s dependency graph shows dependency relationships between repositories. This feature is leveraged by tools such as Dependabot, or GitHub’s feature to export SBOM (Software Bill of Materials) files. Also, it has been used in empirical studies. Inaccuracies in the dependency graph might negatively affect both the effectiveness of tools and the results of the conducted studies. In this paper, we present the results of a mining study to assess the accuracy of GitHub’s dependency graph in Java and Python open-source software projects. In particular, on April 16th, 2023, we randomly sampled 297 software projects developed in Java and 338 developed in Python (all hosted on GitHub), each using GitHub’s dependency graph. Then, we performed three analyses to assess how accurate GitHub’s dependency graph is: (i) backward analysis, focusing on the accuracy of the dependencies of a given repository, as reported in GitHub’s dependency graph; (ii) forward analysis, focusing on the accuracy of the dependents of a given repository, as reported in GitHub’s dependency graph; and (iii) manifest/lock file analysis, focusing on the correspondence between the dependencies reported in the dependency graph of a given repository and what was reported in the corresponding manifest/lock files. The obtained results highlight several inaccuracies in GitHub’s dependency graph, which might affect the output of tools based on GitHub’s dependency graph (e.g., Dependabot and SBOM generators) as well as the outcomes of past empirical studies. We also provide qualitative insights into these inaccuracies and implications for practitioners and researchers.

Peopleware, which includes anything related to the role of people in Software Development (SD), has been arousing an increasing interest from both the software industry and research community. This interest is due to the current economic system that demands high-quality software products with a short time to market, staying on the budget. This exposes software developers to the risk of experiencing stress, burnout, and reduced motivation, leading, in turn, to reduced job performance, low-quality SD-related artifacts, and increased turnover. Mindfulness represents a promising intervention that might let developers do their best at work, limiting or even preventing the previously mentioned negative outcomes. This paper presents MOOD (Mindfulness fOr sOftware Developers), a research project whose overarching goal is to customize a well-known and validated group-based intervention program, Mindfulness-Based Stress Reduction (MBSR), in the context of SD-related tasks and assess whether it helps developers to improve their well-being and performance, as well as the quality of the SD-related artifacts they produce.

MSR4SBOM (Mining Software Repositories for enhanced Software Bills of Materials) is a project whose main goal is to deliver a framework that analyzes the content of software repositories and SBOMs to provide context-sensitive recommendations. The expected outputs are (i) a set of approaches and tools released as open-source projects, making them exploitable in industrial, academic, and open-source contexts; and (ii) replication packages of our empirical studies and repositories of datasets collected while developing, calibrating, and validating the MSR4SBOM approaches and tools.

In this paper, we present the results of a confirmation study on the impact of dead-method removal on the internal structure of source code, time to compile source code, and space to store compilation results (i.e., executable code). To that end, we cleaned up 23 open-source Java desktop applications hosted on GitHub from their dead methods, obtaining two versions: one with dead methods (i.e., original version) and another one without them (i.e., cleaned version). For each of these applications, we compared its versions (original and cleaned) and found that, after removing dead methods, the internal structure of source code significantly improves, while the time to compile source code significantly diminishes as well as the space to store compilation results. We also performed correlation analyses that allowed us to conclude that the more dead methods are removed, the greater the improvement to the internal structure of source code and the less space to store executable code.

In recent years, a growing interest has been in the adoption of medical web or mobile applications or more in general applications in the digital health (DHEAL) field. These applications are designed for a wide range of users, from novice to expert and also end-users with and without disabilities, without adequately considering their unique software security needs. In this short paper, we present the results of a Rapid Review (RR) to identify existing approaches and methods to assess User Experience (UX), usability, accessibility and/or security in DHEAL applications. This RR has been conducted in the context of a research project (“DHEAL-COM Digital Health Solutions in Community Medicine). Among the others, the objective of DHEAL-COM is to delve into the complex relationship between UX (and its variants, like usability and accessibility) and security, i.e., to understand to what extent the principle of acceptability in security is taken into account when developing DHEAL applications. The outcomes of our RR should provide evidence to the stakeholders involved in the DHEAL-COM project and to researchers and practitioners who work in the DHEAL context. The findings of our RR emerge from 39 papers and can be summarized as follows: (i) there are several methods to assess usability; (ii) the most common methods are focused only on common usability aspects and in a few cases these methods concerns accessibility and credibility of the content; (iii) there are several methods to assess security and most of them are dictated by legislative rules; (iv) although the difficulty in finding a compromise between usability and security is clear in many cases, there are neither solutions nor approaches to deal with both of them.

A Software Bill of Materials (SBOM) describes, in a structured, machine-readable format, the open-source and proprietary components that constitute a software product, including their licenses, versions, vendors, vulnerabilities, and dependency relationships. SBOMs enable practitioners to gain visibility into the software supply chain and monitor any risks associated with software security, licensing, and more. In this industry paper, we present the findings of 10 semi-structured interviews with practitioners with different roles in six different software companies operating in Italy, some of which being very large multinationals. The gathered information indicates that the adoption of SBOMs is low, yet the attention of the software industry to software supply chain-related challenges is high. A possible reason behind this outcome is that the software industry has limited knowledge of SBOMs and software supply chain regulations. Although some participants showed a growing interest in SBOMs, the Italian software industry seems to respond less promptly to this technology. We plan to use these results and those from past research to design a survey with practitioners to have a complete picture of SBOM usage in the software industry.

Test-Driven Development (TDD) is an agile software development approach. It promotes short cycles, composed of three phases each, to incrementally implement software functionality: Red, Green, and Refactor. In the Red Phase, the TDD developer writes a unit test for a small chunk of functionality not yet implemented and watches the test fail. In the Green Phase, the TDD developer writes production code to make the test pass as quickly as possible. Finally, in the refactor phase, the TDD developer “cleans” written code. In this demo paper, we present GAI4-TDD (Generative Artificial Intelligence for Test-Driven Development), a PyCharm plugin to support the Green Phase of TDD. Specifically, this plugin generates production code from the tests the TDD developer had written in the Red Phase so that the generated code makes these tests pass. Previous studies have shown that TDD can be beneficial not only in the “traditional” software development context but also in the Embedded Systems (ESs) development context. We preliminary assessed GAI4-TDD in the latter context through a laboratory empirical study on three ESs. We observed that in the greater part of the cases, GAI4- TDD generates production code that successfully implements the chunk of functionality required. A video showing GAI4- TDD in action is available at: https://youtu.be/30IDb-6NgS4.

Background: There are a number of academic courses in the Bachelor Program in Computer Science (CS) on the design of Web apps. Often the internal and external quality of the developed Web apps is not adequately taken into account. Aim: We aimed to (i) estimate the quality of Web apps developed by bachelor CS students in a Software Technologies for the Web (STW) course (a.y. 2021-22) and (ii) define a training plan (on the base of the results of the first step) for the students enrolled to this course for the a.y. 2022-23 to let them design and implement better Web apps, and (iii) experimenting the training plan by comparing the quality of Web apps developed in a.y. 2021-22 and a.y. 2022-23. Method: We designed a prospective empirical investigation to study STW with respect to the training of bachelor students with respect to the quality (internal and external) of the developed Web apps. Results: We observed that quality concerns are widespread in the code of the Web apps the STW students developed in the a.y. 2021-22. Therefore, we plan to ask the students of the a.y. 2022-23 to use in their development pipeline a Static Analysis Tool (SAT) to detect quality concerns in the developed Web apps and deal with them. This second step represents an ongoing stage of our research. Conclusions: Our preliminary outcomes suggest that students must be aware that quality is of primary relevance for the development of Web apps and prepared to use SAT in the development pipeline.

We present the results of an exploratory investigation to obtain preliminary evidence on the use of Test-Driven Development (TDD), an incremental approach to software development where tests are written before production code, to develop Embedded Systems (ESs). Specifically, we conducted two experiments in which we compared TDD with a non-TDD approach in terms of the external quality of ESs and developers’ productivity. In the experiments, we also gathered qualitative data to better understand the investigated phenomenon. We found that the external quality of the implemented solutions increases when using TDD as compared to a non-TDD approach, while there is not a substantial difference with respect to developers’ productivity. However, TDD is perceived as more difficult to apply than a non-TDD approach, and the development task is deemed more challenging with TDD.

Background: Software vulnerabilities are flaws in application source code that can be exploited to cause harm, hence companies must devise strategies to manage them.Aim: We want to understand how software vulnerabilities are managed in a big IT (Information Technology) service and consulting company like NTT Data.Method: We conducted a focus group involving six software professionals working at NTT Data and analyzed the gathered data through a thematic analysis approach.Results: We found that application security standards are defined based on the needs of the clients (i.e., companies that commissioned NTT Data the software to be developed) and the projects’ nature (i.e., the development of greenfield projects vs. maintenance of existing ones). Also, to detect software vulnerabilities, SAST (Static Application Security Testing) tools are mainly used; among these, SonarLint and SonarQube appear to be the de-facto standards for NTT Data. Finally, not all software vulnerabilities are fixed; for example, the presence of some software vulnerabilities is tolerated by the clients, who take on the responsibility of not removing these vulnerabilities.Conclusions: It seems that developers and NTT Data clients are not averse to securing their code. NTT Data follows the application security standards established with their clients. To detect software vulnerabilities, SonarLint and SonarQube appear to be the de-facto standards, so explaining to some extent the increasing attention on these tools by the software engineering research community.

We conducted a large-scale fine-grained empirical study in which we quantitatively analyzed the commit histories of 200 Open-Source (OS) Python software systems, whose software repositories were publicly available on GitHub, for a total of 164,980 commits analyzed. We focused on commits—this is why our study is considered fine-grained—to investigate the spread and evolution of security concerns. To detect security concerns at a commit level, we used SonarQube, a popular Static Application Security Testing (SAST) tool. We found, among other things, that: security concerns are spread in OS Python software systems (on average, about 11 security concerns per commit) and tend to survive more than a couple of weeks and a dozen commits; and critical security concerns, despite their high severity level, are the most spread and tend to survive the most. Also, we found that 47 different kinds of security concerns were introduced into the source code of the studied software systems, and the top eight (per number of introductions) are severe and account for 87% of all introduced security concerns. Python developers should pay more attention to security concerns, especially those critical, and use secure coding practices, automated tools, or even DevSecOps to avoid the introduction of security concerns into their source code or fix them as soon as possible.

A Software Bill of Materials (SBOM) is a complete, formally structured list of all the open-source and proprietary software components present in a software product, including their licenses, versions, and vendors. SBOMs enable software creators and consumers to gain visibility into the software supply chain and monitor any risks associated with security or licensing. Thereby, the United States Government and the European Union have brought SBOMs to the forefront of digital policy. In this paper, we present the results of an exploratory mining study that aims to investigate the adoption of SBOMs by open-source software projects. To that end, we mined GitHub to identify repositories that use SBOM generation tools developed by SPDX and CycloneDX, identifying a total of 186 public repositories adopting SBOMs. We found that the adoption of SBOMs is low, yet it has an increasing trend. Moreover, SBOM files are available in the repository or published release versions in 46% of the software projects analyzed. SBOMs are getting an increasing attention from software creators and consumers. There is a pressing need for organizations to update their software to meet the new standards required for the software supply chain.

Abstract Background.Dead code is a code smell. It can refer to code blocks, fields, methods, etc. that are unused and/or unreachable—e.g., if a method is unused and/or unreachable, it is a dead method. Past research has shown that the presence of dead code in source code harms its comprehensibility and maintainability. Nevertheless, there is still little empirical evidence on the spread of this code smell in the source code of commercial and open-source software applications. Aims.Our goal is to gather, through an exploratory study, empirical evidence on the spread and evolution of dead methods in open-source Java desktop applications. Method.We quantitatively analyzed the commit histories of 23 open-source Java desktop applications, whose software projects were hosted onGitHub. To investigate the spread and evolution of dead methods, we focused on dead methods detected at a commit level. The total number of analyzed commits in our study is 1,587. The perspective of our exploratory study is that of both practitioners and researchers. Results.We can summarize the most important take-away results as follows:(i)dead methods affect open-source Java desktop applications;(ii)dead methods generally survive for a long time before being “buried” or “revived;”(iii)dead methods that are then revived tend to survive less, as compared to dead methods that are then buried;(iv)dead methods are rarely revived; and(v)most dead methods are stillborn, rather than becoming dead later. Given the exploratory nature of our study, we believe that its results will help researchers to conduct more resource- and time-demanding research on dead methods and, in general, on dead code. Conclusions.We can conclude that developers should carefully handle dead code (and thus dead methods) since it is harmful, widespread, rarely revived, and survives for a long time in software applications.

Web apps are built by using a combination of HTML, CSS, and JavaScript. While building modern web apps, it is common practice to make use of third-party libraries and frameworks, as to improve developers’ productivity and code quality. Alongside these benefits, the adoption of such libraries results in the introduction ofJavaScript dead code, i.e., code implementing unused functionalities. The costs for downloading and parsing dead code can negatively contribute to the loading time and resource usage of web apps. The goal of our study is two-fold. First, we presentLacuna, an approach for automatically detecting and eliminating JavaScript dead code from web apps. The proposed approach supports both static and dynamic analyses, it is extensible and can be applied to any JavaScript code base, without imposing constraints on the coding style or on the use of specific JavaScript constructs. Second, by leveraging Lacuna we conduct an experiment to empirically evaluate the run-time overhead of JavaScript dead code in terms of energy consumption, performance, network usage, and resource usage in the context of mobile web apps. We applied Lacuna four times on 30 mobile web apps independently developed by third-party developers, each time eliminating dead code according to a different optimization level provided by Lacuna. Afterward, each different version of the web app is executed on an Android device, while collecting measures to assess the potential run-time overhead caused by dead code. Experimental results, among others, highlight that the removal of JavaScript dead code has a positive impact on the loading time of mobile web apps, while significantly reducing the number of bytes transferred over the network.

Background: Dead code is a code smell. It can refer to code blocks, variables, parameters, fields, methods, classes, etc. that are unused and/or unreachable. Aim: Results from past empirical studies indicate that dead code is widespread in both desktop and web-based software applications. Also, researchers have shown that both comprehensibility and maintainability of source code are negatively affected when dead code is present. Nevertheless, we still know little about maintenance operations involving dead code. Method: We conducted an exploratory empirical study on 13 open-source Java desktop applications, whose software projects were hosted on GitHub, to provide preliminary evidence on whether, and to what extent, developers modify dead code—more specifically, dead methods—when they deal with the maintenance of open-source Java desktop applications. Results: The most important results of our study can be summarized as follows: (i) developers modify dead methods; (ii) dead methods are modified to a different extent as compared to alive methods; (iii) developers spend time modifying dead methods that are removed in subsequent commits; and (iv) developers modify dead methods that are later revived to a different extent as compared to dead methods that are later removed. Conclusions: One of the conclusions of our study is: developers should remove dead methods, whose presence and purpose are not properly documented, to avoid unnecessary modifications to dead methods during the maintenance of software applications.

Background. Test-Driven Development (TDD) is an agile software development practice, which encourages developers to write “quick-and-dirty” production code to make tests pass, and then apply refactoring to “clean” written code. However, previous studies have found that refactoring is not applied as often as the TDD process requires, potentially affecting software quality.

The Software Engineering (SE) research community has been showing an increasing interest in peopleware, which refers to anything that has to do with the role of human factors in software development. Individuals’ personality is one of the human factors that can affect software development. In this paper, we present the results of a preliminary empirical study to understand whether there is a relationship between the personality traits (i.e., openness, conscientiousness, extraversion, agreeableness, and neuroticism) and productivity of undergraduate students in Computer Science (CS), and internal quality of the programs they developed in an implementation task. In our study, we involved 30 (last-year) undergraduate students in CS, who had to implement a series of features. Our results suggest that there are correlation relationships between some personality traits (i.e., conscientiousness, extraversion, and neuroticism) and software quality. As for productivity, we could not find any correlation relationship.

Regression testing wants to prevent that errors, which have already been corrected once, creep back into a system that has been updated. A naïve approach consists of re-running the entire test suite (TS) against the changed version of the software under test (SUT). However, this might result in a time-and resource-consuming process; e.g., when dealing with large and/or complex SUTs and TSs. To avoid this problem, Test Case Selection (TCS) approaches can be used. This kind of approaches build a temporary TS comprising only those test cases (TCs) that are relevant to the changes made to the SUT, so avoiding executing unnecessary TCs. In this paper, we introduce CATTO (Commit Adaptive Tool for Test suite Optimization), a tool implementing a TCS strategy for SUTs written in Java as well as a wrapper to allow developers to use CATTO within IntelliJ IDEA and to execute CATTO just-in-time before committing changes to the repository. We conducted a preliminary evaluation of CATTO on seven open-source Java projects to evaluate the reduction of the test-suite size, the loss of fault-revealing TCs, and the loss of fault-detection capability. The results suggest that CATTO can be of help to developers when performing TCS. The video demo and the documentation of the tool is available at: https://catto-tool.github.io/

Regression testing is a practice that ensures a System Under Test (SUT) still works as expected after changes have been implemented. The simplest approach for regression testing is Retest-all, which consists of re-executing the entire Test Suite (TS) on the changed version of the SUT. Retest-all could be expensive in case a SUT and its TS grow in size and, if resources are insufficient, its application could be impracticable. A Test Suite Reduction (TSR) approach aims to overcome these issues by reducing the size of TSs, while preserving their fault-detection capability. In this paper, we introduce and validate an approach for TSR based on a multi-objective evolutionary algorithm, namely, Non-dominated Sorting Genetic Algorithm II (NSGA-II). This approach seeks to reduce TSs by maximizing both statement coverage and diversity of test cases of the reduced TSs, while minimizing the size of the reduced TSs. We named this approach Genetic Algorithm for teSt SuitE Reduction (GASSER). To assess GASSER, we conducted an experiment on 19 versions of four software systems from a public dataset—i.e. Software-artifact Infrastructure Repository (SIR). We compared GASSER with nine baseline approaches. The comparison was based on the size of the reduced TSs and their fault-detection capability. The most important take-away result is that GASSER, as compared with the baseline approaches, reduces more the size of the TSs with a non-significant effect on their fault-detection capability. The results of our empirical assessment suggest that the application of multi-objective evolutionary algorithms and, in particular, NSGA-II might represent a viable means to deal with TSR.

Context:In empirical software engineering, crossover designs are popular for experiments comparing software engineering techniques that must be undertaken by human participants. However, their value depends on the correlation ($r$) between the outcome measures on the same participants. Software engineering theory emphasizes the importance of individual skill differences, so we would expect the values of$r$to be relatively high. However, few researchers have reported the values of$r$.Goal:To investigate the values of$r$found in software engineering experiments.Method:We undertook simulation studies to investigate the theoretical and empirical properties of$r$. Then we investigated the values of$r$observed in 35 software engineering crossover experiments.Results:The level of$r$obtained by analysing our 35 crossover experiments was small. Estimates based on means, medians, and random effect analysis disagreed but were all between 0.2 and 0.3. As expected, our analyses found large variability among the individual$r$estimates for small sample sizes, but no indication that$r$estimates were larger for the experiments with larger sample sizes that exhibited smaller variability.Conclusions:Low observed$r$values cast doubts on the validity of crossover designs for software engineering experiments. However, if the cause of low$r$values relates to training limitations or toy tasks, this affectsallSoftware Engineering (SE) experiments involving human participants. For all human-intensive SE experiments, we recommend more intensive training and then tracking the improvement of participants as they practice using specific techniques, before formally testing the effectiveness of the techniques.

In this paper, we conduct an empirical study aiming at investigating how personality traits can affect the productivity of software developers in the context of the distributed development of multi-platform apps within a software project stored in GitHub. Participants were 31 master’s students in Computer Science grouped in 13 teams. Data were gathered from the compilation of the IPIP-NEO-120 questionnaire, a largely adopted tool to estimate personality traits, and from the software projects. We analyzed the correlation between personality traits (and their facets) and the productivity metrics. The results of this preliminary study seem to reveal that the most productive participants are those with the highest scores for the personality traits of Agreeableness and Conscientiousness.

Background. Dead code is a code smell. It can refer to code blocks, fields, methods, etc. that are unused and/or unreachable. Empirical evidence shows that dead code harms source code comprehensibility and maintainability in software applications. Researchers have gathered little empirical evidence on the spread of dead code in software applications. Moreover, we know little about the role of this code smell during software evolution.

GitHub currently hosts more than 100 million public repositories. This has made it very popular to conduct Mining Software Repositories (MSR) studies. Researchers have been exploiting the information stored in GitHub (e.g., commits, pull requests, or issues) to investigate both developer- and project-related aspects. GitHub provides the REST API to make queries without cloning repositories. In this tool-demo paper, we highlight some issues we noticed when conducting an MSR study on GitHub by using the REST API and present G-Repo: a tool developed to support researchers when tackling these issues able to ease the creation of datasets for MSR studies. Also, we provide a manually-annotated dataset with information about the kind and the (spoken) languages of 1,500 repositories hosted on GitHub. A video showing the functioning of G-Repo is available at: https://youtu.be/mb9CIALBFZk.

Regression testing is an important activity that ensures a System Under Test (SUT) still works as expected after changes. Regression testing can be expensive in case of large Test Suites (TSs). Test Suite Reduction (TSR) approaches speed up regression testing by removing redundant test cases. These approaches can be classified as adequate or inadequate. Adequate approaches reduce TSs so that they completely preserve the test requirements (e.g., statement coverage) of the original TSs. Inadequate approaches produce reduced TSs that only partially preserve test requirements. An inadequate TSR approach is appealing when it leads to a higher reduction in TS size at the expense of a negligible loss in fault-detection capability. We defined an inadequate approach for TSR named GASSER (Genetic Algorithm for teSt SuitE Reduction). It is based on a multi-objective evolutionary algorithm, NSGA-II (Non-dominated Sorting Genetic Algorithm II). GASSER seeks to reduce TSs by maximizing both the statement coverage and diversity of test cases, and minimizing the size of the reduced TSs. We implemented GASSER in a Java prototype of a supporting tool and named it as the approach, namely GASSER. In this tooldemo paper, we present such a tool prototype as well as the results of a preliminary empirical study to assess the validity of both the approach and the tool prototype. A screen-cast of GASSER in action is available at https://youtu.be/20Uf1ugEvAQ.

Background. Regression testing is a practice that ensures a System Under Test (SUT) still works as expected after changes. The simplest regression testing approach is Retest-all, which consists of re-executing the entire Test Suite (TS) on the new version of the SUT. When SUT and its TS grow in size, applying Retest-all could be expensive. Test Suite Reduction (TSR) approaches would allow overcoming the above-mentioned issues by reducing TSs while preserving their fault-detection capability.

Researcher Bias (RB) occurs when researchers influence the results of an empirical study based on their expectations. RB might be due to the use of Questionable Research Practices (QRPs). In research fields like medicine, blinding techniques have been applied to counteract RB. We conducted an explorative qualitative survey to investigate RB in Software Engineering (SE) experiments, with respect to: (i) QRPs potentially leading to RB, (ii) causes behind RB, and (iii) possible actions to counteract RB including blinding techniques. Data collection was based on semi-structured interviews. We interviewed nine active experts in the empirical SE community. We then analyzed the transcripts of these interviews through thematic analysis. We found that some QRPs are acceptable in certain cases. Also, it appears that the presence of RB is perceived in SE and, to counteract RB, a number of solutions have been highlighted: some are intended for SE researchers and others for the boards of SE research outlets.

Noise, defined as an unwanted sound, is one of the most common factors people have to deal with when performing their daily working tasks. Researchers have marginally investigated the effect of noise on software engineers' performance. In this paper, we present the results of two replicated experiments whose main goal was to increase the body of knowledge, by confirming or not the results of the baseline experiments, on the effect of noise while comprehending functional requirements specifications and fixing faults in source code. The results of the replicated experiments suggest that: (i) noise does not significantly affect the comprehension of functional requirements specifications and (ii) noise significantly and negatively affects fixing faults if this task lasts 30 minutes, while it does not have a significant impact if the task lasts 60 minutes. The results of the replications confirm to a large extent those of the baseline experiments and allow us to postulate, as done for the baseline experiments, that fixing faults is more vulnerable to noise than comprehending the specifications of functional requirements.

Researchers in the field of Software Fault Prediction (SFP) make use of software metrics to build predictive models, for example, by means of machine learning and statistical techniques. The number of metrics used for SFP has increased dramatically in the last few decades. Therefore, a taxonomy of metrics for SFP could be useful to standardize the lexicon, to simplify the communication among researchers/practitioners, and to organize and classify such metrics. In this research, we built a taxonomy of metrics for SFP with the aim of making it as comprehensive as possible. We exploited and extended two Systematic Literature Reviews (SLRs) to collect and classify a total of 512 metrics for SFP and then to build our taxonomy. We also provide information on the metrics in this taxonomy in terms of: acronym(s), extended name, description, granularity of the prediction, category, and research papers in which they were used. To allow the taxonomy to be constantly updated over time, we provide external contributors the possibility to ask for changes via pull-requests on GitHub.

Knowledge transfer is one of the main goals of modern code review, as shown by several studies that surveyed and interviewed developers. While knowledge transfer is a clear expectation of the code review process, there are no analytical studies using data mined from software repositories to assess the effectiveness of code review in "training" developers and improve their skills over time. We present a mining-based study investigating how and whether the code review process helps developers to improve their contributions to open source projects over time. We analyze 32,062 peer-reviewed pull requests (PRs) made across 4,981 GitHub repositories by 728 developers who created their GitHub account in 2015. We assume that PRs performed in the past by a developer D that have been subject to a code review process have "transferred knowledge" to D. Then, we verify if over time (i.e., when more and more reviewed PRs are made by D), the quality of the contributions made by D to open source projects increases (as assessed by proxies we defined, such as the acceptance of PRs, or the polarity of the sentiment in the review comments left for the submitted PRs). With the above measures, we were unable to capture the positive impact played by the code review process on the quality of developers' contributions. This might be due to several factors, including the choices we made in our experimental design.Additional investigations are needed to confirm or contradict such a negative result.

Test-Driven Development (TDD) is an incremental approach to software development. Despite it is claimed to improve both quality of software and developers’ productivity, the research on the claimed effects of TDD has so far shown inconclusive results. Some researchers have ascribed these inconclusive results to the negative affective states that TDD would provoke. A previous (baseline) experiment has, therefore, studied the affective reactions of (novice) developers—i.e., 29 third-year undergraduates in Computer Science (CS)—when practicing TDD to implement software. To validate the results of the baseline experiment, we conducted a replicated experiment that studies the affective reactions of novice developers when applying TDD to develop software. Developers in the treatment group carried out a development task using TDD, while those in the control group used a non-TDD approach. To measure the affective reactions of developers, we used the Self-Assessment Manikin instrument complemented with a liking dimension. The most important differences between the baseline and replicated experiments are: (i) the kind of novice developers involved in the experiments—third-year vs. second-year undergraduates in CS from two different universities; and (ii) their number—29 vs. 59. The results of the replicated experiment do not show any difference in the affective reactions of novice developers. Instead, the results of the baseline experiment suggest that developers seem to like TDD less as compared to a non-TDD approach and that developers following TDD seem to like implementing code less than the other developers, while testing code seems to make them less happy.

We present a quasi-experiment to investigate whether, and to what extent, sleep deprivation impacts the performance of novice software developers using the agile practice of test-first development (TFD). We recruited 45 undergraduates, and asked them to tackle a programming task. Among the participants, 23 agreed to stay awake the night before carrying out the task, while 22 slept normally. We analyzed the quality (i.e., the functional correctness) of the implementations delivered by the participants in both groups, their engagement in writing source code (i.e., the amount of activities performed in the IDE while tackling the programming task) and ability to apply TFD (i.e., the extent to which a participant is able to apply this practice). By comparing the two groups of participants, we found that a single night of sleep deprivation leads to a reduction of 50 percent in the quality of the implementations. There is notable evidence that the developers' engagement and their prowess to apply TFD are negatively impacted. Our results also show that sleep-deprived developers make more fixes to syntactic mistakes in the source code. We conclude that sleep deprivation has possibly disruptive effects on software development activities. The results open opportunities for improving developers' performance by integrating the study of sleep with other psycho-physiological factors in which the software engineering research community has recently taken an interest in.

Dead code is a bad smell and it appears to be widespread in open-source and commercial software systems. Surprisingly, dead code has received very little empirical attention from the software engineering research community. In this paper, we present a multi-study investigation with an overarching goal to study, from the perspective of researchers and developers, when and why developers introduce dead code, howthey perceive and cope with it, and whether dead code is harmful. To this end, we conducted semi-structured interviews with software professionals and four experiments at the University of Basilicata and the College of William & Mary. The results suggest that it is worth studying dead code not only in the maintenance and evolution phases, where our results suggest that dead code is harmful, but also in the design and implementation phases. Our results motivate future work to develop techniques for detecting and removing dead code and suggest that developers should avoid this smell.

In this study, we collected evidence from empirical studies published over two decades-from 1995 to 2018-to answer the following general research question: "What is the current existing empirical evidence concerning the use of software modeling to support source code maintenance?" We carried out a systematic literature review on research published in relevant journals, as well as conference and workshop proceedings, to investigate various aspects of our general research question. Although there is a common belief that software models are beneficial for source code maintainability, this aspect has been scarcely investigated in the literature and only a few empirical studies have been conducted in an industrial context. Moreover, most of the used models are UML. As so, our study shows that there is a small body of research related to this field.

When committing source code in a Version Control System (VCS) as a consequence of a bug fixing task, a good practice should consist in writing a message that shortly explains how the bug has been fixed. In this paper, we empirically assess a heuristic based on the presence of keywords in developers' commit messages, while uploading their changes to source code classes on GitHub. A class is fault-prone if it is involved in a commit, whose message contains keywords that are related to bug-fixing tasks. After having analyzed all the commits between two consecutive releases of a software project, a class is labeled with the number of how many bug-fixing commits in which it was involved. We assessed whether our heuristic can be used to support the human annotating activity, by comparing the number of bugs provided by the popularity dataset of the PROMISE research repository with the one estimated through such heuristic. We considered the identification of (i) faulty source code classes (i.e., a class is faulty if it contains at least one fault) and (ii) the number of faults in source code classes. The average accuracy (i.e., the number of classes correctly identified as either faulty or not over the total number of classes) of our approach is 71%. As for the number of faults in source code classes, the concordance (i.e., the number of classes on which the heuristic correctly identifies the number of faults over the total number of classes) is 62% on average. Our proposal might support, but not replace, annotating activities when building datasets for fault prediction.

During the evolution of software, it could happen that the information in the comments and in the associated source code are not aligned, so hampering the execution of software evolution and maintenance tasks. This kind of misalignment is known as lack of coherence and it can happen for several reasons, e.g., programmers modify the intent of source code while executing a maintenance task without updating its comment accordingly. We study the problem of detecting a lack of coherence between comments and source code by exploiting Word Embeddings (WEs). We present four models based on WE and tested these models using six different WE variants through an experiment conducted on a publicly available dataset. Results are compared against a baseline. The most important outcome is: the considered models and WE variants are more efficient in terms of execution time while maintaining performance very close to the baseline. The explanation for such an improvement is that WEs are able to concentrate the important information in a more compact input representation.

Test suites tend to become large and complex after software evolution iterations, thus increasing effort and cost to execute regression testing. In this context, test suite reduction approaches could be applied to identify subsets of original test suites that preserve the capability of satisfying testing requirements and revealing faults. In this paper, we propose Multi-Objective test suites REduction (named MORE+): a three-dimension approach for test suite reduction. The first dimension is the structural one and concerns the information on how test cases in a suite exercise the under-test application. The second dimension is functional and concerns how test cases exercise business application requirements. The third dimension is the cost and concerns the time to execute test cases. We define MORE+ as a multi-objective approach that reduces test suites so maximizing their capability in revealing faults according to the three considered dimensions. We have compared MORE+ with seven baseline approaches on 20 Java applications. Results showed, in particular, the effectiveness of MORE+ in reducing test suites with respect to these baselines, i.e., significantly more faults are revealed with test suites reduced by applying MORE+.

Background: Noise, defined as an unwanted sound, is one of the commonest factors that could affect people's performance in their daily work activities. The software engineering research community has marginally investigated the effects of noise on software engineers' performance.

Background. Regression testing is conducted after changes are made to a system in order to ensure that these changes did not alter its expected behavior. The problem with regression testing is that it can require too much time and/or too many resources. This is why researchers have defined a number of regression testing approaches. Among these, Test Suite Reduction (TSR) approaches reduce the size of the original test suites, while preserving their capability to detect faults. TSR approaches can be classified as adequate or inadequate. Adequate approaches reduce test suites so that they completely preserve the test requirements (e.g., statement coverage) of the original test suite, while inadequate ones produce reduced test suites that partially preserve these test requirements.

Background: Test-Driven Development (TDD) is an agile software development practice, which is claimed to boost both external quality of software products and developers' productivity.

Rapid Type Analysis (RTA) is an algorithm for call graph construction, which is known to be fast and to well approximate virtual method calls. In this paper, we explore its use in the context of refactoring, namely we defined an approach that relies on RTA for the detection of the dead method smell in Java code. We implemented this approach in a prototype of supporting tool we named Dead Code Finder (DCF). We empirically assessed DCF (and the underlying approach) through an experiment on four open-source Java desktop application. We compared DCF with three baseline tools. The results indicate that DCF outperforms these baselines in terms of accuracy of the detected dead methods.

Regression testing is an important activity that can be expensive (e.g., for large test suites). Test suite reduction approaches speed up regression testing by removing redundant test cases. These approaches can be classified as adequate or inadequate. Adequate approaches reduce test suites so that they completely preserve the test requirements (e.g., code coverage) of the original test suites. Inadequate approaches produce reduced test suites that only partially preserve the test requirements. An inadequate approach is appealing when it leads to a greater reduction in test suite size at the expense of a small loss in fault-detection capability. We investigate a clustering-based approach for inadequate test suite reduction and compare it with well-known adequate approaches. Our investigation is founded on a public dataset and allows an exploration of trade-offs in test suite reduction. Results help a more informed decision, using guidelines defined in this research, to balance size, coverage, and fault-detection loss of reduced test suites when using clustering.

MetricAttitude [18] is a visualization approach implemented in an environment that provides a mental picture of an object-oriented software by means of polymetric views of classes. In this paper, we describe a qualitative investigation we have conducted with a focus group involving developers aiming at evaluating their viewpoint on the relevance of the support MetricAttitude provides to perform comprehension tasks on source code. This investigation also allowed us to gather information on the developers' opinion on the MetricAttitude features and its software visualization metaphors. The discussion was animated and participants provided a number of useful suggestions for improving the visualization. The tool was considered very useful, while some usability problems have to be addressed. Specifically, the information provided has to be further filtered to easier software comprehension tasks.

In this paper, we propose an approach that uses software metrics to comprehend attributes of a codebase: maintainability, reusability, or complexity. This approach is new because it uses gathered metrics as the basis to associate musical sounds to source code classes. These sounds are arranged to compose a melody that can be both visualized (as a musical score) and played. We named this new way to deal with a codebase: software musification. To prove the validity of our proposal, we show a sample of its application. The main goal of this paper is to show our promising idea and to present research achievements at the early stages of our research.

We carried out a family of controlled experiments to investigate whether the use of abbreviated identifier names, with respect to full-word identifier names, affects fault fixing in C and Java source code. This family consists of an original (or baseline) controlled experiment and three replications. We involved 100 participants with different backgrounds and experiences in total. Overall results suggested that there is no difference in terms of effort, effectiveness, and efficiency to fix faults, when source code contains either only abbreviated or only full-word identifier names. We also conducted a qualitative study to understand the values, beliefs, and assumptions that inform and shape fault fixing when identifier names are either abbreviated or full-word. We involved in this qualitative study six professional developers with 1--3 years of work experience. A number of insights emerged from this qualitative study and can be considered a useful complement to the quantitative results from our family of experiments. One of the most interesting insights is that developers, when working on source code with abbreviated identifier names, adopt a more methodical approach to identify and fix faults by extending their focus point and only in a few cases do they expand abbreviated identifiers.

In this paper, we present LifeBook, a Personal Information Management (PIM) system that handles information on events captured by all the user's devices. Our PIM retrieves events on the basis of both the user's context and event similarity, which is computed by exploiting an information retrieval technique. We aggregated together the similarity of content, location, time, and event type to relate and surf the events. To this aim, we propose a re-find interface enabling the user to search and visualize information already seen before, of which he remembers some context aspects, such as time and/or place. The events captured on different devices are stored on the cloud without user intervention. A preliminary quantitative and qualitative evaluation has been also conducted to assess the effectiveness of LifeBook. Results in terms of time, effort and relevance of the information provided suggest that LifeBook be a viable means to retrieve personal information. Participants in the empirical investigation also considered the tool appropriate for supporting information re-finding tasks.

Context: Test-driven development (TDD) is an agile practice claimed to improve the quality of a software product, as well as the productivity of its developers. A previous study (i.e., baseline experiment) at the University of Oulu (Finland) compared TDD to a test-last development (TLD) approach through a randomized controlled trial. The results failed to support the claims. Goal: We want to validate the original study results by replicating it at the University of Basilicata (Italy), using a different design. Method: We replicated the baseline experiment, using a crossover design, with 21 graduate students. We kept the settings and context as close as possible to the baseline experiment. In order to limit researchers bias, we involved two other sites (UPM, Spain, and Brunel, UK) to conduct blind analysis of the data. Results: The Kruskal-Wallis tests did not show any significant difference between TDD and TLD in terms of testing effort (p-value = .27), external code quality (p-value = .82), and developers' productivity (p-value = .83). Nevertheless, our data revealed a difference based on the order in which TDD and TLD were applied, though no carry over effect. Conclusions: We verify the baseline study results, yet our results raises concerns regarding the selection of experimental objects, particularly with respect to their interaction with the order in which of treatments are applied.

Concern localization refers to the process of locating code units that match a particular textual description. It takes as input textual documents such as bug reports and feature requests and outputs a list of candidate code units that are relevant to the bug reports or feature requests. Many information retrieval (IR) based concern localization techniques have been proposed in the literature. These techniques typically represent code units and textual descriptions as a bag of tokens at one level of abstraction, e.g., each token is a word, or each token is a topic. In this work, we propose a multi-abstraction concern localization technique named MULAB. MULAB represents a code unit and a textual description at multiple abstraction levels. Similarity of a textual description and a code unit is now made by considering all these abstraction levels. We combine a vector space model and multiple topic models to compute the similarity and apply a genetic algorithm to infer semi-optimal topic model configurations. We have evaluated our solution on 136 concerns from 8 open source Java software systems. The experimental results show that MULAB outperforms the state-of-art baseline PR, which is proposed by Scanniello et al. in terms of effectiveness and rank.

MetricAttitude is a visualization approach implemented in an environment that provides a mental picture by viewing an object-oriented software by means of polymetric views of classes (i.e., fine-grained). In this paper, we present an extension of MetricAttitude which visualizes a software by levels considering not only its class view but also its package views in terms of nested packages (i.e., coarse-grained). Packages are represented by using visual properties associated to Martin's metrics [15]. The new approach and its supporting visualization environment also allow showing relationships among packages.

In this paper, we present the results of a controlled experiment conducted to assess whether the presence of unreachable methods in source code affects source code comprehensibility and modifiability. A total of 47 undergraduate students at the University of Basilicata participated in this experiment. We divided the participants in two groups. The participants in the first group were asked to comprehend code base containing unreachable methods and implement five change requests in that code base. The participants in the second group were asked to accomplish exactly the same tasks as the participants in the first group, however, the source code provided to them did not contain any unreachable methods. The results of the study indicate that code comprehensibility is significantly higher when source code does not contain unreachable methods. However, we did not observe a statistically significant difference for code modifiability. From these results, we distill lessons and implications for practitioners as well as possible avenues for further research.

While performing regression testing, an appropriate choice for test case ordering allows the tester to early discover faults in source code. To this end, test case prioritization techniques can be used. Several existing test case prioritization techniques leave out the execution cost of test cases and exploit a single objective function (e.g., code or requirements coverage). In this paper, we present a multi-objective test case prioritization technique that determines the ordering of test cases that maximize the number of discovered faults that are both technical and business critical. In other words, our new technique aims at both early discovering faults and reducing the execution cost of test cases. To this end, we automatically recover links among software artifacts (i.e., requirements specifications, test cases, and source code) and apply a metric-based approach to automatically identify critical and fault-prone portions of software artifacts, thus becoming able to give them more importance during test case prioritization. We experimentally evaluated our technique on 21 Java applications. The obtained results support our hypotheses on efficiency and effectiveness of our new technique and on the use of automatic artifacts analysis and weighting in test case prioritization.

Engineering green software-intensive systems is critical in our drive towards a sustainable, smarter planet. The goal of green software engineering is to apply green principles to the design and operation of software-intensive systems. Green and self-greening software systems have tremendous potential to decrease energy consumption. Moreover, enterprise software can and should be re-thought to address sustainability issues using innovative business models, processes, and incentives. Monitoring and measuring the greenness of software is critical towards the notion of sustainable and green software. Demonstrating improvement is paramount for users to achieve and affect change. Thus, the theme of GREENS 2015 is Towards a Green Software Body of Knowledge. The GREENS workshop series brings together researchers and practitioners to discuss both the state-of-the-art and state-of-the-practice in green software, including novel ideas, research challenges, methods, experiences, and tools to support the engineering of sustainable and energy efficient software systems.

With object-oriented programming languages (e.g., Java or C#), the identification of unreachable source code may be very complex especially when working at method level. To deal with the detection of unreachable methods, we have defined an approach named DUM: Detecting Unreachable Methods. We implemented a prototype of a supporting software we named DUM-Tool. It works on Java byte-code and detects unreachable methods by traversing a graph-based representation of a subject software.

We present a new metaphor that takes advantages of concepts such as archipelagos, atolls, and palms. Each package of a software system is represented as an atoll that maintainers can navigate and interact with. Atolls that form an archipelago represent the entire system. Maintainers can pass from an atoll to another one, so understanding how the entire software and its packages are related with one another. Palms on an atoll graphically depict salient information of the classes contained in the package associated to that atoll. The metaphor has been implemented as a 3D interactive environment tool to allow a fine- and large-grained understanding of a subject software system implemented in Java. Finally, we have used our 3D environment on a number of open-source object-oriented software systems and the obtained results are preliminarily presented in this paper.

I have enhanced Metric Attitude. It is a visualization tool based on static analysis that provides a mental picture by viewing an object-oriented software system by means of polymetric views. In particular, we have integrated an Information Retrieval engine and named this new version of visualization tool as Metric Attitude++. It allows the user to formulate a textual query and to show on the visual representation of the subject software the elements that are more similar to that query. This could be useful in all those cases in which a user needs to identify (or to localize) features implemented in the source code. Several filters are also available to hide possibly irrelevant details and to ease the browsing and then the comprehension of a software system. Finally, we have applied Metric Attitude++ on a number of object-oriented software systems. In this paper, we report preliminary results of a quantitative study on a widely studied open-source software, namely JEdit. On the basis of our results it seems that Metric Attitude++ can be effectively applied to different kinds of source code comprehension tasks and to concept location in source code, in particular.

It has been estimated that about 2% of global carbon dioxide emissions can be attributed to IT systems. Green (or sustainable) computing refers to supporting business critical computing needs with the least possible amount of power. This phenomenon changes the priorities in the design of new software systems and in the way companies handle existing ones. In this paper, we present the results of a research project aimed to develop a migration strategy to give an existing software system a new and more eco-sustainable lease of life. We applied a strategy for migrating a subject system that performs intensive and massive computation to a target architecture based on a Graphics Processing Unit (GPU). We validated our solution on a system for path finding robot simulations. An analysis on execution time and energy consumption indicated that: (i) the execution time of the migrated system is less than the execution time of the original system; and (ii) the migrated system reduces energy waste, so suggesting that it is more eco-sustainable than its original version. Our findings improve the body of knowledge on the effect of using the GPU in green computing.

Design patterns are recognized as a means to improve software maintenance by furnishing an explicit specification of class and object interactions and their underlying intent [Gamma et al. 1995]. Only a few empirical investigations have been conducted to assess whether the kind of documentation for design patterns implemented in source code affects its comprehensibility. To investigate this aspect, we conducted a family of four controlled experiments with 88 participants having different experience (i.e., professionals and Bachelor, Master, and PhD students). In each experiment, the participants were divided into three groups and asked to comprehend a nontrivial chunk of an open-source software system. Depending on the group, each participant was, or was not, provided with graphical or textual representations of the design patterns implemented within the source code. We graphically documented design-pattern instances with UML class diagrams. Textually documented instances are directly reported source code as comments. Our results indicate that documenting design-pattern instances yields an improvement in correctness of understanding source code for those participants with an adequate level of experience.

There are a number of empirical studies that assess the benefit deriving from the use of documentation and models in the execution of maintenance tasks. The greater part of these studies are quantitative and fail to analyze the values, beliefs, and assumptions that inform and shape source code comprehensibility and maintainability. We designed and conducted a qualitative study to understand the role of source code comments and identifiers in source code comprehensibility and maintainability. In particular, we sought to understand how novice and young professional developers perceive comments and identifier names after they have inspected the system behavior visible in its user interfaces. Novice developers were 18 third-year Bachelor students in Computer Science. The young professional developers were 12 and had work experience in between 3 months and 2 and half years. The used qualitative methodological approach is ethnographic. We asked the participants to inspect the behavior of a Java application visible in its user interfaces and then to comprehend and modify the source code of that application. We immersed ourselves and participated to the study, while collecting data by means of contemporaneous field notes, audio recordings, and copies of various artifacts. From the collected data, we have identified insights into comprehension and maintenance practices. The main insights can be summarized as follows: (i) with respect to novice developers, professional developers prefer to deal with identifier names rather than comments, (ii) all the participants indicate as essential the use of naming convention techniques for identifiers, and (iii) for all the participants the names of identifiers are important and should be properly chosen. Summarizing, independently from the kind of developer, it is advisable to use naming convention techniques and to properly choose identifiers.

We carried out a controlled experiment and an external replication to investigate whether the use of requirement diagrams of the System Modeling Language (SysML) helps in the comprehensibility of requirements. The original experiment was conducted at the University of Basilicata in Italy with Bachelor students, while its replication was executed at the University of Gothenburg in Sweden with Bachelor and Master students. A total of 87 participants took part in the experiment and its replication. The achieved results indicated that the comprehension of requirements is statistically significant when requirements specification documents include requirement diagrams without any impact on the time to accomplish comprehension tasks. On the basis of our results, we also present and discuss possible implications from the practitioner and researcher perspectives.

Context: abbreviated and full-word identifier names in dealing with faults in source code. Goal: investigating whether the use of abbreviated identifier names affects the ability of novice professional software developers in identifying and fixing faults in Java code. Method: external replication. Results: the results of the original experiment (conducted on C code) were confirmed. Conclusions: the difference in using abbreviated and full-word identifiers is not statistically significant with respect to the time to complete a task and the number of faults identified and fixed.

MetricAttitude is a visualization tool based on static analysis that provides a mental picture by viewing an object-oriented software system by means of polymetric views. In this paper, we present a preliminary empirical investigation based on a questionnaire-based survey to assess Metric Attitude with respect to source code comprehension tasks. Participants involved in this study were Computer Science students and software professionals. The results suggest that Metric Attitude is a viable means to comprehend source code and that both kinds of participants in the empirical investigation considered it to be appropriate in source code comprehension.

Websites built using Web Content Management Systems (WCMSs) usually provide their users with three types of access structures to surf their contents: indexes of categories, breadcrumb trails, and sitemaps. In addition, to find contents of his/her interest, a user can perform more or less advanced full-text searches. In this paper we propose an automatic approach to extend the navigation structure of websites developed using WCMSs with Semantic Navigation Maps (SNMs), a complementary navigation structure that enables linking and navigating contents based on their lexical similarity. The approach uses an information retrieval technique (namely, Latent Semantic Indexing) to identify lexical similarities between textual contents, and a fuzzy clustering algorithm to form groups of similar web pages. For each page of the website, a set of navigation links towards pages showing similar content and a measure of such similarity is provided. The paper presents the approach to generate SNMs, an implementation for the Joomla! open source WCMS, and the results of an empirical evaluation involving two real world websites built using this WCMS.

Over the last few years, the software engineering community has proposed a number of modeling methods to represent functional requirements. Among them, use cases are recognized as an easy to use and intuitive way to capture and define such requirements. Screen mockups (also called user-interface sketches or user interface-mockups) have been proposed as a complement to use cases for improving the comprehension of functional requirements. In this article, we aim at quantifying the benefits achievable by augmenting use cases with screen mockups in the comprehension of functional requirements with respect to effectiveness, effort, and efficiency. For this purpose, we conducted a family of four controlled experiments, involving 139 participants having different profiles. The experiments involved comprehension tasks performed on the requirements documents of two desktop applications. Independently from the participants' profile, we found a statistically significant large effect of the presence of screen mockups on both comprehension effectiveness and comprehension task efficiency. No significant effect was observed on the effort to complete tasks. The main pragmatic lesson is that the screen mockups addition to use cases is able to almost double the efficiency of comprehension tasks.

We carried out a family of experiments to investigate whether the use of UML models produced in the requirements analysis process helps in the comprehensibility and modifiability of source code. The family consists of a controlled experiment and 3 external replications carried out with students and professionals from Italy and Spain. 86 participants with different abilities and levels of experience with UML took part. The results of the experiments were integrated through the use of meta-analysis. The results of both the individual experiments and meta-analysis indicate that UML models produced in the requirements analysis process influence neither the comprehensibility of source code nor its modifiability.

ICT accounts for approximately 2% of world CO2 emissions, a figure equivalent to aviation, according to Gartner estimates. In the remaining 98% software counts for both operationalizing the private sector in doing its business and the public sector in supporting the society, as well as delivering enduser applications that permeate personal life of individuals and families. Software can contribute to decrease power consumption (i.e., become greener) in at least two ways. First, by being more energy efficient, hence using fewer resources and causing fewer CO2 emissions. Second, by making its processes more sustainable, i.e. decreasing the emissions of governments, companies and individuals. To this end, enterprise software must be rethought to address sustainability issues and support innovative business models and processes. The special theme of the second edition of GREENS is “Leveraging energy efficiency to software users”. This workshop brings together software engineering researchers and practitioners to discuss the state-of-the-art and state-of-the-practice in green software, as well as research challenges, novel ideas, methods, experiences, and tools to support the engineering of sustainable and energy efficient software systems.

We carried out a controlled experiment to investigate whether the use of abbreviated identifier names affects the ability of novice software developers to identify and fix faults in source code. The experiment was conducted with 49 students in Computer Science. The results of the statistical analyses indicate that there was not a significant difference to identify and to fix faults, when source code contains either abbreviated and full-word identifier names. In other words, it seems that abbreviated identifiers provide the same information as full-word identifiers on the solution domain and the implementation.

Defect prediction approaches use software metrics and fault data to learn which software properties associate with faults in classes. Existing techniques predict fault-prone classes in the same release (intra) or in a subsequent releases (inter) of a subject software system. We propose an intra-release fault prediction technique, which learns from clusters of related classes, rather than from the entire system. Classes are clustered using structural information and fault prediction models are built using the properties of the classes in each cluster. We present an empirical investigation on data from 29 releases of eight open source software systems from the PROMISE repository, with predictors built using multivariate linear regression. The results indicate that the prediction models built on clusters outperform those built on all the classes of the system.

In this paper, we present a novel approach based on the distributed behavioral model proposed by Reynolds to simulate animal motion such as bird flocks and fish schools. Our proposal has been used to group similar source code classes and has been implemented in a prototype of a supporting system. The approach and the software prototype have been preliminarily assessed on six open source object-oriented software systems implemented in Java. The results indicate that our proposal is promising in source code comprehension and could be successfully applied in the architecture recovery field.

Modeling is a fundamental activity within the requirements engineering process and concerns the construction of abstract descriptions of requirements that are amenable to interpretation and validation. The choice of a modeling technique is critical whenever it is necessary to discuss the interpretation and validation of requirements. This is particularly true in the case of functional requirements and stakeholders with divergent goals and different backgrounds and experience. This paper presents the results of a family of experiments conducted with students and professionals to investigate whether the comprehension of functional requirements is influenced by the use of dynamic models that are represented by means of the UML sequence diagrams. The family contains five experiments performed in different locations and with 112 participants of different abilities and levels of experience with UML. The results show that sequence diagrams improve the comprehension of the modeled functional requirements in the case of high ability and more experienced participants.

In this paper, we present a visualization approach for the reverse engineering of object-oriented (OO) software systems and its implementation in MetricAttitude, an Eclipse Rich Client Platform application. The goal of our proposal is to ease both the comprehension of a subject system and the identification of fault-prone classes. The approach graphically represents a suite of object-oriented design metrics (e.g., Weighted Methods per Class) and "traditional" code-size metrics (e.g., Lines Of Code). To assess the validity of MetricAttitude and its underlying approach, we have conducted a case study on the framework Eclipse 3.5. The study has provided indications about the tool scalability, interactivity, and completeness. The results also suggest that our proposal can be successfully used in the identification of fault-prone classes.

Test prioritization techniques can be used to determine test case ordering and early discover faults in source code. Several of these techniques exploit a single objective function, e.g., code or requirements coverage. In this tool demo paper, we present MOTCP, a software tool that implements a multi-objective test prioritization technique based on the information related to the code and requirements coverage, as well as the execution cost of each test case. To establish users' and system requirements coverage, the MOTCP uses Latent Semantic Indexing to recover traceability links among application source code and requirements specifications. The test case ordering is then obtained by applying a non-dominated sorting genetic algorithm.

We present an approach based on a forest metaphor to ease the comprehension of evolving object oriented software systems. The approach takes advantages of familiar concepts such as forests of trees, sub-forest of trees, trunks, branches, leaves, and color of the leaves. In particular, each release of a software is represented as a forest that users (or software maintainers) can navigate and interact with. Users can pass from a release to another one, so understanding how the entire software and its classes evolve throughout the past releases. The approach has been implemented in a prototype of a 3D interactive environment. A preliminary empirical evaluation has been also conducted to assess that environment and the underlying approach.

Abstract In this paper we present an approach to automate the architecture recovery process of software systems. The approach is built on information retrieval and clustering techniques, and, in particular, uses Latent Semantic Indexing (LSI) to get similarities among software entities (e.g., programs or classes) and the k-means clustering algorithm to form groups of software entities that implement similar functionality. In order to improve computational time in the context of the software evolution and then reduce energy waste, the architecture recovery process can be also applied by using fold-in and fold-out mechanisms that, respectively, add and remove software entities to the LSI representation of the understudy software system. The approach has been implemented in a prototype of a supporting software system as an Eclipse plug-in. Finally, to assess the approach and the plug-in, we have conducted an empirical investigation on five open source software systems implemented using the programming languages Java and C/C++. In the investigation special emphasis has been also given to the effect of using the fold-in and fold-out mechanisms.

Background: In the modeling of object oriented software systems, the UML object diagrams are recognized very useful to complement class diagrams. However, up to now, there exists only one experiment [Torchiano 2004] that investigates this concern. Aim: To confirm or contradict the findings of the original experiment, we have conducted a replication and the achieved results have been presented in this paper. Both the replication and the original experiment have been conducted to investigate whether the use of object diagrams to complement class diagrams affects the comprehension of software systems. Method: The replication has been conducted with a group of 24 graduated subjects in Computer Science of the University of Basilicata. The experiment adopts a counterbalanced design, thus ensuring that each subject work on two comprehension tasks, experimenting each time class and object diagrams together or class diagrams alone. The comprehension on each task has been assessed using a questionnaire-based approach. In particular, we have measured the comprehension level of each subject using an information retrieval based approach that allowed us to get a balance between correctness and completeness of the answers. Results: The results show that the subjects significantly benefit from the use of object diagrams in the comprehension of software systems, thus confirming and strengthening the findings of the original experiment. Conclusions: It is advisable to complement the usual class diagrams with object diagrams to increase the understandability of software systems. To raise the generalizability of the results, replications of this study are necessary especially with professional software engineers

We propose an approach that leverages lexical information and fuzzy clustering to reduce the number of the design pattern instances that existing approaches based on structural information (i.e., navigating the dependencies among software elements) erroneously recover in source code. To assess the effectiveness of the techniques, we present the results of a case study conducted on four open source software systems implemented in java. The data analysis indicates that the use of lexical information and fuzzy clustering improves the correctness of the results achieved by existing design pattern recovery approaches based on structural information, while preserving the number of design pattern instances correctly identified.

The presence of dead code may affect the comprehensibility, the readability, and the size of source code so increasing the effort and the cost for maintenance. The elimination of dead code needs a huge cost and effort for recognizing and eliminating code that is not effectively used. The goal of this work consists in defining an approach based on the Kaplan Meier estimator to analyze dead code. The validity of the approach has been preliminarily assessed on a case study constituted of fifty-eight versions of five open source software systems implemented in Java. The results suggested that two out of the five systems where implemented avoiding as much as possible the introduction of dead code.

One of the most common comprehension activities undertaken by developers is concept location in source code. In the context of software change, concept location means finding locations in source code where changes are to be made in response to a modification request. Static techniques for concept location usually rely on searching the source code using textual information or on navigating the dependencies among software elements. In this paper we propose a novel static concept location technique, which leverages both the textual information present in the code and the structural dependencies between source code elements. The technique employs a textual search in that source code, which is clustered using the Border Flow algorithm, based on combining both structural and textual data. We evaluated the technique against a text search based baseline approach using data on almost 200 changes from five software systems. The results indicate that the new approach outperforms the baseline and that improvements are still possible.

A critical claim in software requirements regards the assertion that the team performances improve when media with higher richness levels are used. To investigate this claim, we have conducted a controlled experiment to compare traditional face-to-face communication, the richest medium, and a leaner medium, namely an advanced chat implementing a distributed version of Think-Pair-Square (i.e., a well known method for collaborative problem solving). The comparison has been performed considering the time needed to model functional requirements through a use case modeling technique. Since the only assessment of time could be meaningless, we have also analyzed the media effect on the quality of the produced use cases. The results indicate a significant difference in terms of time to model software requirements in favor of face-to-face communication with no significant impact on the quality.

In this paper, we present and discuss the results of an internal replication of a controlled experiment for assessing the effectiveness of including screen mockups when adopting Use Cases. The results of the original experiment indicate a clear improvement in terms of understandability of functional requirements when screen mockups are present with no significant impact on effort. The data analysis of the replication, conducted also in this case with undergraduate students, confirms the results of the original experiment with slight differences, thus confirming that screen mockups facilitate the understanding of requirements without influencing the effort. We also sketch here some issues related to the documentation and communication between experimenters

In order to increase stakeholders' comprehension on software requirements, Use Cases can be enhanced with screen mock-ups (i.e., GUI prototypes sketched with a special conceived graphical tool). However, the effort to write Use Cases augmented with screen mockups may increase, thus not justifying their adoption in the requirements engineering process.

In this paper we present the preliminary results of a controlled experiment to assess the contribution provided by the design patterns on the maintenance of source code. In particular, the study aimed at assessing the effort and the efficiency to perform maintenance operations in case design pattern instances are properly documented and provided to the maintainer. The context of the experiment is constituted of Master Students in Computer Science at the University of Basilicata. The preliminary analysis conducted on the gathered data revealed that the effort is significantly reduced in case design pattern instances are properly documented and provided to the subjects. Similarly, the efficiency is significantly better in case the documentation of design pattern instances is used to accomplish maintenance operations.

Reusing software by copying and pasting is a common practice in software development. This phenomenon is widely known as code cloning. Problems with clones are mainly due to the need of managing each duplication, thus increasing the effort to maintain software systems. Clone detection approaches generally take into account either the syntactic structure (e.g., Abstract Syntax Tree) or lexical elements (e.g., the signature of a function). In this paper we propose an approach to detect code clones, based on syntactic information enriched by lexical elements. To this end, we have defined a Tree Kernel function to compare Abstract Syntax Trees. A preliminary investigation has been also conducted to assess the validity of the proposed approach.

Clustering based approaches are generally difficult to use in practice since they need a significant human interaction for recovering software architectures, are conceived for a specific programming language, and very often do not use design knowledge (e.g., the implemented architectural model). In this paper we present a clustering based approach to recover the implemented architecture of software systems with a hierarchical structure and implemented with any object oriented programming language. The approach is based on the combination of structural and lexical dimensions. The structural dimension is used to decompose a software system into layers (i.e., horizontal decomposition), while the lexical dimension is then employed to partition each layer (i.e., vertical decomposition) into software modules. Layers are identified using a well known and widely employed link analysis algorithm, i.e., the Kleinberg algorithm, while Vector Space Model is used to vertically decompose the layers. To assess the approach and the underlying techniques, we also present a prototype of a supporting tool and the results from a case study conducted on subsequent versions of three open source Java software systems.

A number of clustering based approaches and tools have been proposed in the past to partition a software system into subsystems. The greater part of these approaches is semiautomatic, thus requiring human decision to identify the best partition of software entities into clusters among the possible partitions. In addition, some approaches are conceived for software systems implemented using a particular programming language (e.g., C and C++). In this paper we present an approach to automate the partitioning of a given software system into subsystems. In particular, the approach first analyzes the software entities (e.g., programs or classes) and then using Latent Semantic Indexing the dissimilarity between these entities is computed. Finally, software entities are grouped using iteratively the k-means clustering algorithm. The approach has been implemented in a prototype of a supporting software system as an Eclipse plug-in. Finally, to assess the approach and the plug-in, we have conducted an empirical investigation on three open source software systems implemented using the programming languages Java and C/C++.

Abstract This paper presents an approach to identify software layers for the understanding and evolution of software systems implemented with any object‐oriented programming language. The approach first identifies relations between the classes of a software system and then uses a link analysis algorithm (i.e. the Kleinberg algorithm) to group them into layers. Additionally to assess the approach and the underlying techniques, the paper also presents a prototype of a supporting tool and the results from a case study. Copyright © 2010 John Wiley & Sons, Ltd.

This paper describes the results of an external replication of an experiment for assessing whether the use of dynamic modeling influences the comprehension of software requirements. The results of the original experiment conducted in Italy did not confirm that there was a significant difference in the comprehension of software requirements when dynamic modeling is used. The goal of the replication was therefore to verify these findings with a group of more experienced students at the Universidad Politeacutecnica de Valencia (UPV) in Spain. The results shows that the use of dynamic modeling does significantly improve the comprehension of software requirements, thus providing evidence that dynamic modeling facilitates the interpretation and comprehension of requirements.

Concurrent versioning of source code is a common and well-established practice to manage concurrency and consistency within source code repository. Similarly to source code, software models are often the result of cooperative work by different software engineers, that need to update them even concurrently. Unfortunately, modeling tools rarely provide support for concurrency and consistency. On the other hand, the available concurrent versioning tools do not provide an adequate support for software models. In this paper we present COMOVER (COncurrent MOdel VERsioning), a tool that integrates software modeling features with versioning and concurrency management as well as model elements sharing and exchanging.

This paper presents an incremental approach to migrate COBOL non decomposable data-intensive applications based on files to a modern relational database management system. This approach has been defined and developed within a technology transfer project carried out in cooperation between the University of Salerno and a small industrial partner. The developed approach first reengineers the original database and then adapts the code of the legacy application to enable the communication with reengineered database. A wrapper enables the communication between the legacy code and the new database. To support the software engineer in the different phases of the defined approach an Eclipse plug-in has also been developed. Finally, both the plug-in and the approach have been assessed on a legacy system of our industrial partner.

Abstract This paper presents the research results of an ongoing technology transfer project carried out in cooperation between the University of Salerno and a small software company. The project is aimed at developing and transferring migration technology to the industrial partner. The partner should be enabled to migrate monolithic multi‐user COBOL legacy systems to a multi‐tier Web‐based architecture. The assessment of the legacy systems of the partner company revealed that these systems had a very low level of decomposability with spaghetti‐like code and embedded control flow and database accesses within the user interface descriptions. For this reason, it was decided to adopt an incremental migration strategy based on the reengineering of the user interface using Web technology, on the transformation of interactive legacy programs into batch programs, and the wrapping of the legacy programs. A middleware framework links the new Web‐based user interface with the Wrapped Legacy System. An Eclipse plug‐in, named MELIS (migration environment for legacy information systems), was also developed to support the migration process. Both the migration strategy and the tool have been applied to two essential subsystems of the most business critical legacy system of the partner company. Copyright © 2008 John Wiley & Sons, Ltd.

We propose a distributed inspection method that tries to minimise the synchronous collaboration among team members to identify defects in software artefacts. The approach consists of identifying conflicts on the potential defects and then resolving them using an asynchronous discussion before performing a traditional synchronous meeting. This approach has been implemented in a Web based tool and assessed through a controlled experiment with master students in Computer Science at the University of Salerno. The tool presented provides automatic merge and conflict highlighting functionalities to support the inspectors during the pre-meeting refinement phase and provides the moderator with information about the inspection progress as a decision support. The tool also supports a synchronous inspection meeting to discuss about unsolved conflicts. However, by analysing the data collected during a controlled experiment we found that this phase can often be skipped due to the fact that asynchronous discussion resolved most of the conflicts.

We present the results of two controlled experiments aimed at assessing MELIS (migration environment for legacy information systems), a tool developed within a technology transfer project to support the migration of COBOL legacy information systems to a J2EE web-enabled multi-tier target architecture. The first controlled experiment was conducted within an academic research laboratory with master students in Computer Science at the University of Salerno, while a replicated experiment was conducted in the laboratory of our partner company with both professional programmers and academic researchers. The results revealed that the use of MELIS decrease the time to migrate legacy systems to the web with respect to the use of traditional development tools. Also, less expert software engineers benefit more of the use of MELIS.

Abstract We present an approach based on Winner Takes All (WTA), a competitive clustering algorithm, to support the comprehension of static and dynamic Web applications during Web application reengineering. This approach adopts a process that first computes the distance between Web pages and then identifies and groups similar pages using the considered clustering algorithm. We present an instance of application of the clustering process to identify similar pages at the structural level. The page structure is encoded into a string of HTML tags and then the distance between Web pages at the structural level is computed using the Levenshtein string edit distance algorithm. A prototype to automate the clustering process has been implemented that can be extended to other instances of the process, such as the identification of groups of similar pages at content level. The approach and the tool have been evaluated in two case studies. The results have shown that the WTA clustering algorithm suggests heuristics to easily identify the best partition of Web pages into clusters among the possible partitions. Copyright © 2007 John Wiley & Sons, Ltd.

The correlation between the effort to develop a learning process and early size measures could be used to assess the usability of an employed tool. In particular, when the measures are obtained from the learning process specification and they are relevant effort indicators we can assert that the technical competences of instructional designers are not relevant for the tool usage. We present initial results of applying empirical analysis to confirm a previously usability study performed on the ASCLO-S (Adaptive Self consistent Learning Object SET) editor, a visual language based tool for developing adaptive learning processes.

We present an incremental approach to the migration of non decomposable COBOL applications to a Web-enabled multi-tier architecture. The relevant software components of the target architecture, namely the communication middleware and the generator of graphical user interfaces, are developed once for all in order to reduce the migration effort. An Eclipse plug-in has also been developed to support the software engineer in the migration of the graphical user interface and in the restructuring and wrapping of the original legacy code. A pilot project on a COBOL legacy system evolved during the last thirty years has been used to experiment the migration strategy and the plug-in

Banking legacy systems intensively exchange messages in electronic format. Such systems are, for their nature, difficult to update and maintain. As a consequence, the introduction of new types of messages is a hard task. Adding new functionalities requires custom coding and software reuse is seen as a key to obtain a better time-to-market factor, risk and cost reduction. In this paper we describe the architecture and part of the implementation of the SI.RE. Visual System, an Interbanking Network Information System that lets us generate gateways for the exchange of electronic messages among banking legacy systems and supports software reuse. In particular, the SI.RE visual system contains a Visual Programming Environment that allows us to obtain a rapid development of the message handling functions. This environment implements a Visual Programming Language UVG that allows a programmer to reuse COBOL routines.

We present the Component-Based Visual Environment Development (CB-VED) process for building visual language environments and introduce the Visual Language Desk (VLDesk) system supporting its implementation. The proposed approach is based on software reuse at different granularity levels and enables incremental development. The VLDesk exploits all the knowledge gained from the development of the Visual Language Compiler-Compiler tool extending its functionalities with many adjunctive features useful in the presented development process. One of the aims of this research consists of the application of software engineering techniques to the incremental development of visual language environments.