Abstract: Software sustainability has been a trending topic in the last decade in academia. Studies related to software sustainability propose models, frameworks, or practices that can be applied in the industry. But most of these proposals are still not systematically adopted in the industry. Therefore, there is an opportunity to create a structured meeting to support the concrete adoption of sustainability practices in software development. This paper aims to provide an overview of these frameworks and how they can help facilitate sustainability-driven meetings (SusDM). Seeking this, we present practical examples and a workflow to prepare the meeting by applying the existing sustainability frameworks in SusDM. As a position paper, our hypothesis is that the contributions of this meeting may be related to improving the knowledge of software developers on sustainable software engineering, discovering new sustainability requirements, prioritization, and implementing software sustainability prac (More)

Software security is a complex topic, and for development projects it can be challenging to assess what security is necessary and cost-effective. Agile Software Development (ASD) values self-management. Thus, teams and their Product Owners are expected to also manage software security prioritisation. In this paper we build on the notion that security experts who want to influence the priority given to security in ASD need to do this through interactions and support for teams rather than prescribing certain activities or priorities. But to do this effectively, there is a need to understand what hinders and supports teams in prioritising security. Based on a longitudinal case study, this article offers insight into the strategy used by one security professional in an SME to influence the priority of security in software development projects in the company. The main result is a model of influences on security prioritisation that can assist in understanding what supports or hinders the prioritisation of security in ASD, thus providing recommendations for security professionals. Two alternative strategies are outlined for software security in ASD – prescribed and emerging – where we hypothesise that an emerging approach can be more relevant for SMEs doing ASD, and that this can impact how such companies should consider software security maturity.

Software security needs to be a continuous endeavour in current software development practices. Frequent software updates, paired with an ongoing flow of security breaches, requires software companies to address software security throughout development and post deployment. Prescriptive software security approaches do not match well with agile software development and its emphasis on self-management. Agile approaches are however in favour of meetings as a coordination and problem-solving strategy. This article investigates the role of regular security meetings centred on making security priorities and decisions for achieving continuous software security. Through technical action research and an observational case study, we studied variations of such meetings in three companies. We found that such meetings can reach key stakeholders, make security more visible, and contribute to ongoing security prioritisation. Thus, security meetings are a promising approach, especially for small and medium sized development companies with basic yet immature security competence. Future research should investigate further the role of such meetings and how best to organise them for different contexts and needs. For this we outline implications for research and practice, e.g., related to participants and how to organise the discussions and prioritisations in the meeting.

Today's software development projects need to consider security as one of the qualities the software should possess. However, overspending on security will imply that the software will become more expensive and often also delayed. This paper discusses the role of objectivity in assessing and researching the goal of good enough security. Different understandings of objectivity are introduced, and the paper explores how these can guide the way forward in improving judgements on what level of security is good enough. The paper recommends adopting and improving upon methods that include different perspectives, support the building of interactive expertise, and support confirmability by keeping documentation of the basis on which judgements were made.

Background: Software engineering work and its context often has characteristics of what in social science is termed 'messy'; it has ephemeral and irregular qualities. This puts high demands on researchers doing inquiry and analysis. Aims: This paper aims to show what a combination of situational analysis (SA) and narrative analysis (NA) can bring to qualitative software engineering research, and in particular for situations characterised by mess. Method: SA and NA were applied to a case study on software security. Results: We found that these analysis methods helped us gain new insights and understandings and a broader perspective of the situation we are studying. Additionally, the methods helped collaboration in the analysis. Conclusion: We recommend applying and studying these and similar combinations of analysis approaches further.

To achieve a level of security that is just right, software development projects need to strike a balance between security and cost. This necessitates making such decisions as to what security activities to perform in development and which security requirements should be given priority. Current evidence indicates that in many agile development projects, software security is dealt with in a more or less "accidental" way based on individuals' security awareness and interest. This approach is unlikely to lead to an optimal security level for the product. This paper suggests Security Intention Recap Meetings as a recurring organisational tool for evaluating current practices regarding the security intentions of a software project, and to make decisions on how to move forward. These meetings involve key decision makers in the project, such as the product owner and the project manager, with the purpose of making security decisions visible and deliberate and to monitor their results

