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

Software Engineers' Information Seeking Behavior in Change Impact Analysis - An Interview Study

Software engineers working in large projects must navigate complex information landscapes. Change Impact Analysis (CIA) is a task that relies on engineers' successful information seeking in databases storing, e.g., source code, requirements, design descriptions, and test case specifications. Several previous approaches to support information seeking are task-specific, thus understanding engineers' seeking behavior in specific tasks is fundamental. We present an industrial case study on how engineers seek information in CIA, with a particular focus on traceability and development artifacts that are not source code. We show that engineers have different information seeking behavior, and that some do not consider traceability particularly useful when conducting CIA. Furthermore, we observe a tendency for engineers to prefer less rigid types of support rather than formal approaches, i.e., engineers value support that allows flexibility in how to practically conduct CIA. Finally, due to diverse information seeking behavior, we argue that future CIA support should embrace individual preferences to identify change impact by empowering several seeking alternatives, including searching, browsing, and tracing.Comment: Accepted for publication in the proceedings of the 25th International Conference on Program Comprehensio

An Exploratory Study of Forces and Frictions affecting Large-Scale Model-Driven Development

In this paper, we investigate model-driven engineering, reporting on an exploratory case-study conducted at a large automotive company. The study consisted of interviews with 20 engineers and managers working in different roles. We found that, in the context of a large organization, contextual forces dominate the cognitive issues of using model-driven technology. The four forces we identified that are likely independent of the particular abstractions chosen as the basis of software development are the need for diffing in software product lines, the needs for problem-specific languages and types, the need for live modeling in exploratory activities, and the need for point-to-point traceability between artifacts. We also identified triggers of accidental complexity, which we refer to as points of friction introduced by languages and tools. Examples of the friction points identified are insufficient support for model diffing, point-to-point traceability, and model changes at runtime.Comment: To appear in proceedings of MODELS 2012, LNCS Springe

What influences the speed of prototyping? An empirical investigation of twenty software startups

It is essential for startups to quickly experiment business ideas by building tangible prototypes and collecting user feedback on them. As prototyping is an inevitable part of learning for early stage software startups, how fast startups can learn depends on how fast they can prototype. Despite of the importance, there is a lack of research about prototyping in software startups. In this study, we aimed at understanding what are factors influencing different types of prototyping activities. We conducted a multiple case study on twenty European software startups. The results are two folds, firstly we propose a prototype-centric learning model in early stage software startups. Secondly, we identify factors occur as barriers but also facilitators for prototyping in early stage software startups. The factors are grouped into (1) artifacts, (2) team competence, (3) collaboration, (4) customer and (5) process dimensions. To speed up a startups progress at the early stage, it is important to incorporate the learning objective into a well-defined collaborative approach of prototypingComment: This is the author's version of the work. Copyright owner's version can be accessed at doi.org/10.1007/978-3-319-57633-6_2, XP2017, Cologne, German

OntoEng: A design method for ontology engineering in information systems

This paper addresses the design problem relating to ontology engineering in the discipline of information systems. Ontology engineering is a realm that covers issues related to ontology development and use throughout its life span. Nowadays, ontology as a new innovation promises to improve the design, semantic integration, and utilization of information systems. Ontologies are the backbone of knowledge-based systems. In addition, they establish sharable and reusable common understanding of specific domains amongst people, information systems, and software agents. Notwithstanding, the ontology engineering literature does not provide adequate guidance on how to build, evaluate, and maintain ontologies. On the basis of the gathered experience during the development of V4 Telecoms Business Model Ontology as well as the conducted integration of the related literature from the design science paradigm, this paper introduces OntoEng and its application as a novel systematic design method for ontology engineering

Free and open source software development of IT systems

IT system development, integration, deployment, and administration benefit significantly from free and open source software (FOSS) tools and services. Affordability has been a compelling reason for adopting FOSS in computing curricula and equipping computing labs with support infrastructure. Using FOSS systems and services, however, is just the first step in taking advantage of how FOSS development principles and practices can impact student learning in IT degree programs. Above all, FOSS development of IT systems requires changes to how students, instructors, and other contributors work collaboratively and openly and get involved and invested in project activities. In this paper I examine the challenges to engage students in FOSS development projects proposed by real clients. A six-week course project revealed problems with adopting FOSS development and collaboration across different activities and roles that student team members have assumed. Despite these problems, students have showed a genuine and strong interest in gaining more practice with FOSS development. FOSS development teaching was further refined in two other courses to learn about adequate teaching strategies and the competencies that students achieve when they participate in FOSS development of IT systems

Rationale in Development Chat Messages: An Exploratory Study

Chat messages of development teams play an increasingly significant role in software development, having replaced emails in some cases. Chat messages contain information about discussed issues, considered alternatives and argumentation leading to the decisions made during software development. These elements, defined as rationale, are invaluable during software evolution for documenting and reusing development knowledge. Rationale is also essential for coping with changes and for effective maintenance of the software system. However, exploiting the rationale hidden in the chat messages is challenging due to the high volume of unstructured messages covering a wide range of topics. This work presents the results of an exploratory study examining the frequency of rationale in chat messages, the completeness of the available rationale and the potential of automatic techniques for rationale extraction. For this purpose, we apply content analysis and machine learning techniques on more than 8,700 chat messages from three software development projects. Our results show that chat messages are a rich source of rationale and that machine learning is a promising technique for detecting rationale and identifying different rationale elements.Comment: 11 pages, 6 figures. The 14th International Conference on Mining Software Repositories (MSR'17