Abstract Large-scale systems development commonly faces the challenge of managing relevant knowledge between different organizational groups, particularly in increasingly agile contexts. Here, there is a conflict between coordination and group autonomy, and it is challenging to determine what necessary coordination information must be shared by what teams or groups, and what can be left to local team management. We introduce a way to manage this complexity using a modeling framework based on two core concepts: methodological islands (i.e., groups using different development methods than the surrounding organization) and boundary objects (i.e., artifacts that create a common understanding across team borders). However, we found that companies often lack a systematic way of assessing coordination issues and the use of boundary objects between methodological islands. As part of an iterative design science study, we have addressed this gap by producing a modeling framework (BOMI: Boundary Objects and Methodological Islands) to better capture and analyze coordination and knowledge management in practice. This framework includes a metamodel, as well as a list of bad smells over this metamodel that can be leveraged to detect inter-team coordination issues. The framework also includes a methodology to suggest concrete modeling steps and broader guidelines to help apply the approach successfully in practice. We have developed Eclipse-based tool support for the BOMI method, allowing for both graphical and textual model creation, and including an implementation of views over BOMI instance models in order to manage model complexity. We have evaluated these artifacts iteratively together with five large-scale companies developing complex systems. In this work, we describe the BOMI framework and its iterative evaluation in several real cases, reporting on lessons learned and identifying future work. We have produced a matured and stable modeling framework which facilitates understanding and reflection over complex organizational configurations, communication, governance, and coordination of knowledge artifacts in large-scale agile system development.

The MobSTr dataset contains a number of artifacts for an autonomous driver assistance system, ranging from textual requirements to models for system design and models relevant to safety assurance. The artifacts provided are connected with traceability links created and managed with Eclipse Capra, an open source traceability management tool. The dataset builds upon a custom traceability information model that provides type safety and semantics for the trace links. MobSTr is intended for researchers that work on software and systems traceability as well as on model-based safety assurance. It is already being used in a number of studies, including research on trace link consistency, change impact analysis, and automated analysis of safety and timing requirements.

Large-scale system development companies are increasingly adopting agile methods. While this adoption may improve lead-times, such companies need to balance two trade-offs: (i) the need to have a uniform, consistent development method on system level with the need for specialised methods for teams in different disciplines (e.g., hardware, software, mechanics, sales, support); (ii) the need for comprehensive documentation on system level with the need to have lightweight documentation enabling iterative and agile work. With specialised methods for teams, isolated teams work within larger ecosystems of plan-driven culture, i.e., teams become agile "islands". At the boundaries, these teams share knowledge which needs to be managed well for a correct system to be developed. While it is useful to support diverse and specialised methods, it is important to understand which islands are repeatedly encountered, the reasons or factors triggering their existence, and how best to handle coordination between them. Based on a multiple case study, this work presents a catalogue of islands and the boundary objects between them. We believe this work will be beneficial to practitioners aiming to understand their ecosystems and researchers addressing communication and coordination challenges in large-scale development.

Today, there is a wide range of techniques to support software comprehension. However, we do not fully understand yet what techniques really help novices, to comprehend a software system. In this paper, we present a master level project course on software evolution, which has a large focus on software comprehension. We collected data about student's experience with diverse comprehension techniques during focus group discussions over the course of two years. Our results indicate that systematic code reading can be supported by additional techniques to guiding reading efforts. Most techniques are considered valuable for gaining an overview and some techniques are judged to be helpful only in later stages of software comprehension efforts.

Traceability is crucial for many activities in software and systems engineering including monitoring the development progress, and proving compliance with standards. In practice, the use and maintenance of trace links are challenging as artifacts undergo constant change, and development takes place in distributed scenarios with multiple collaborating stakeholders. Although traceability management in general has been addressed in previous studies, there is a need for empirical insights into the collaborative aspects of traceability management and how it is situated in existing development contexts. The study reported in this paper aims to close this gap by investigating the relation of collaboration and traceability management, based on an understanding of characteristics of the development effort. In our multiple exploratory case study, we conducted semi-structured interviews with 24 individuals from 15 industrial projects. We explored which challenges arise, how traceability management can support collaboration, how collaboration relates to traceability management approaches, and what characteristics of the development effort influence traceability management and collaboration. We found that practitioners struggle with the following challenges: (1) collaboration across team and tool boundaries, (2) conveying the benefits of traceability, and (3) traceability maintenance. If these challenges are addressed, we found that traceability can facilitate communication and knowledge management in distributed contexts. Moreover, there exist multiple approaches to traceability management with diverse collaboration approaches, i.e., requirements-centered, developer-driven, and mixed approaches. While traceability can be leveraged in software development with both agile and plan-driven paradigms, a certain level of rigor is needed to realize its benefits and overcome challenges. To support practitioners, we provide principles of collaborative traceability management. The main contribution of this paper is empirical evidence of how culture, processes, and organization impact traceability management and collaboration, and principles to support practitioners with collaborative traceability management. We show that collaboration and traceability management have the potential to be mutually beneficial—when investing in one, also the other one is positively affected.

