Living Boundary Objects to Support Agile Inter-Team Coordination at Scale

Context: In the last decades, large-scale agile development has received increasing attention, as also organizations with many stakeholders and large systems aim for higher development speed and focus on customer value. A recognized research challenge in large-scale agile development relates to inter-team coordination. To coordinate effectively, organizations need to identify what knowledge is required across team borders and how it can be managed over time. Knowledge is potentially manifested in boundary objects – artifacts that create a shared understanding between teams (e.g., requirements or architecture descriptions). Traceability between artifacts is a key necessity to manage change in agile contexts. Moreover, agile practitioners aim to reduce the documentation effort to absolutely crucial artifacts and trace links.Objective: This thesis aims to improve how practitioners can manage knowledge for inter-team coordination in large-scale agile development. We focus especially on how knowledge can be made explicit in artifacts and trace links that are evolved over time. Method: We empirically investigated problems and developed solutions using a research approach that was inspired by design science. Case studies, an in-depth design science study, a mixed methods study, and surveys were performed. Using this mix of research methods, we leveraged both qualitative and quantitative data. Results: We coined the concept of living boundary objects to manage knowledge for inter-team coordination. Living boundary objects are boundary objects that are traced to other artifacts, kept up to date, and serve for inter-team coordination. They should be established early in the lifecycle to create a common understanding of the product to be developed. We scrutinized architecture descriptions, interfaces, and requirements and traceability information models as examples of concrete boundary objects. We recommend establishing alignment using a common high-level structure, but also supporting diverse knowledge management practices to fulfill the individual needs of agile teams. Conclusions: Our contributions help to establish knowledge management practices that are considered beneficial by practitioners and focus on the crucial aspects to align agile teams on. We suggest concepts and requirements for knowledge management tools that take the distinct role of living boundary objects into consideration and can be adjusted as organizations\u27 needs evolve

Boundary Objects and their Use in Agile Systems Engineering

Agile methods are increasingly introduced in automotive companies in the attempt to become more efficient and flexible in the system development. The adoption of agile practices influences communication between stakeholders, but also makes companies rethink the management of artifacts and documentation like requirements, safety compliance documents, and architecture models. Practitioners aim to reduce irrelevant documentation, but face a lack of guidance to determine what artifacts are needed and how they should be managed. This paper presents artifacts, challenges, guidelines, and practices for the continuous management of systems engineering artifacts in automotive based on a theoretical and empirical understanding of the topic. In collaboration with 53 practitioners from six automotive companies, we conducted a design-science study involving interviews, a questionnaire, focus groups, and practical data analysis of a systems engineering tool. The guidelines suggest the distinction between artifacts that are shared among different actors in a company (boundary objects) and those that are used within a team (locally relevant artifacts). We propose an analysis approach to identify boundary objects and three practices to manage systems engineering artifacts in industry

Why and How Your Traceability Should Evolve: Insights from an Automotive Supplier

Traceability is a key enabler of various activities in automotive software and systems engineering and required by several standards. However, most existing traceability management approaches do not consider that traceability is situated in constantly changing development contexts involving multiple stakeholders. Together with an automotive supplier, we analyzed how technology, business, and organizational factors raise the need for flexible traceability. We present how traceability can be evolved in the development lifecycle, from early elicitation of traceability needs to the implementation of mature traceability strategies. Moreover, we shed light on how traceability can be managed flexibly within an agile team and more formally when crossing team borders and organizational borders. Based on these insights, we present requirements for flexible tool solutions, supporting varying levels of data quality, change propagation, versioning, and organizational traceability.Comment: 9 pages, 3 figures, accepted in IEEE Softwar

Why and How to Balance Alignment and Diversity of Requirements Engineering Practices in Automotive

In large-scale automotive companies, various requirements engineering (RE) practices are used across teams. RE practices manifest in Requirements Information Models (RIM) that define what concepts and information should be captured for requirements. Collaboration of practitioners from different parts of an organization is required to define a suitable RIM that balances support for diverse practices in individual teams with the alignment needed for a shared view and team support on system level. There exists no guidance for this challenging task. This paper presents a mixed methods study to examine the role of RIMs in balancing alignment and diversity of RE practices in four automotive companies. Our analysis is based on data from systems engineering tools, 11 semi-structured interviews, and a survey to validate findings and suggestions. We found that balancing alignment and diversity of RE practices is important to consider when defining RIMs. We further investigated enablers for this balance and actions that practitioners take to achieve it. From these factors, we derived and evaluated recommendations for managing RIMs in practice that take into account the lifecycle of requirements and allow for diverse practices across sub-disciplines in early development, while enforcing alignment of requirements that are close to release.Comment: 19 page

Investigating Software Engineering Artifacts in DevOps Through the Lens of Boundary Objects