Purpose Today, agile software development teams in general do not adopt security risk-assessment practices in an ongoing manner to prioritize security work. Protection Poker is a collaborative and lightweight software security risk-estimation technique that is particularly suited for agile teams. Motivated by a desire to understand why security risk assessments have not yet gained widespread adoption in agile development, this study aims to assess to what extent the Protection Poker game would be accepted by agile teams and how it can be successfully integrated into the agile practices. Design/methodology/approach Protection Poker was studied in capstone projects, in teams doing a graduate software security course and in sessions with industry representatives. Data were collected via questionnaires, observations and group interviews. Findings Results show that Protection Poker has the potential to be adopted by agile teams. Key benefits include good discussions on security and the development project, along with increased knowledge and awareness. Challenges include ensuring efficient use of time and gaining impact on the end product. Research limitations/implications Using students allowed easy access to subjects and an ability to collect rich data over time, but at the cost of generalizability to professional settings. Results from interactions with professionals supplement the data from students, showing similarities and differences in their opinions on Protection Poker. Originality/value The paper proposes ways to tackle the main obstacles to the adoption of the Protection Poker technique, as identified in this study.

Abstract Onboarding is the process of supporting new employees regarding their social and performance adjustment to their new job. Software companies have faced challenges with recruitment and onboarding of new team members, and there is no study that investigates it in a holistic way. In this paper, we conducted a multi‐case study to investigate the onboarding of software developers/teams, associated challenges, and areas for further improvement in 3 globally distributed legacy projects. We employed Bauer's model for onboarding to identify the current state of the onboarding strategies employed in each case. We learned that the employed strategies are semi‐formalized. Besides, in projects with multiple sites, some functions are executed locally, and the onboarding outcomes may be hard to control. We also learned that onboarding in legacy projects is especially challenging and that decisions to distribute such projects across multiple locations shall be approached carefully. In our cases, the challenges to learn legacy code were further amplified by the project scale and the distance to the original sources of knowledge. Finally, we identified practices that can be used by companies to increase the chances of being successful when onboarding software developers and teams in globally distributed legacy projects.

The DevOps paradigm means that development and operations for an organisation blend together. For security, this implies that information on detected attacks can be fed back to the development, enabling faster eradication of vulnerabilities in software. This is particularly important in cloud installations, where release cycles can be less than a day. This paper argues that DevOps can be employed for overall improved software security.

In order to be responsible stewards of other people's data, cloud providers must be accountable for their data handling practices. The potential long provider chains in cloud computing introduces additional accountability challenges, and this paper examines requirements which must be fulfilled to achieve an accountability-based approach.

Security testing can broadly be described as (1) the testing of security requirements that concerns confidentiality, integrity, availability, authentication, authorization, nonrepudiation and (2) the testing of the software to validate how much it can withstand an attack. Agile testing involves immediately integrating changes into the main system, continuously testing all changes and updating test cases to be able to run a regression test at any time to verify that changes have not broken existing functionality. Software companies have a challenge to systematically apply security testing in their processes nowadays. There is a lack of guidelines in practice as well as empirical studies in real-world projects on agile security testing; industry in general needs a more systematic approach to security. The findings of this research are not surprising, but at the same time are alarming. The lack of knowledge on security by agile teams in general, the large dependency on incidental pen-testers, and the ignorance in static testing for security are indicators that security testing is highly under addressed and that more efforts should be addressed to security testing in agile teams.

