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

Report from GI-Dagstuhl Seminar 16394: Software Performance Engineering in the DevOps World

This report documents the program and the outcomes of GI-Dagstuhl Seminar 16394 "Software Performance Engineering in the DevOps World". The seminar addressed the problem of performance-aware DevOps. Both, DevOps and performance engineering have been growing trends over the past one to two years, in no small part due to the rise in importance of identifying performance anomalies in the operations (Ops) of cloud and big data systems and feeding these back to the development (Dev). However, so far, the research community has treated software engineering, performance engineering, and cloud computing mostly as individual research areas. We aimed to identify cross-community collaboration, and to set the path for long-lasting collaborations towards performance-aware DevOps. The main goal of the seminar was to bring together young researchers (PhD students in a later stage of their PhD, as well as PostDocs or Junior Professors) in the areas of (i) software engineering, (ii) performance engineering, and (iii) cloud computing and big data to present their current research projects, to exchange experience and expertise, to discuss research challenges, and to develop ideas for future collaborations

Technical Debt Prioritization: State of the Art. A Systematic Literature Review

Background. Software companies need to manage and refactor Technical Debt issues. Therefore, it is necessary to understand if and when refactoring Technical Debt should be prioritized with respect to developing features or fixing bugs. Objective. The goal of this study is to investigate the existing body of knowledge in software engineering to understand what Technical Debt prioritization approaches have been proposed in research and industry. Method. We conducted a Systematic Literature Review among 384 unique papers published until 2018, following a consolidated methodology applied in Software Engineering. We included 38 primary studies. Results. Different approaches have been proposed for Technical Debt prioritization, all having different goals and optimizing on different criteria. The proposed measures capture only a small part of the plethora of factors used to prioritize Technical Debt qualitatively in practice. We report an impact map of such factors. However, there is a lack of empirical and validated set of tools. Conclusion. We observed that technical Debt prioritization research is preliminary and there is no consensus on what are the important factors and how to measure them. Consequently, we cannot consider current research conclusive and in this paper, we outline different directions for necessary future investigations

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

Challenges to Architecture Decision-Making in Agile Development Environments

Käesoleva magistritöö eesmärk on uurida väljakutseid, mis võivad esineda tarkvaraarhitektuuri kombineerimisel väleda tarkvaraarendusega ning selgitada välja põhjused, mis neid esile toovad. Kuigi antud teema on olnud juba päevakorras mõnda aega, siis jätkuvalt esineb vastuolusid väleda tarkvaraarenduse ja tarkvaraarhitektuuri sobitamisel nii teadlaste kui praktikute seas. Väleda tarkvaraarenduse ning arhitektuuri toetajaid võib leida sama palju kui mittetoetajaid, kes väidavad, et neid kahte kokku sobitada pole võimalik. Käesolevas magistritöös püstitatud uurimisküsimuste vastamisel on kasutatud kahte uurimismetoodikat: kirjanduse ülevaade ning juhtumiuuring. Kirjanduse ülevaade käsitleb varem avaldatud uurimistöid ning raskuseid, mida on antud valdkonnas senimaani täheldatud. Lisaks sellele on arutlusse võetud kirjanduses välja toodud soovitused, mida järgida arhitektuuri arendamisel väledas arenduskeskkonnas. Magistritöö teine osa käsitleb Eestis tegutsevas tarkvara idufirmas Stagnation Lab ja Siseministeeriumi IT osakonnas (SMIT) läbi viidud juhtumiuuringut. Stagnation Labis analüüsiti kahte projekti ning intervjueeriti mõlema projekti rollis olnud tarkvaraarhitekte, et uurida, milliseid raskusi kohati süsteemi ning eelkõige tarkvara arhitektuuri arenduse käigus. Samal eesmärgil intervjueeriti ka SMITi projekti eestvedanud tarkvaraarhitekti.The goal of this master thesis is to explore challenges of architecture decision-making in agile environments and trying to find out what causes issues regarding agile architecture - the latter being a set of values and practices supporting the effective evolution of the design and system architecture, concurrent with the implementation of new business functionality. Although the topic has been existent for some time, there are still tensions between software architecture and agility that are not well understood by agile practitioners and researchers alike. While there are many active promoters of agile architecture design, there can be found equally many non-believers who state that agility and architecture cannot work together. To find answers to the research questions stated in this thesis, two research methodologies have been used: a literature survey and a case study. The literature survey covers related work on agility in software architecture and the challenges that come with it. The survey includes difficulties that have been observed regarding the use of agile development methods when building the architecture. In addition, recommended practices are discussed for applying agile processes associated with sound architectural principles. The second part of the thesis is a case study within a software startup company, Stagnation Lab, and the SMIT (Ministry of the Interior IT and Development Centre). In Stagnation Lab, two projects were analyzed. The main architects behind the design of each project were interviewed to look deeper into potential challenges when applying agile practices in architecture development. Similarly, at SMIT, the main architect responsible for the design of a monitoring information system for the Rescue and Fire Department was interviewed

Everyone’s Going to be an Architect: Design Principles for Architectural Thinking in Agile Organizations

Organizational agility is a prominent aim for companies to thrive in today’s volatile business environments. One common building block of agility are (semi-) autonomous teams for continuously fulfilling and surpassing customers’ needs. However, these teams still need to see the enterprise’s ‘big picture’ of strategic objectives, business processes, and IT landscape to prevent organizational inertia or technical debt. This requires architectural thinking to inform these ‘non’-architects’ decision-making. To aid companies towards achieving sustainable agility, we propose six design principles as underlying logic on how to realize architectural thinking in agile organizations. The results are based on insights from interviews with sixteen employees and consultants with expertise on architecture management and organizational agility across several industries. Our work closes a gap in the agility literature, which so far mainly focused on non-generalizable blueprints for agile setups without showing their underlying logics, or approaches and role set-ups for enterprise-level architecture management