Context . Empathy, a key social skill, is essential for communication and collaboration in SE but remains an under-researched topic. Aims . This study investigates empathy in SE from practitioners’ perspectives, aiming to characterize its meaning, identify barriers, discuss practices to overcome them, and explore its effects. Method . A qualitative content analysis was conducted on 55 web articles from DEV and Medium, two communities widely used by practitioners. To strengthen our findings, we conducted a follow-up survey with empathy experts. Results . The study proposes a definition of empathy in SE, identifies barriers such as toxic culture and excessive technical focus, practices to foster empathy in teams, and outcomes, including improved collaboration, communication, and reduced anxiety, frustration, and stress. These findings are synthesized into a conceptual framework. Conclusion . Survey results indicate the framework is clear, valuable, and raises empathy awareness, with suggestions for improvements and integration into training. This study paves the way for improving team dynamics by addressing barriers and offering strategies to cultivate empathy. Future work will explore empathy’s broader implications in SE practice.

This is the Replicated Computational Results (RCR) Report for our TOSEM article “Exploring Empathy in Software Engineering: Insights from a Gray Literature Analysis of Practitioners’ Perspectives” where we present qualitative content analysis conducted on 55 web articles from DEV and Medium, two communities widely used by practitioners, and a follow-up survey with empathy experts. In this article, we introduced a conceptual framework of empathy in software engineering. As part of this RCR, we provide an empirical package with detailed guidelines to set up and replicate our study, as well as to interpret the results. We hope it can motivate and support future research on empathy and human aspects in software engineering by offering a reusable and transparent example of qualitative analysis involving gray literature and expert feedback. All related data and materials are openly available in the experimental package.

[Context]. Requirements Process Debt (RPD) refers to shortcomings or inefficiencies in the requirements engineering process. Through an industry-wide survey, the InsighTD project identified the causes of RPD, its effects, and practices for its prevention and mitigation. Another approach to exploring RPD is by examining grey literature (GL), i.e., sources that have not been formally published. One such source is the discourse of solution providers, a specific type of web content. Although this discourse can enhance the knowledge gained through empirical studies, no research has yet explored it. [Aims]. To investigate how public discourse has discussed the causes of RPD. [Research Method]. We elicited public discourse on RPD causes using predefined search strings on Google and Bing. We collected web addresses where discussions on RPD causes were found and applied content analysis procedures to examine the data. [Results]. Based on public discourse, we produced 128 codes for causes, 60 for effects of RPD, along with 93 preventive and 70 mitigation practices. These elements were categorized to reveal their relationships within the software development process. [Conclusion]. Our study expands the body of knowledge on RPD causes, demonstrating that GL can serve as a valuable complementary source.

Context . Technical debt (TD) prevention allows software practitioners to apply practices to avoid potential TD items in their projects. Aims . To uncover and prioritize, from the point of view of software practitioners, the practices that could be used to avoid TD items, the relations between these practices and the causes of TD, and the practice avoidance reasons (PARs) that could explain the failure to prevent TD. Method . We analyze data collected from six replications of a global industrial family of surveys on TD, totaling 653 answers. We also conducted a follow up survey to understand the importance level of analyzed data. Results . Most practitioners indicated that TD could be prevented, revealing 89 prevention practices and 23 PARs for explaining the failure to prevent TD. The article identifies statistically significant relationships between preventive practices and certain causes of TD. Further, it prioritizes the list of practices, PARs, and relationships regarding their level of importance for TD prevention based on the opinion of software practitioners. Conclusion . This work organizes TD prevention practices and PARs in a conceptual map and the relationships between practices and causes of TD in a Sankey diagram to help the visualization of the body of knowledge reported in this study.