Non-functional requirements define the overall qualities or attributes of a system. Although important, they are often neglected for many reasons, such as pressure of time and budget. In agile software development, there is a focus on the feature implementation and delivery of value to the customer and, as such, non-functional aspects of a system should also be of attention. Non-functional requirements testing is challenging due its cross-functional aspects and lack of clarity of their needs by business in the most part of projects. The goal of this paper is to empirically investigate how do agile team members handle non-functional testing in their projects, aiming to identify preliminary factors influencing the testing of non-functional requirements, specifically performance and security in agile development. We conducted interviews with twenty IT professionals in large multinational company. As result we could identify seven main factors influencing non-functional testing and four main practices adopted by them to overcome the challenges faced. We aim to replicate our investigation in a larger scale. Meanwhile, our work provides initial contributions to practitioners and inspires our future research.

Organizations recognize that protecting their assets against attacks is an important business. However, achieving what is adequate security requires taking bold steps to address security practices within the organization. In the Agile software development world, security engineering process is unacceptable as it runs counter to the agile values. Agile teams have thus approached software security activities in their own way. To improve security within agile settings requires that management understands the current practices of software security activities within their agile teams. In this study, we use survey to investigate software security usage, competence, and training needs in two agile organizations. We find that (1) The two organizations perform differently in core software security activities but are similar when activities that could be leveraged for security are considered (2) regardless of cost or benefit, skill drives the kind of activities that are performed (3) Secure design is expressed as the most important training need by all groups in both organizations (4) Effective software security adoption in agile setting is not automatic, it requires a driver.

Software developers and testers have to work together to achieve the goals of software development projects. In globally distributed software projects the development and testing are often scattered across multiple locations forming virtual teams. Further, the distributed projects are so complex that none of team members can possibly possess all the knowledge about the project individually. During testing in such teams, developers and testers need to coordinate and communicate frequently. However, coordination is affected by the availability of the project information, which is distributed among different project members and organizational structures. Many companies are facing decisions about how to apply agile methods in their distributed projects. These companies are often motivated by the opportunities of solving the coordination and communication difficulties associated with global software development. In this paper we investigate the communication between testers and developers in two teams from two software companies performing continuous agile testing in a distributed setting. We describe four communication practices used by the team: handover through issue tracker system, formal meetings, written communication and coordination by mutual adjustment. We also discuss communication between testers and developers in collocated versus distributed testers and developers. We have found that early participation of the testers is very important to the success of the handover between testers and developers. The communication between developers and testers is not sufficiently effective through written communication and that it changes depending on the type of the tasks and experience of the testers.

Even though agile actively seeks collaboration from all its stakeholders, most agile projects do not extend themselves toward the operations people. To solve this problem, DevOps is introduced. DevOps is a conceptual framework for reintegrating development and operations of Information Systems, which is able to break the wall between developers and operations professionals. DevOps improves the work through a collection of principles and practices, centered around close collaboration between Development and Operations personnel. However, both sides have paid little attention to issues faced by each other. Communication gaps is a recurrent problem in agile teams that is also eminent in the relationship between developers and operations. Literature offers little research on this aspect of communication in DevOps. This position paper describes the communication practices from a distributed agile team composed of developers and operations based on communication challenges (geographical, socio-cultural, and temporal distance) and strategies (frequency, direction, modality, and content). From the results we outline possible research focus for future work, aiming to enrich the academia research on the matter as well as to help practitioners to improve their working practices.

Virtual teams, with a high level of interdependence and cooperation among team members, are one of the building blocks of successful global software organizations. Shared team knowledge is vital for effective collaboration in virtual teams. Hence, it makes sense for organizations to put in place efforts to ensure that teams have a sufficient level of shared knowledge. A successful agile virtual team needs to have shared knowledge on the tasks and how to do them, who knows what in the team, the development process, and the goals of the team. While shared knowledge helps on communication and collaboration, virtual teams meet several challenges in the form of values and norms, lack of face-to-face communication, time-zone differences, and difficulties in building and maintaining trust. We describe and discuss how a framework for establishing shared knowledge was applied to a global virtual agile team in a Product Centre at DNV GL -- an international provider of software for a safer, smarter and greener future in the energy, process and maritime industries. The whole group of 22 met face to face once a year, and we describe how they in one such team gathering worked on creating shared understanding about the task, the team, the process and goals of the virtual team.