Software engineering artifacts are central to DevOps, enabling the collaboration of teams involved with integrating the development and operations domains. However, collaboration around DevOps artifacts has yet to receive detailed research attention. We apply the sociological concept of Boundary Objects to describe and evaluate the specific software engineering artifacts that enable a cross-disciplinary understanding. Using this focus, we investigate how different DevOps stakeholders can collaborate efficiently using common artifacts. We performed a multiple case study and conducted twelve semi-structured interviews with DevOps practitioners in nine companies. We elicited participants\u27 collaboration practices, focusing on the coordination of stakeholders and the use of engineering artifacts as a means of translation. This paper presents a consolidated overview of four categories of DevOps Boundary Objects and eleven stakeholder groups relevant to DevOps. To help practitioners assess cross-disciplinary knowledge management strategies, we detail how DevOps Boundary Objects contribute to four areas of DevOps knowledge and propose derived dimensions to evaluate their use

What do Users Expect of Bidirectional Transformations?

A bidirectional transformation (bx) is a means of maintaining the consistency of two or more related sources of information. Existing bx frameworks attempt to capture what it means for a bx to be well-behaved by proposing various laws. In many cases, however, it is still unclear if such laws really capture "desirable" behaviour from a user\u27s perspective. We argue that knowing most users\u27 expectations is not only useful as input for designing, extending, and improving existing bx frameworks and tools, but also when attempting to choose the most suitable bx tool for a specific application scenario and group of users. In addition, being aware of intuitive expectations that cannot be fulfilled by a chosen bx tool (perhaps for good reasons!) is equally important; when designing and implementing consistency maintainers, such mismatches between users\u27 expectations and tool characteristics should be made explicit and discussed with all stakeholders. In this paper, we designed and performed an experiment asking 65 computer science students to answer questions regarding the expected behaviour of a synchroniser. Our contribution is twofold: (i) we propose an experiment design that can be adapted and repeated for a specific group of users, and (ii) we present and discuss empirical data obtained from two runs of the experiment

T-Reqs: Tool Support for Managing Requirements in Large-Scale Agile System Development

T-Reqs is a text-based requirements management solution based on the git version control system. It combines useful conventions, templates and helper scripts with powerful existing solutions from the git ecosystem and provides a working solution to address some known requirements engineering challenges in large-scale agile system development. Specifically, it allows agile cross-functional teams to be aware of requirements at system level and enables them to efficiently propose updates to those requirements. Based on our experience with T-Reqs, we i) relate known requirements challenges of large-scale agile system development to tool support; ii) list key requirements for tooling in such a context; and iii) propose concrete solutions for challenges.Comment: Accepted for publication in Proc. of 26th IEEE Int. Requirements Eng. Conf., Demo Track, Banff, Alberta, Canada, 201

ExTrA: Explaining architectural design tradeoff spaces via dimensionality reduction

In software design, guaranteeing the correctness of run-time system behavior while achieving an acceptable balance among multiple quality attributes remains a challenging problem. Moreover, providing guarantees about the satisfaction of those requirements when systems are subject to uncertain environments is even more challenging. While recent developments in architectural analysis techniques can assist architects in exploring the satisfaction of quantitative guarantees across the design space, existing approaches are still limited because they do not explicitly link design decisions to satisfaction of quality requirements. Furthermore, the amount of information they yield can be overwhelming to a human designer, making it difficult to see the forest for the trees. In this paper we present ExTrA (Explaining Tradeoffs of software Architecture design spaces), an approach to analyzing architectural design spaces that addresses these limitations and provides a basis for explaining design tradeoffs. Our approach employs dimensionality reduction techniques employed in machine learning pipelines like Principal Component Analysis (PCA) and Decision Tree Learning (DTL) to enable architects to understand how design decisions contribute to the satisfaction of extra-functional properties across the design space. Our results show feasibility of the approach in two case studies and evidence that combining complementary techniques like PCA and DTL is a viable approach to facilitate comprehension of tradeoffs in poorly-understood design spaces

Explaining quality attribute tradeoffs in automated planning for self-adaptive systems

Self-adaptive systems commonly operate in heterogeneous contexts and need to consider multiple quality attributes. Human stakeholders often express their quality preferences by defining utility functions, which are used by self-adaptive systems to automatically generate adaptation plans. However, the adaptation space of realistic systems is large and it is obscure how utility functions impact the generated adaptation behavior, as well as structural, behavioral, and quality constraints. Moreover, human stakeholders are often not aware of the underlying tradeoffs between quality attributes. To address this issue, we present an approach that uses machine learning techniques (dimensionality reduction, clustering, and decision tree learning) to explain the reasoning behind automated planning. Our approach focuses on the tradeoffs between quality attributes and how the choice of weights in utility functions results in different plans being generated. We help humans understand quality attribute tradeoffs, identify key decisions in adaptation behavior, and explore how differences in utility functions result in different adaptation alternatives. We present two systems to demonstrate the approach\u27s applicability and consider its potential application to 24 exemplar self-adaptive systems. Moreover, we describe our assessment of the tradeoff between the information reduction and the amount of explained variance retained by the results obtained with our approach