Context: Technical debt (TD) can bring short-term benefits to software projects, but its presence is also associated with issues such as decreasing product quality. Recent literature has proposed indicator-based strategies for TD identification and different approaches for TD management, but most of them focused on the point of view of software developers. Little is still known about how project management practitioners actually discuss, experience, and manage TD. Goal: This work investigates, from the point of view of project management practitioners, how they commonly discuss, experience, and manage TD. Method: We mined, curated, and selected a total of 42 TD discussions on Stack Exchange Project Management (SEPM), totaling 583 messages. We analyzed this data set quantitatively and qualitatively. Results: The most commonly discussed types of debt are process and people, revealing 47 indicators for recognizing debt items. We also found 72 practices related to TD management. Conclusion: The perspective considered by project management practitioners to analyze the TD phenomenon is different from the one considered by other roles in the software development process. This work organizes the TD indicators and management practices identified in SEPM into a Sankey diagram, which may assist practitioners and serve as guidance for future research.

Context: Knowing the effects of technical debt (TD) can support software development teams in the prioritization of TD items to pay off. However, little is known about the relations between the effects of TD and TD payment practices. Having this knowledge can provide valuable information for decision making about which payment practice can be applied given the presence of specific effects of TD. Aims: To investigate, from the point of view of software practitioners, (i) which TD payment practices have been used when certain effects of the presence of debt are felt in software projects and (ii) the reasons for not paying debt items despite the effects they are causing to the project. Method: We analyze quantitatively and qualitatively data collected from a survey with 432 practitioners across four countries. Results: Among the identified relations, the practice "code refactoring" is commonly used to pay debt items off when the effects "delivery delay" and "rework" are felt in software projects. On the other hand, when practitioners face the TD effects "low external quality" and "delivery delay", ，they commonly justify the non- payment of the debt items indicating the need of "focusing on short term goals". Conclusion: We organize the relationship between TD effects, and payment practices and reasons for not eliminating debt items. All this information is structured in an alluvial diagram, which can facilitate the visualization of the identified relations.

Background: Little is known about the practices used for technical debt (TD) payment. The study of payment practices, as well as the reasons for not applying them, can help practitioners to control and manage TD items. Aims: To investigate, from the point of view of software practitioners, if TD items have been paid off in software projects, the practices that have been used to pay off TD and the reasons that hamper the implementation of these practices. Method: We analyzed - both quantitatively and qualitatively - a corpus of responses from a survey of 432 practitioners, from four countries, about the possibility of TD payment. Results: We found that, for most of the cases, TD items have not been eliminated from software projects. The main reasons for not paying off TD are lack of organizational interest, low priority on the debt, focus on short-term goals, cost, and lack of time. On the other hand, we identified that code refactoring, design refactoring, and update system documentation are the most used practices for TD payment. Practitioners also cited practices related to the prevention, prioritization, and creation of a favorable setting as part of TD payment initiatives. Conclusion: This paper summarizes the identified practices and reasons for not paying off debt items in a map. Our map reveals that the majority of payment practices are of a technical nature while the majority of reasons for not paying off debts are associated with non-technical issues.

Context: System modeling usually precedes coding activities during software development. Addressing model smells in the upfront can avoid their propagation to the source code. Technical debt (TD) affects several software development phases, including design, but little is still known about it at the modeling level. Goal: Investigate whether applying refactoring procedures in UML class diagrams improves the quality of the automatically generated code in terms of TD (code debt) reduction. Method: We perform three replications of an empirical study following the same protocol used in the original study, but with variations on the: (1) round- trip engineering tool, (2) code issue identification tool, and (3) analyzed class diagram. Each study considered two sets of refactoring tasks. The first applied successive model refactoring sessions in a class diagram and analyzed their resulting automatically generated code. The second applied successive code refactoring sessions and analyzed their resulting automatically generated model. Results: There is a weak relationship between the analyzed model smells and code issues. Round-trip engineering tools influence the presence of code issues. Lastly, code issues identification tools mostly consider code formatting problems, in detriment of design issues smells. Conclusion: Results confirm the findings of the original study and motivate further investigation on the correspondence between model smells and code issues to prevent code debt at the model level.