Virtual teams, with a high level of interdependence and cooperation among team members, are the building block of successful global software organizations. While becoming agile helps on communication and collaboration, such teams meet several challenges in the form of cultural differences, language barriers, national traditions, different values and norms, lack of face-to-face communication, time-zone differences, and difficulties in building and maintaining trust. A successful agile virtual team needs to have the right structure, but equally important is the ability to improve as a team, to become self-managing with shared decision-making and shared leadership. It takes a long time to form such a team, and expert coaching is needed. We describe and discuss how one team leader coached and improved a global virtual agile team at a large savings and insurance company over a period of one year. Because the team members had overlapping working hours the team was able to base coordination on mutual adjustment and frequent feedback. Social software and face-to-face meetings were important factors to achieve this. By involving the remote developers in the strategy of the product, enabling everyone to pick their own tasks, and focusing on continuous learning, knowledge sharing and team build activities, the team members became highly motivated and self-managing.

In globally distributed software projects the testing expertise may be scattered across multiple locations. We describe and discuss a globally distributed agile project at DNV GL Software, a multinational provider of software for a safer, smarter and greener future in the energy, process and maritime industries. DNV GL Software is headquartered in Norway. The project is distributed across two locations with 12 team members in Norway and three testers in China. In a distributed agile team with little overlap in working hours the challenge is to coordinate tasks and test activities in a way that makes coordination and communication efficient. DNV GL Software believes in including the remote testers as part of the agile team, enabling self-managing, cross-functional virtual teams that are capable of taking the full responsibility for implementing and verifying one entire feature. To support the communication between testers in China and the rest of the team in Norway, the team needs a shared understanding of the goal of a release and how to collaborate. We conducted interviews with the team and representatives from different roles in the organization, and we performed retrospectives with the team. In this article we describe how continuous testing based on continuous and frequent feedback ensures knowledge sharing and safeguarding the quality of the system under development. We found the following enablers for a successful virtual agile team: coordination by mutual adjustment, dedicated testers and low turnover, shifting working hours, and self-management and autonomy. Non-technical factors, such as socio-technical and organizational factors, have a significant influence on the way software testing is performed in an agile virtual team. To be successful the organization needs to invest in bringing the remote testers closer to the rest of the team, as part of the virtual team.

Many studies show that real-world systems are riddled with large dependency cycles among software classes. Dependency cycles are claimed to affect quality factors such as testability, extensibility, modifiability, and reusability. Recent studies reveal that most defects are concentrated in classes that are in and near cycles. In this paper, we (1) propose a new metric: IRCRSS based on the Class Reachability Set Size (CRSS) to identify the reduction ratio between the CRSS of a class and its interfaces, and (2) presents a cycle-breaking decision support system (CB-DSS) that implements existing design approaches in combination with class edge contextual data. Evaluations of multiple systems show that (1) the IRCRSS metric can be used to identify fewer classes as candidates for breaking large cycles, thus reducing refactoring effort, and (2) the CB-DSS can assist software engineers to plan restructuring of classes involved in complex dependency cycles.

Cloud computing has been receiving a great deal of attention during the past few years. A major feature of public cloud services is that data are processed remotely in unknown systems that the users do not own or operate. This context creates a number of challenges related to data privacy and security and may hinder the adoption of cloud technology in, for example, the healthcare domain. This paper presents results from a stakeholder elicitation activity, in which the participants identified a number of obstacles to the adoption of cloud computing for the processing of healthcare data. We compare our results with previous studies and outline accountability as a possible way forward to increase the adoption of cloud services in the healthcare domain.

