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

Collaborative traceability management: a multiple case study from the perspectives of organization, process, and culture

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

Collaborative traceability management: a multiple case study from the perspectives of organization, process, and culture

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

Prioritizing Strategic IT Projects with Tropos

One of the daily tasks of an enterprise architect is to prioritize strategic IT projects. To achieve a business-IT alignment, this prioritization needs to be based on business strategies and goals. Therefore, business goals and their traceability to strategic IT projects are relevant for the enterprise architect. However, surpris-ingly little formalisations and reasoning techniques have been developed in the enterprise architecture domain. In this paper we show that the popular goal modelling technique Tropos together with its formal reasoning techniques can support the enterprise architect when prioritizing strategic IT projects. We prove the feasibility of our work with a tool implementation of the proposed modelling language and its corresponding algorithms; and demon-strate their usefulness with the help of an example taken from the enterprise architecture literature

Boundary objects in agile practices: Continuous management of systems engineering artifacts in the automotive domain

Automotive companies increasingly include proven agile methods in their plan-driven system development. The adoption of agile methods impacts not only the way individuals collaborate, but also the management of artifacts like requirements, test cases, safety documentation, and models. While practitioners aim to reduce unnecessary documentation, there is a lack of guidance for automotive companies with respect to what artifacts are needed and how to manage them. To close this knowledge gap and create practical guidelines, we conducted a design-science study together with 53 practitioners from six automotive companies. Using interviews, surveys, and focus groups, we analyzed categories of artifacts and practical challenges to create applicable guidelines to collaboratively manage artifacts in agile automotive contexts. Our findings indicate that different practices are required to manage artifacts that are shared among different teams within the company (boundary objects) and those that are relevant within a specific team (locally relevant artifacts)

Software Architecture in Practice: Challenges and Opportunities

Software architecture has been an active research field for nearly four decades, in which previous studies make significant progress such as creating methods and techniques and building tools to support software architecture practice. Despite past efforts, we have little understanding of how practitioners perform software architecture related activities, and what challenges they face. Through interviews with 32 practitioners from 21 organizations across three continents, we identified challenges that practitioners face in software architecture practice during software development and maintenance. We reported on common software architecture activities at software requirements, design, construction and testing, and maintenance stages, as well as corresponding challenges. Our study uncovers that most of these challenges center around management, documentation, tooling and process, and collects recommendations to address these challenges.Comment: Preprint of Full Research Paper, the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE '23

Handling requirements dependencies in agile projects: A focus group with agile software development practitioners

Agile practices on requirements dependencies are a relatively unexplored topic in literature. Empirical studies on it are scarce. This research sets out to uncover concepts that practitioners in companies of various sizes across the globe and in various industries, use for dealing with requirements dependencies in their agile software projects. Concepts were revealed through online focus group research, using an adapted forum for discussion, and grounded theory to analyze the responses. Our study resulted in the following findings: (1) requirements dependencies occur in agile projects and are important to these projects' success just as this is known for `traditional' software projects'; (2) requirements dependencies (i) were considered and treated as part of risk management, (ii) were deemed a responsibility of the individual team members, and (iii) mostly did affect project planning; (3) continuous communication and collaboration - two essential features of any agile method, were found critical to mitigating the risks due to dependencies; (4) a hybrid approach to architecture between agile and plan-driven methods was perceived to yield maximum scalability and help coping with dependencies; (5) `cross-cutting concerns', a category of dependencies, were not uniformly understood in an agile context and require more research