Background: The concept of technical debt (TD) describes a phenomenon that impacts software projects and makes them difficult to manage. In recent years, various techniques and best practices in terms of TD management were proposed and although important on its own this knowledge must be complemented with a broader comprehension of what causes TD and what are the effects of TD. This paper presents a replication of the InsighTD survey-a globally distributed family of industrial surveys on causes and effects of TD-and thus amplifies the InsighTD reach and expands its knowledge base. Objective: The research presented in this paper gives insight on the state of practice and understanding of the TD concept alongside with data on causes and effects of TD in the Serbian IT industry. Method: A nation-wide survey, as a part of the InsighTD initiative, was conducted in Serbia in order to obtain feedback from software industry practitioners. Results: In total 93 practitioners from the Serbian IT industry filled out the survey. The results indicate that the concept of TD is broadly distributed, but at the same time it is not widely accepted for use (only 35% of participants had some sort of practical experiences with projects that were TD aware). The top cited causes were: deadlines, ineffective project management, lack of experience, test not performed and misconduct. On the other side the most common effects of TD were: low maintainability, increased effort, rework and low external quality. Conclusion: The research presented in this paper confirms the original study findings that deadlines are the top cited cause of TD. It also identifies new causes of TD in the context of InsighTD, with misconduct being one of the most cited ones. Regarding the effects of TD this research differs in most of the top 10 identified effects from the original study but confirms the occurrence of some effects most cited.

Understanding TD causes can support development teams in defining actions that could be taken to prevent the occurrence of debt items. Understanding the effects of TD could aid in prioritization of TD items to pay off to minimize possible negative consequences for the project. Existing work has revealed 105 causes and 85 effects of TD, and this high number can make it difficult to make practical use of this information. Without a consolidated representation, we would need to rely on a set of tables and isolated pieces of data. In this work, we propose the use of cross-company probabilistic cause-effect diagrams to represent information about TD causes and effects. We hypothesize that such diagrams can be useful to support TD cause/effect analysis sessions and empirically investigate this issue. Results from a case study performed with 72 participants indicate that the diagrams are able to positively support the management of TD, making it easier to identify its causes and the effects of its presence. Most of the participants also agreed that, by using the proposed diagrams, they gain agility, productivity, performance, and effectiveness. Finally, 89% of the participants stated that the use of the diagrams helped them to identify causes and effects of TD that they would not have identified without their support.

Background: The presence of technical debt (TD) brings risks to a software project and makes it difficult to manage. Several TD management strategies have been proposed, but considering actions that could explicitly prevent the insertion of TD in the first place and monitor its effects is not yet a common practice. Thus, while TD management is an important topic, it is also worthwhile to understand the causes that could lead development teams to incur different types of debt as well as the effects of their presence on software projects. Aims: The objective of this work is twofold. First, we investigate the state of practice in the TD area including the status quo, the causes that lead to TD occurrence, and the effects of existing TD. Second, we present the design of InsighTD, a globally distributed family of industrial surveys on causes and effects of TD, and the results of its first execution. Method: We designed the InsighTD in joint collaboration with several TD researchers. It is designed to run as an incremental large scale study based on continuous and independent replications of the questionnaire in different countries. Results: This paper presents the first results of the first execution of the survey. In total, 107 practitioners from the Brazilian software industry answered the questionnaire. Results indicate that there is a broad familiarity with the concept of TD. Deadlines, inappropriate planning, lack of knowledge, and lack of a well-defined process are among the top 10 cited and most likely causes that lead to the occurrence of TD. On the other side, low quality, delivery delay, low maintainability, rework and financial loss are among the top 10 most commonly cited and impactful effects of TD. Conclusion: With InsighTD, we intend to reduce the problem of isolated investigations in TD that are not yet representative and, thus, build a continuous and generalizable empirical basis for understanding practical problems and challenges of TD.