Software projects are still facing with challenges of team coordination across global boundaries. Boundary spanner is an important organic coordination mechanism that is not much explored in GSD literature. This paper presents a finding from four case studies of how a boundary spanner resolve coordination gaps in organizationally distributed teams. The qualitative data were collected from 16 interviews from different types of global software projects. Boundary spanners have common characteristics of a coordinator, such as team member recognition, multiple perspective expertise, decision-making ability and work time flexibility. Task negotiation, conflict resolution, task information navigation and boundary object set-up are common activities to support team coordination. We also discussed a compound effect of other organizational roles and the impact of context factors on boundary spanner's activities.

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.

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.

Offshore software development has gained momentum and most of software companies today have implemented offshore strategies of some sort. Many of these strategies are enforced by corporate top management and driven by assumptions that lower development wages guarantee cheaper and better software development. In practice, offshore software development is associated with many risks, and achievement of the expected benefits is not as straightforward as the rumor has it. In this paper we explore an implementation of an offshore strategy in a Swedish software company that opened its offshore branch in Russia. Based on extensive documentation analysis we create an overview of the initially expected benefits and obstacles that prevailed among onshore product and development unit managers. Years after implementation of the offshore in sourcing strategy we asked these managers about the achievement of their expectations. We observed that the company documented various expected benefits when implementing an off shoring strategy and also concerns that some of these benefits might not be achieved. Seven years after its implementation, the off shoring strategy was overall considered working, however the expected benefits were not fully achieved. More importantly, several gaps were identified, that suggest that the enforced strategy has resulted in a stable but not beneficial collaboration from the onshore perspective.

Coordinating teams across geographical, temporal and cultural boundaries has been identified as a critical task to achieve the success of global software projects. Organizational boundary is another dimension of global distribution, which is a less visible but equally important factor that influences team coordination. This study investigates attributes of the organizational boundary that inhibits coordination and development activities. Besides, we explore a set of effective coordination practices to overcome organizational boundary. The data were collected from two projects involving four different software development organizations. We found that the variety on collaboration policy, team organization, engineering process, and development practices contributes to extra coordination efforts, insufficient communication, team awareness and mistrust. The study also highlights that coordination practices, such as face-to-face contact, process synchronization and shared collaborative development are compulsory but not sufficient for effective team coordination across organizational boundary.

Previous studies have shown that dependency cycles contain significant number of defects, defect-prone components and account for the most critical defects. Thereby, demonstrating the impacts of cycles on software reliability. This preliminary study investigates the variables in a cyclic dependency graph that relate most with the number of defect-prone components in such graphs so as to motivate and guide decisions for possible system refactoring. By using network analysis and statistical methods on cyclic graphs of Eclipse and Apache-Active MQ, we have examined the relationships between the size and distance measures of cyclic dependency graphs. The size of the cyclic graphs consistently correlates more with the defect-proneness of components in these systems than other measures. Showing that adding new components to and/or creating new dependencies within an existing cyclic dependency structures are stronger in increasing the likelihood of defect-proneness. Our next study will investigate whether there is a cause and effect between refactoring (breaking) cyclic dependencies and defect-proneness of affected components.

(Background) Defect distribution in software systems has been shown to follow the Pareto rule of 20-80. This motivates the prioritization of components with the majority of defects for testing activities. (Research goal) Are there significant variations between defective components and architectural hotspots identified by other defect measures? (Approach) We have performed a study using post-release data of an industrial Smart Grid application with a well-maintained defect tracking system. Using the Pareto principle, we identify and compare defect-prone and hotspots components based on four defect metrics. Furthermore, we validated the quantitative results against qualitative data from the developers. (Results) Our results show that at the top 25% of the measures 1) significant variations exist between the defective components identified by the different defect metrics and that some of the components persist as defective across releases 2) the top defective components based on number of defects could only identify about 40% of critical components in this system 3) other defect metrics identify about 30% additional critical components 4) additional quality challenges of a component could be identified by considering the pair wise intersection of the defect metrics. (Discussion and Conclusion) Since a set of critical components in the system is missed by using largest-first or smallest-first prioritization approaches, this study, therefore, makes a case for an all-inclusive metrics during defect model construction such as number of defects, defect density, defect severity and defect correction effort to make us better understand what comprises defect-prone components and architectural hotspots, especially in critical applications.