Highly configurable systems are complex pieces of software. To tackle this complexity, hundreds of dedicated analysis techniques have been conceived, many of which able to analyze system properties for all possible system configurations, as opposed to traditional, single-system analyses. Unfortunately, it is largely unknown whether these techniques are adopted in practice, whether they address actual needs, or what strategies practitioners actually apply to analyze highly configurable systems. We present a study of analysis practices and needs in industry. It relied on a survey with 27 practitioners engineering highly configurable systems and follow-up interviews with 15 of them, covering 18 different companies from eight countries. We confirm that typical properties considered in the literature (e.g., reliability) are relevant, that consistency between variability models and artifacts is critical, but that the majority of analyses for specifications of configuration options (a.k.a., variability model analysis) is not perceived as needed. We identified rather pragmatic analysis strategies, including practices to avoid the need for analysis. For instance, testing with experience-based sampling is the most commonly applied strategy, while systematic sampling is rarely applicable. We discuss analyses that are missing and synthesize our insights into suggestions for future research.

Automated traceability has been investigated for over a decade with promising results. However, a human analyst is needed to vet the generated trace links to ensure their quality. The process of vetting trace links is not trivial and while previous studies have analyzed the performance of the human analyst, they have not focused on the analyst's information needs. The aim of this study is to investigate what context information the human analyst needs. We used design science research, in which we conducted interviews with ten practitioners in the traceability area to understand the information needed by human analysts. We then compared the information collected from the interviews with existing literature. We created a prototype tool that presents this information to the human analyst. To further understand the role of context information, we conducted a controlled experiment with 33 participants. Our interviews reveal that human analysts need information from three different sources: 1) from the artifacts connected by the link, 2) from the traceability information model, and 3) from the tracing algorithm. The experiment results show that the content of the connected artifacts is more useful to the analyst than the contextual information of the artifacts.

Traceability is an important concern for numerous software engineering activities. Establishing traceability links is a challenging and cost-intensive task, which is uneconomical without suitable strategies for maintaining high link quality. Current approaches to Traceability Management (TM), however, often make important assumptions and choices without ensuring that the consequences and implications for traceability maintenance are feasible and desirable in practice.

Traceability is a known problem both in academia and industry. One of the main challenges is that there is no one solution that will solve traceability problems for everyone in industry. Traceability needs are dependent on the context of the organization and can differ from project to project in the same organization. To cater for this problem we have developed Capra, an open source, flexible, configurable and extendable traceability management tool. Capra can be tailored according to specific traceability needs of individual projects and organizations.

Traceability and trace link management are important for various reasons, including managing knowledge about a complex software system, monitoring the progress of its development, and proving that it is developed in accordance to regulations. However, it is difficult to maintain and use trace links in real-world projects where artifacts undergo constant change and multiple stakeholders are involved. In this paper, we extend the current body of knowledge on traceability management by regarding its collaborative aspects in an industrial setting. Based on 15 industrial cases and semi-structured interviews with 24 practitioners, we identify challenges involved in collaborative traceability management, and how traceability management can be used to enable collaboration. Our findings show that main challenges are boundaries between organizations and tools, a lack of common goals and responsibilities, and the difficulty of collaboratively maintaining trace links. We also identify traceability as an important facilitator for communication and knowledge management across these boundaries.

Domain Specific Languages (DSLs) are an established means of reducing the gap between problem and solution domains. DSLs increase productivity and improve quality as they can be tailored to exactly fit the needs of the problem to be solved. A DSL can have multiple notations including textual and graphical notations. In some cases, one of these notations for a DSL is enough but there are many cases where a single notation does not suffice and there is a demand to support multiple notations for the same DSL. UML profile is one of several approaches used to define a DSL, however most UML tools only come with graphical editors. In this paper, we present our approach and industrial experience on integrating textual and graphical editors for a UML profile-based DSL. This work was conducted as part of an explorative study at Ericsson. The main aim of the study was to investigate how to introduce a textual editor to an already existing UML profile-based DSL in an Eclipse environment. We report on the challenges of integrating textual and graphical editors for UML profile-based DSLs in practice, our chosen approach, specific constraints and requirements of the study.