Software reference architectures provide templates and guidelines for designing systems in a particular domain. Companies use them to achieve interoperability of (parts of) their software, standardization, and faster development. In contrast to system-specific software architectures that "emerge" during development, reference architectures dictate significant parts of the software design early on. Agile software development frameworks (such as Scrum) acknowledge changing software requirements and the need to adapt the software design accordingly. In this paper, we present lessons learned about how reference architectures interact with Scrum (the most frequently used agile process framework). These lessons are based on observing software development projects in five companies. We found that reference architectures can support good practice in Scrum: They provide enough design upfront without too much effort, reduce documentation activities, facilitate knowledge sharing, and contribute to "architectural thinking" of developers. However, reference architectures can impose risks or even threats to the success of Scrum (e.g., to self-organizing and motivated teams).

Architecture decisions are often not explicitly documented in practice but reside in the architect's mind as tacit knowledge, even though explicit capturing and documentation of architecture decisions has been associated with a multitude of benefits. As part of a research collaboration with ABB, we developed a tool to document architecture decisions. This tool is an add-in for Enterprise Architect and is an implementation of a viewpoint-based decision documentation framework. To validate the add-in, we conducted an exploratory case study with ABB architects. In the study, we assessed the status quo of architecture decision documentation, identified architects' expectations of the ideal decision documentation tool, and evaluated the new add-in. We found that although awareness of decision documentation is increasing at ABB, several barriers exist that limit the use of decisions in practice. Regarding their ideal tool, architects want a descriptive and efficient approach. Supplemental features like reporting or decision sharing are requested. The new add-in, was well-perceived by the architects. As a result of the study, we propose a clearer separation of problem, outcomes, and alternatives for the decision documentation framework.

Software architects make architectural decisions such as choosing architecture patterns or frameworks. Capturing architectural decisions reduces evolution costs for software systems. Existing approaches overlook the challenge of capturing tacit knowledge about architectural decisions. Previously, we proposed the REGAIN approach to capture tacit knowledge about architectural decisions. REGAIN is based on the Repertory Grid technique, a powerful knowledge acquisition approach from knowledge engineering. However, REGAIN lacked industrial validation. Therefore, in this paper, we initially present a study to ensure that REGAIN meets the needs of industrial architects. We interviewed 16 architects who indicated REGAIN advantages such as systematic decision-making support. Also, architects indicated improvement opportunities, in particular tool support and the possibility to prioritize concerns that are used to evaluate decision alternatives. Therefore, we conducted an additional study to evaluate two approaches for prioritizing concerns: pairwise-comparisons and the hundred-dollar approach. We conducted an experiment with 30 graduate students to compare the two prioritization approaches. Based on the results of the experiment, we added the hundred-dollar approach to REGAIN. Moreover, based on the study with architects and the experiment with students, we implemented open source tool support for REGAIN, which architects can use to capture architectural decisions.

Context: Variability (i.e., the ability of software systems or artifacts to be adjusted for different contexts) became a key property of many systems. Objective: We analyze existing research on variability in software systems. We investigate variability handling in major software engineering phases (e.g., requirements engineering, architecting). Method: We performed a systematic literature review. A manual search covered 13 premium software engineering journals and 18 premium conferences, resulting in 15,430 papers searched and 196 papers considered for analysis. To improve reliability and to increase reproducibility, we complemented the manual search with a targeted automated search. Results: Software quality attributes have not received much attention in the context of variability. Variability is studied in all software engineering phases, but testing is underrepresented. Data to motivate the applicability of current approaches are often insufficient; research designs are vaguely described. Conclusions: Based on our findings we propose dimensions of variability in software engineering. This empirically grounded classification provides a step towards a unifying, integrated perspective of variability in software systems, spanning across disparate or loosely coupled research themes in the software engineering community. Finally, we provide recommendations to bridge the gap between research and practice and point to opportunities for future research.

Background: Many empirical software engineering studies use students as subj ects and are conducted as part of university courses.Aim: We aim at reporting our experiences with using guidelines for integrating empirical studies with our research and teaching goals.Method: We document our experience from conducting three studies with graduate students in two software architecture cou rses.Results: Our results show some problems that we faced when following the guidelines and deviations we made from the original guidelines.Conclusions: Based on our results we propose recommendations for empirical software engineering studies that are integrated in university courses.

Abstract — Background: Case studies and experiments are research methods frequently applied in empirical software engineering. Experiments are well-understood and their value as an empirical method is recognized. On the other hand, there seem to be different opinions on what constitutes a case study, and about the value of case studies as a thorough research method. Aim: We aim at exploring the attitudes of software engineering researchers on case studies and experiments. Furthermore, we investigate how the perceptions of researchers vary along their views on what constitutes a case study. Method: We performed an exploratory survey involving 26 software engineering researchers. We collected data using a paper-based questionnaire. Results: We found that participants slightly prefer experiments over case studies. Moreover, participants believe there is more useful literature on experiments, than on case studies. By analyzing two different views on the nature of case studies, we found differences in the perceived validity of case studies. Conclusions: The survey provided insights into the perceptions of researchers on case studies and experiments. Moreover, the results help reconcile different views on case studies. Keywords- empirical software engineering; case studies; experiments; survey I.

Knowledge about the architecture of a software-intensive system tends to vaporize easily. This leads to increased maintenance costs. We explore a new idea: utilizing the repertory grid technique to capture tacit architectural knowledge. Particularly, we investigate the elicitation of design decision alternatives and their characteristics. To study the applicability of this idea, we performed an exploratory study. Seven independent subjects applied the repertory grid technique to document a design decision they had to take in previous projects. Then, we interviewed each subject to understand their perception about the technique. We identified advantages and disadvantages of using the technique. The main advantage is the reasoning support it provides; the main disadvantage is the additional effort it requires. Also, applying the technique depends on the context of the project. Using the repertory grid technique is a promising approach for fighting architectural knowledge vaporization.