(Background) Software defects that most likely will turn into system and/or business failures are termed critical by most stakeholders. Thus, having some warnings of the most probable location of such critical defects in a software system is crucial. Software complexity (e.g. coupling) has long been established to be associated with the number of defects. However, what is really challenging is not in the number but identifying the most severe defects that impact reliability. (Research Goal) Do cyclic related components account for a clear majority of the critical defects in software systems? (Approach) We have empirically evaluated two non-trivial systems. One commercial Smart Grid system developed with C# and an open source messaging and integrated pattern server developed with Java. By using cycle metrics, we mined the components into cyclic-related and non-cyclic related groups. Lastly, we evaluated the statistical significance of critical defects and severe defect-prone components (SDCs) in both groups. (Results) In these two systems, results demonstrated convincingly, that components in cyclic relationships account for a significant and the most critical defects and SDCs. (Discussion and Conclusion) We further identified a segment of a system with cyclic complexity that consist almost all of the critical defects and SDCs that impact on system's reliability. Such critical defects and the affected components should be focused for increased testing and refactoring possibilities.

Effective team coordination is crucial for successful global software projects. Although considerable research effort has been made in this area, no agreement has been reached on the influence of dispersion on team coordination and performance. The objective of this paper is to summarize the evidence on the relationship among context dispersion, team coordination and performance in global software projects. We have performed a Systematic literature review (SLR) to collect relevant studies and a thematic analysis to synthesize the extracted data. We found 28 primary studies reporting the impact of five dispersion dimensions on team performance. Previously, only two primary studies considered and distinguished all of these dispersion dimensions in studying dispersed team performance. The dispersion dimensions affect team outcomes indirectly through influencing organic and mechanistic coordination processes. Empirical evidence show that geographical dispersion impacts negatively and temporal dispersion has a mixed effect on team performance. While studies with teams working across different time zones shows a tendency that the team performance is pessimistically perceived, studies that use direct measure on task performance shows a positive association to temporal dispersion. The paper provides implications for future research and practitioners in establishing effective distributed team coordination.

Context is a central concept in empirical software engineering. It is one of the distinctive features of the discipline and it is an in-dispensable part of software practice. It is likely responsible for one of the most challenging methodological and theoretical problems: study-to-study variation in research findings. Still, empirical software engineering research is mostly concerned with attempts to identify universal relationships that are independent of how work settings and other contexts interact with the processes important to software practice. The aim of this paper is to provide an overview of how context affects empirical research and how empirical software engineering research can be better 'contextualized' in order to provide a better understanding of what works for whom, where, when, and why. We exemplify the importance of context with examples from recent systematic reviews and offer recommendations on the way forward.

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.

Thematic analysis is an approach that is often used for identifying, analyzing, and reporting patterns (themes) within data in primary qualitative research. 'Thematic synthesis' draws on the principles of thematic analysis and identifies the recurring themes or issues from multiple studies, interprets and explains these themes, and draws conclusions in systematic reviews. This paper conceptualizes the thematic synthesis approach in software engineering as a scientific inquiry involving five steps that parallel those of primary research. The process and outcome associated with each step are described and illustrated with examples from systematic reviews in software engineering.

Synthesis of case studies is different from synthesis of purely quantitative studies, for example, in that sampling and analysis in primary studies have been carried out differently, and that primary results are of a different nature. The objective of this research is to identify what challenges should be considered when choosing and using a method for synthesis of case studies. We collected experience from independent synthesis of two published case studies (on trust in outsourcing) by two teams, one team applied cross-case analysis, the other team applied thematic synthesis. The two teams reached both supporting and complimentary conclusions. Identified challenges relate to the goals and research questions of the cases to be synthesized, the number of case studies, temporal and spatial variations, and access to raw data.

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