Context: Several technical debt (TD) management strategies have been proposed, but considering actions that could prevent the insertion of TD in the first place is not yet a common practice. This is a point that deserves investigation because it is expected that TD prevention could be sometimes "cheaper" than TD repayment. Besides, TD prevention also helps other TD management activities, especially in catching inexperienced developers' 'not-so-good' solutions. Thus, while TD management is an important topic, it is also worthwhile to understand the motivations and factors that could lead development teams to incur different types of debt. Objective: To identify causes that lead to the occurrence of TD, investigate if these causes occur in isolation or in combination, understand if TD can be prevented, and investigate, in terms of effort, if it is better to prevent debt, or incur it and pay it off later. Method: An interview based case study was performed with software practitioners. The results were formulated based on a synthesis of the text fragments coded for each response. Results: We identified 57 causes that lead a development team to incur debt. For the majority of TD types, these causes occur in combination. It was also indicated that debt can be prevented, and it is better to work on prevention activities than to pay off debt later. Conclusion: Results allowed us to identify 57 causes that lead a development team to incur debt. These causes mostly occur in combination, not in isolation. It was also indicated that debt can be prevented, and it would be better to work on prevention activities than to pay off debt later.

The current scenario of software development is characterized by a wide adoption of agile methodologies, which define processes and practices that address a range of problems faced by development teams.However, there is still little information on how these methodologies deal with technical debt(TD).This work presents the results of a replicated survey(originally executed in Finland) whose goal was to investigate which agile practices and processes are sensitive to TD.Despite this replication allows different types of analysis, the focus of this paper will be on the analysis of the effects of the agile practices and processes on TD from the perspective of the Brazilian software industry, where the study was replicated.At total, 62 practitioners from different organizations answered the questionnaire.The results indicated that participants already had a good knowledge about TD, instances of TD reside in the software implementation and are caused due to deficiencies in its architecture, the size of a debt item is proportional to its impact on the project, and, refactoring and iteration have the most positive effect on TD.This replication also contributes to the investigated topic through the accumulation of evidence about the findings, thereby increasing the level of confidence in results.

Context: Mining software repositories has been used as an important tool to support software engineering research.Recent studies indicate that code comments are one of the most explored objects of analysis in the area.Objective: This work investigates how analysis of comments has been used to support software engineering activities by identifying its purposes, focuses, techniques, tools, evaluation methods, and the research type performed in the area.Method: We performed a systematic mapping study of the literature that considered papers from 1990 to 2016.Results: We analyzed 36 primary studies.The collected data pointed out that comment analysis has been used mainly for understanding and identifying the quality of software artifacts.The Dictionary/Vocabulary and Natural Language Processing are among the most used techniques, and most of them are performed in a semiautomatic way.We also organized a set of tools that have been used for mining software comments.Most of the primary studies are a solution proposal paper.Regarding evaluation methods, we found that experiments and case studies are the most considered.Conclusion: The results of this mapping study can help to identify points that still require further investigation in comment analysis research.

Context] The software engineering community considers the technical debt (TD) concept intuitive, because it facilitates discussion among team members about problems that can impact the software development.Personal opinions and experiences related to the concept have been published in blogs and other channels without any evaluation, originating the TD Folklore.[Goal] This work aims to investigate TD Folklore statements classifying them by agreement and consensus.Besides, we also investigated if software development experience affects the perception of developers.[Method] We replicated a survey to evaluate TD Folklore statements.In the replication, we increased the number of respondents and added a new research question to analyze the difference of opinions between participants with and without software experience.[Results] At total, the survey was answered by 107 respondents.The list of TD Folklore was reorganized by the ranking of agreement and consensus indicated by participants.We also identified that professional experience does not change the participants´ perception on the concept of TD for the most cases.[Conclusion] We believe that TD Folklore can help researchers and practitioners identify gaps for new research efforts.

Technical debt (TD) refers to likely long-term costs associated with software development shortcuts taken by programmers to achieve short-term business benefits. If a development team does not manage TD, it can cause significant long-term problems such as high maintenance costs. Management strategies monitor debt items and evaluate when and if they should be paid. In order to effectively support this task, the systematic use of decision criteria can be decisive. In this context, this paper presents a strategy for TD management that uses multiple decision criteria to decide when to pay debt items off. In addition, it presents a case study that assessed the feasibility of the proposed strategy regarding its usefulness, ease of use and self-predicted future use. The results provided positive evidence on the use of the proposed strategy, indicating (i) that it can be useful in supporting TD management activities and (ii) that it can bring gains in terms of productivity, performance, and efficacy when evaluating the desirable time to pay debt items off.