Synthesizing the evidence from a set of studies that spans many countries and years, and that incorporates a wide variety of research methods and theoretical perspectives, is probably the single most challenging task of performing a systematic review. In this paper, we perform a tertiary review to assess the types and methods of research synthesis in systematic reviews in software engineering. Almost half of the 31 studies included in our review did not contain any synthesis; of the ones that did, two thirds performed a narrative or a thematic synthesis. The results show that, despite the focus on systematic reviews, there is, currently, limited attention to research synthesis in software engineering. This needs to change and a repertoire of synthesis methods needs to be an integral part of systematic reviews to increase their significance and utility for research and practice.

Code smells are particular patterns in object-oriented systems that are perceived to lead to difficulties in the maintenance of such systems. It is held that to improve maintainability, code smells should be eliminated by refactoring. It is claimed that classes that are involved in certain code smells are liable to be changed more frequently and have more defects than other classes in the code. We investigated the extent to which this claim is true for God Classes and Brain Classes, with and without normalizing the effects with respect to the class size. We analyzed historical data from 7 to 10 years of the development of three open-source software systems. The results show that God and Brain Classes were changed more frequently and contained more defects than other kinds of class. However, when we normalized the measured effects with respect to size, then God and Brain Classes were less subject to change and had fewer defects than other classes. Hence, under the assumption that God and Brain Classes contain on average as much functionality per line of code as other classes, the presence of God and Brain Classes is not necessarily harmful; in fact, such classes may be an efficient way of organizing code.

Abstract This paper reports on an industrial case study in a large Norwegian Oil and Gas company (StatoilHydro ASA) involving a reusable Java‐class framework and two applications that use that framework. We analyzed software changes from three releases of the reusable framework, called Java Enterprise Framework (JEF), and two applications reusing the framework, called Digital Cargo File (DCF) and Shipment and Allocation (S&A). On the basis of our analysis, we found the following: (1) Profiles of change types for the reused framework and the applications are similar, specifically, perfective changes dominate significantly. (2) Although on observing the mean value adaptive changes are more frequent and are active longer in JEF and S&A, these systems went through less refactoring than DCF. For DCF, we saw that preventive changes were more frequent and were active longer. (3) Finally, we found that designing for reuse seems to lead to a long‐term payoff in relation to non‐reusable software systems. Copyright © 2010 John Wiley & Sons, Ltd.

Code smells are design flaws in object-oriented designs that may lead to maintainability issues in the further evolution of the software system. This study focuses on the evolution of code smells within a system and their impact on the change behavior (change frequency and size). The study investigates two code smells, God Class and Shotgun Surgery, by analyzing the historical data over several years of development of two large scale open source systems. The detection of code smells in the evolution of those systems was performed by the application of an automated approach using detection strategies. The results show that we can identify different phases in the evolution of code smells during the system development and that code smell infected components exhibit a different change behavior. This information is useful for the identification of risk areas within a software system that need refactoring to assure a future positive evolution.

Providing robust decision support for software engineering (SE) requires the collection of data across multiple contexts so that one can begin to elicit the context variables that can influence the results of applying a technology. However, the task of comparing contexts is complex due to the large number of variables involved. This works extends a previous one in which we proposed a practical and rigorous process for identifying evidence and context information from SE papers. The current work proposes a specific template to collect context information from SE papers and an interactive approach to compare context information about these studies. It uses visualization and clustering algorithms to help the exploration of similarities and differences among empirical studies. This paper presents this approach and a feasibility study in which the approach is applied to cluster a set of papers that were independently grouped by experts.

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 begun to collaborate with research groups to make available repositories of software engineering empirical data. However, these initiatives are limited due to data ownership and privacy issues. As a result, many researchers in the area have adopted systematic reviews as a mean to extract empirical evidence from published material. Systematic reviews are labor intensive and costly. In this paper, we argue that the use of Information Extraction Tools can support systematic reviews and significantly speed up the creation of repositories of SE empirical evidence.