Context: Many theories in health care and business administration seek answers to the fundamental question of why people behave the way they do. The Theory of Reasoned Action (TRA) is a theory that focuses on a person's intention to behave a certain way. An intention is a plan or a likelihood that someone will behave in a particular way in specific situations and driven by what is believed -- whether or not they actually do so. Belief is a state of mind that embodies trust and confidence in something. In this context, actions are driven by what is believed, by what is assumed to be true about the world. Objective: Our aim is to study and characterize a belief system by applying TRA to agile software project teams in terms of origins, sources and impacts of beliefs on self-management development practices. Method: An ethnographic case study was conducted. A set of interviews and observations on origins and impacts of beliefs in self-management practices was conducted over years with professionals from different project teams. Results: The results showed the strong influence of past experiences and organizational contexts on self-management practices of agile teams and pointed out some key issues. Thus, this study contribute to an improved understanding on how to apply behavioral theories to study software practices. Conclusion: This study showed that ethnographic methods are quite useful to understand software practice. The study also demonstrated that it is possible to capture and represent a belief system in a software project context.

Context: The concept of code smells is widespread in Software Engineering. However, in spite of the many discussions and claims about them, there are few empirical studies to support or contest these ideas. In particular, the study of the human perception of what is a code smell and how to deal with it has been mostly neglected. Objective: To build empirical support to understand the effect of god classes, one of the most known code smells. In particular, this paper focuses on how conceptualization affects identification of god classes, i.e., how different people perceive the god class concept. Method: A controlled experiment that extends and builds upon another empirical study about how humans detect god classes [19]. Our study: i) deepens and details some of the research questions of the previous study, ii) introduces a new research question and, iii) when possible, compares the results of both studies. Result: Our findings show that participants have different personal criteria and preferences in choosing drivers to identify god classes. The agreement between participants is not high, which is in accordance with previous studies. Conclusion: This study contributes to expand the empirical data about the human perception of code smells. It also presents a new way to evaluate effort and distraction in experiments through the use of automatic logging of participant actions.

It is believed that people consider the implications of their actions and act based on a reasonable assessment of those implications. In this context, belief can be defined as a state of mind that embodies trust and confidence in something. So, behavior is driven by what is believed, by what is culturally assumed to be true about the world. Our work aims to study and characterize a belief system of software project teams to understand the beliefs underlying an intention or practice, and seek answers about how people progress from intention to behavior in software engineering environments. We applied a behavioral theory in terms of organizational and team level factors associated to beliefs about the software development practices. A set of interviews on origins, sources and impacts of beliefs on software practices was conducted with professionals from different project teams and companies. The results point out a strong influence of past experiences and repeated behavior on software development practices of project teams. Also, we list a set of practical recommendations for software companies that are dealing with the challenges of adopting new practices on software projects.

Program comprehension is an essential activity to perform software maintenance and evolution. Comprehensibility often encompasses the analysis of individual logical units, called features, which are often scattered through many program modules. Understanding how the feature code is implemented along the software evolution history is essential, for instance, to perform refactoring activities. However, existing tools do not provide means to comprehend the feature code evolution. To overcome this shortcoming, this paper presents a tool called Source Miner Evolution (SME) that provides multiple interactive and coordinated views to comprehend feature code evolution. SME implements a feature-sensitive comparison of multiple program versions. Our usability assessment with experienced developers indicated that SME allows them to efficiently perform recurring comprehension tasks on evolving feature code. The developers' performance was influenced by the combination of visual SME mechanisms, such as colors, tool tips and menu-popup interactions over the features' code elements.

Ethnography is about the adoption of a cultural lens to observe and interpret events, actions, and behaviors, ensuring that they are placed in a relevant and meaningful context. Using this approach, it is possible to capture and analyze software development practices. Our aims are to illustrate the use of an ethnographic approach in a case study of agile software development adoption, to discuss the methodological challenges involved, and to provide support to others who conduct ethnographic studies of software practice. An ethnographic case study was conducted, employing participant observation, interviews, and document analysis. Difficulties and decisions were recorded and compared with those encountered in the literature. Finally, key challenges and guidelines to tackle them were discussed and documented. We identified five key challenges of applying ethnography to the study of software practices: (a) working in collaboration with and having something to offer to the participating company; (b) the insider/outsider dynamic of participant observation; (c) the balance between participant listening and participant observation; (d) the researcher's relationship with the participants; and (e) the rigor in qualitative work that involves the dilemma of the contextualization to be sufficiently broad and detailed. This study shows that ethnographic methods are indispensible when trying to understand software practice, and that the fundamental challenge for the researcher is to balance the role of participant observer with rigorous fieldwork.

Program comprehension is a key activity through maintenance and evolution of large-scale software systems. The understanding of a program often requires the evolution analysis of individual functionalities, so-called features. The comprehension of evolving features is not trivial as their implementations are often tangled and scattered through many modules. Even worse, existing techniques are limited in providing developers with direct means for visualizing the evolution of features' code. This work presents a proactive and interactive visualization strategy to enable feature evolution analysis. It proactively identifies code elements of evolving features and provides multiple views to present their structure under different perspectives. The novel visualization strategy was compared to a lightweight visualization strategy based on a tree-structure. We ran a controlled experiment with industry developers, who performed feature evolution comprehension tasks on an industrial-strength software. The results showed that the use of the proposed strategy presented significant gains in terms of correctness and execution time for feature evolution comprehension tasks.

Folklore and beliefs are strong in the software practitioners' community. Software engineering is a communication intensive activity. Software engineers are innovation driven and regularly use automated resources to share ideas, new paradigms and approaches to support and improve their practices. This information flow generates technical folklore and beliefs (that do not have a formal trial basis). Software engineers applying practices are influenced by these and they are inevitably taken on board in the adoption of a particular technology or practice. This paper presents an industrial case study, using a qualitative approach, to investigate the origins and impacts of beliefs on software development team practices. Its main contribution is on the understanding of creation and evolution of technical beliefs, and in studying its use for team practices improvement in the software engineering industry.

The number of scientific publications is constantly increasing, and the results published on Empirical Software Engineering are growing even faster. Some software engineering publishers have began to collaborate with research groups to make available repositories of software engineering empirical da

Open Source Software (OSS) mailing lists are used by developers to discuss software engineering tasks performed in the project. In the last years, researchers have been conducting mailing lists linguistic analyses for understanding the intricacies of OSS development. An unpublished approach for that is to use NeuroLinguistic Theory (NT). NT postulates the use of a Preferred Representational cognitive System (PRS) in specific contexts. This means that different resources and cognitive channels are used by developers in order to understand software, but what types of representational systems are the preferred by software engineers? This paper introduces a psychometrically-based neuro-linguistic analysis tool to classify developers, and presents early results of an experiment to assess the PRS of four top developers against a baseline of the Apache server mailing list.

Modern IDE provides several resources to visually represent and explore the software. Nonetheless, there is limited empirical evidence of how those resources are utilized in specific software engineering activities. This has led to several studies to characterize the usage of IDE resources. The majority of these studies rely on methods that are costly and time consuming. This paper proposes a visual approach to help the characterization of IDE usage during software maintenance activities. It works by gathering data for all primitive operations performed by the programmers on the IDE, registering it in a log file and presenting the information abstracted from this log in an interactive visual interface. The interface transforms the fine-grained log data into meaningful information to represent how programmers use the IDE resources.

This paper presents a tool named CRISTA that supports code comprehension through the application of stepwise abstraction. It uses a visual metaphor to represent the code and supports essential tasks for code reading, inspection and documentation. As code comprehension is time consuming, a tool can greatly improve such activity.

Data quality is one of the bases for effective data mining. Flexible, consistent and extensible data storage is one of the requirements for effective data analysis. For more than 15 years, researchers in the database and decision making world have been studying the construction of data repositories for data analysis. Named data warehouses, these repositories are historical databases, which are separated both logically and physically from the organization production environment and designed to store data gathered from this environment. Data warehousing also includes data selection, integration and organization approaches to make data easily accessible to the decision making process. Based on our previous experience with data warehousing for mining software repositories, this paper presents a Data Warehousing Approach for software development data analysis.

Modern IDEs offer built-in support for developing plug-ins. More recently, we have seen a growing number of plug-ins that offer non-conventional software visualization interfaces. They usually aim to help programmers to understand unfamiliar source code by representing it in visual structures such as trees, scatter-plots or graphs. Although very attractive visually, we need to know more about the effectiveness of these interfaces in conveying information to software engineers. In this paper, we propose an infrastructure to empirically evaluate how useful are non-conventional visual paradigms in supporting software comprehension activities. The results for the first pilot study indicated that our experimental environment was consistent and could move to a full scale controlled experiment.

Experimental replications are very important to the advancement of empirical software engineering. Replications are one of the key mechanisms to confirm previous experimental findings. They are also used to transfer experimental knowledge, to train people, and to expand a base of experimental evidence. Unfortunately, experimental replications are difficult endeavors. It is not easy to transfer experimental know-how and experimental findings. Based on our experience, this paper discusses this problem and proposes a Framework for Improving the Replication of Experiments (FIRE). The FIRE addresses knowledge sharing issues both at the intra-group (internal replications) and inter-group (external replications) levels. It encourages coordination of replications in order to facilitate knowledge transfer for lower cost, higher quality replications and more generalizable results.

The software engineering research community has been adopting systematic reviews as an unbiased and fair way to assess a research topic. Despite encouraging early results, a systematic review process can be time consuming and hard to conduct. Thus, tools that help on its planning or execution are needed. This article suggests the use of Visual Text Mining (VTM) to aid systematic reviews. A feasibility study was conducted comparing the proposed approach with a manual process. We observed that VTM can contribute to Systematic Review and we propose a new strategy called VTM-Based Systematic Review.

Experience management refers to the capture, structuring, analysis, synthesis, and reuse of an organization's experience in the form of documents, plans, templates, processes, data, etc. The problem of managing experience effectively is not unique to software development, but the field of software engineering has had a high-level approach to this problem for some time. The Experience Factory is an organizational infrastructure whose goal is to produce, store, and reuse experiences gained in a software development organization. This paper describes The Q-Labs Experience Management System (Q-Labs EMS), which is based on the Experience Factory concept and was developed for use in a multinational software engineering consultancy. A critical aspect of the Q-Labs EMS project is its emphasis on empirical evaluation as a major driver of its development and evolution. The initial prototype requirements were grounded in the organizational needs and vision of Q-Labs, as were the goals and evaluation criteria later used to evaluate the prototype. However, the Q-Labs EMS architecture, data model, and user interface were designed to evolve, based on evolving user needs. This paper describes this approach, including the evaluation that was conducted of the initial prototype and its implications for the further development of systems to support software experience management.

Software organizations are in need of methods to understand, structure, and improve the data their are collecting. We have developed an approach for use when a large number of diverse metrics are already being collected by a software organization (M.G. Mendonca et al., 1998; M.G. Mendonca, 1997). The approach combines two methods. One looks at an organization's measurement framework in a top-down goal-oriented fashion and the other looks at it in a bottom-up data-driven fashion. The top-down method is based on a measurement paradigm called Goal-Question-Metric (GQM). The bottom-up method is based on a data mining technique called Attribute Focusing (AF). A case study was executed to validate this approach and to assess its usefulness in an industrial environment. The top-down and bottom-up methods were applied in the customer satisfaction measurement framework at the IBM Toronto Laboratory. The top-down method was applied to improve the customer satisfaction (CUSTSAT) measurement from the point of view of three data user groups. It identified several new metrics for the interviewed groups, and also contributed to better understanding of the data user needs. The bottom-up method was used to gain new insights into the existing CUSTSAT data. Unexpected associations between key variables prompted new business insights, and revealed problems with the process used to collect and analyze the CUSTSAT data. The paper uses the case study and its results to qualitatively compare our approach against current ad hoc practices used to improve existing measurement frameworks.