ABSTRACT. CONTEXT: Many researchers advocate “tailoring” agile methods to suit a project’s or company’s specific environment and needs. This includes combining agile methods with more traditional “plan driven” practices.

OBJECTIVE: This study aims to assess to what extent projects actually combine agile and traditional practices.

METHOD: Data from the HELENA survey of nearly 700 projects were examined to assess how many projects respondents characterized as using agile methods also used traditional methods, and also to what extent they used different practices.

RESULTS: The data show that, overall, two-thirds of the projects in the survey combine agile and traditional methods. However, projects that combine agile and traditional methods are significantly less likely to use agile _practices_ than projects that solely use agile methods.

CONCLUSIONS: We hypothesize that the mindset of an organization, rather than technical necessity, determines whether a project will adopt a purely agile or a hybrid approach.

ABSTRACT. Automotive companies increasingly adopt scaled agile methods to allow them to deal with their organisational and product complexity. Suitable methods are needed to ensure safety when developing automotive systems. On a small scale, R-Scrum and SafeScrum are two concrete suggestions for how to develop safety-critical systems using agile methods. However, for large-scale environments, existing scaled agile frameworks like SAFe or LESS do not support the development of safety-critical systems out of the box. We, therefore, aim to understand which challenges exist when developing safety-critical systems within large-scale agile industrial settings, in particular in the automotive domain. Based on an analysis of R-Scrum and SafeScrum, we conducted a focus group with three experts from industry to collect challenges in their daily work. We found challenges in the areas of living traceability, continuous compliance, and organisational flexibility. Among others, organisations struggle with defining a suitable traceability strategy, performing incremental safety analysis, and with integrating safety practices into their scaled way of working. Our results indicate a need to provide practical approaches to integrate safety work into large-scale agile and point towards possible solutions, e.g., modular safety cases.

ABSTRACT. Software companies have increasingly organised hackathons since the early 2010s. These time-bounded, intensive, collaborative and solution-oriented events enable companies to generate several ideas, some of which can be used to evolve their products and services. Hackathons are means to gather feedback from outside to innovate. Companies also follow such open innovation trend by raising software ecosystems via a platformisation process. They create platforms so that third parties can develop new software solutions and in doing so extend the current product portfolio. In this scenario, a hackathon can be seen as a strategy to support ecosystem evolution. Therefore, we decided to conduct a systematic mapping study to investigate the benefits that hackathons can provide to software ecosystems. This paper presents our analysis of twenty-seven papers on corporate hackathons in the software industry. As main findings, we (i) describe a set of fourteen social, technical and business benefits; as well as (ii) discuss how companies can leverage ecosystem health by conducting hackathons. We address the scarcity of research around the outcomes of corporate hackathons. Besides, we conclude that hackathons are alternative modes of production and innovation, which can catalyse a software ecosystem.

ABSTRACT. Agile software development has become increasingly popular over the past years. Agile methods are perceived to address challenges caused by the rapid change in the market while reducing time to market and development. As the popularity of Agile method is growing, the need for Agile adoption guidance also increases. Over the past years, Agile Maturity Models (AMMs) have been proposed to offer guidelines in Agile adoption. Agile maturity models (AMMs) suggest that Agile practices are introduced in a specific order. However, a number of evaluations of AMMs show that they are not properly validated and not suited for use in industry. Current evaluations of AMMs are based on certain criteria and not based on empirical studies. There are no studies that evaluate AMMs' suggestion to introduce Agile in certain order against industry practice. The relevance of the AMMs in the industry is not yet examined.

In this study, we conducted a literature review to identify the order of Agile practice introduction mentioned in AMMs. We then compared the AMMs' suggestions to the strategies used by practitioners, which we elicited from a survey and a series of interviews.

The literature survey revealed 12 AMMs which provide explicit mappings of Agile practices to maturity levels. These mappings show that the AMMs are not in agreement pertaining to the which practice is to be included in which maturity levels. The AMMs do not provide clear information nor rationale why certain practices need to be introduced in a specific maturity level. Comparison of the AMMs suggestions and the empirical study revealed that the guidance suggested by AMMs are not aligned with industry practice. The AMMs take a simplistic view of introducing Agile practices in a pre-determined order without consideration of the different contexts in industry. Our study indicates that practitioners iteratively add, remove, and modify the set of Agile practices they use to match their needs and contexts. In addition, the AMMs do not consider the potential perceived trade-off of adding Agile practices, such as team member discomfort, conflicts with other teams, and recurring bugs.

Currently, AMMs do not provide sufficient information to guide Agile adoption in the industry. Associating Agile maturity with sets of Agile practices is inadequate and too simplified. Our results suggest that there might be no universal strategy for Agile adoption that works better than others.

ABSTRACT. Agile Software Development (ASD) has several limitations concerning its requirements engineering activities. Motivated by this scenario, we performed a systematic mapping (SM) that investigated the phenomenon of the requirements specification activity in different agile projects. The results of the SM pointed out several factors (positive and negative) related to the quality of software requirements specification in ASD. Then, we conducted six industrial case studies in different contexts to investigate and characterize the requirements specification activity in ASD. Data collected from documents, observations, and interviews with software engineers were analyzed, synthesized and triangulated using Grounded Theory and Meta-Ethnography. The analysis and cross-synthesis of the six case studies resulted in an explanatory model providing a deep description of the factors that should be considered in order to write more useful Software Requirements Specifications (SRSs) in ASD. The factors found in the SM were confirmed by the emerged model. In addition, this model defines the simplicity and objectivity as essential quality factors of SRSs in ASD. The main factors affecting the SRSs quality in ASD projects are related to their customer-driven nature that leads to prolix SRSs, hindering their understanding from the developer perspective. The findings of this investigation are also reinforced by other studies indicating that SRSs in agile projects are insufficient for the coding activity. The emerged model is supported by explanations and provides a deeper understanding of the requirements specification activity in ASD. This creates opportunities for further studies and improvements in the requirements specification activity for ASD in industry. In fact, improving the quality of SRSs in ASD may help to gain a competitive advantage in the software industry.

ABSTRACT. Context: Requirements Engineering (RE) is one of the key processes in software development. Since Agile software development advocates continuous improvement, the question arises which Agile RE practices are the most essential and shall be adopted/improved at first? Objective: Investigate and rank the Agile RE practices based on how practitioners perceive their importance for a software project. Method: We conducted a survey asking 136 Agile software development practitioners how they perceive the importance of the 31 Agile RE practices that we had identified in a literature study. We used a ranking method based on the PROMETHEE family methods to create the ranking of relative importance of the practices. Results: The opinions of respondents from a wide range of countries around the globe allowed us to determine the perceived importance of the Agile RE practices and create a seven-tier ranking of the practices. Moreover, the analysis concerning demographic data let us identify some relationships between the experience of the respondents and their view on the importance of the Agile RE practices. Conclusions: Our findings suggest the most critical Agile RE practices are those supporting iterative development with emergent requirements and short feedback loop. Moreover, in many cases, the perceived importance of practices seems to depend on the context of the project (e.g., methodology, domain). We also learned that the popularity of the practices is highly correlated with their perceived importance.

ABSTRACT. Context: Organizations are increasingly challenged by dynamic and technical market environments. Traditional product roadmapping practices such as detailed and fixed long-term planning typically fails in such environments. Therefore, companies are actively seeking ways to improve their product roadmapping approach. Goal: This paper aims at identifying problems and challenges with respect to product roadmapping. In addition, it aims at understanding how companies succeed in improving their roadmapping practices in their respective company contexts. The study focuses on mid-sized and large companies developing software-intensive products in dynamic and technical market environments. Method: We conducted semi-structured expert interviews with 15 experts from 13 German companies and conducted a thematic data analysis. Results: The analysis showed that a significant number of companies is still struggling with traditional feature-based product-roadmapping and opinion-based prioritization of features. The most promising areas for improvement are stating the outcomes a company is trying to achieve and making them part of the roadmap, sharing or co-developing the roadmap with stakeholders, and the establishing discovery activities.

ABSTRACT. Data protection has become increasingly important in recent years, partly due to the EU General Data Protection Regulation (GDPR) and similar legislations in other countries, but also because of various privacy scandals which led to bad press for the affected companies. Since most of the processing of the relevant personal data is performed by software, data protection needs to be addressed in the development of software. This paper therefore investigates how to incorporate data protection in the software life cycle. Based on a simple default life cycle model, the main questions to ask and issues to address for this purpose in the various phases are summarized. However, these questions and issues are independent of the exact life cycle model used, whether plan-driven, agile or some hybrid, and can therefore easily be mapped to some other model. Not surprisingly, data protection mainly affects the analysis and design of software systems (``privacy by design'') when the data to be processed and stored, as well as the form of processing and the protection mechanisms to be used are defined. Nevertheless, to some extent the entire life cycle down to withdrawal is affected.

ABSTRACT. Product Configuration Systems (PCS) are software applications supporting the design of products tailored to the individual desiderata of customers. PCS development does not follow the same procedure as traditional software: indeed, due to its nature, specific knowledge needs to be collected, a set of custom engineering stages have thus been built-up. Within these stages, special requirements representation and design artifacts are used notably to deal with features inter-dependencies. More specifically, the Product Variant Master (PVM) has been specifically created for PCS knowledge representation while Class-Responsibility-Collaboration (CRC) cards and a UML Class Diagram are often indispensable for PCS object-oriented design. PCS development projects have gradually started to use agile methods like the Scrum. This paper presents a process fragment for conducting PCS development projects with Scrum; it overviews how the development team of a specific organization adapted the agile process to the PCS context. This process fragment has indeed been built on the basis of practitioners knowledge collected through 5 qualitative interviews (inductive approach) and exhaustively depict the activities performed by the team on PCS development projects of various size and context. Represented using an i* Strategic Rationale Diagram, it includes 6 developer roles but also one operator role (the infrastructure manager) to properly deal with the integration of releases in the organization's software ecosystem. We point to its use as a first guidance for PCS development teams willing to conduct projects using Scrum.

ABSTRACT. Agile software development has been applied since the early 2000s. It is now mainstream industrial practice in ICT companies and IT organizations. However, recently increasing and even disruptive digitalization has brought new drivers and needs for Agile both in software organizations as well as in traditional companies which are becoming more and more software-intensive. Following that line of developments, based on our recent survey conducted in Finland in 2018, in this paper we explore the current state of the affairs with respect to how different organizations currently address agility and how significantly digitalization affect that in different industrial sectors. The results show that operative goals (productivity, quality) are considered to be the most important ones to achieve by agile means. Scrum, Kanban and DevOps are the most frequently reported methods, and SAFe is the dominant scaling model. Lead time metrics are the most typically followed measurements. The operative goals as well as responsiveness are also the most highly ranked future aims. The impacts of digitalization are considered to be significant but agile developments are seen to address them well. As a conclusion of this survey study, there is no “one Agile” for all. Different organizations seem to emphasize multiple aspects of agility when they develop, adapt and even transform themselves. Yet, also many commonalities were indicated.

ABSTRACT. Connecting vehicles to cloud platforms has enabled innovative business scenarios while raising new quality concerns, such as reliability and scalability, which must be addressed by research. Cloud-native architectures based on microservices are a recent approach to enable continuous delivery and to improve service reliability and scalability. We propose an approach for restructuring cloud platform architectures in the automotive domain into a microservices architecture. To this end, we adopted and implemented microservices patterns from literature to design the cloud-native automotive architecture and conducted a laboratory experiment to evaluate the reliability and scalability of microservices in the context of a real-world project in the automotive domain called Eclipse Kuksa. Findings indicated that the proposed architecture could handle the continuous software delivery over-the-air by sending automatic control messages to a vehicular setting. Different patterns enabled us to make changes or interrupt services without extending the impact to others. The results of this study provide evidences that microservices are a potential design solution when dealing with service failures and high payload on cloud-based services in the automotive domain.

ABSTRACT. Adopting microservices include specific concerns on design, development and deployment. Assuring architecture design alignmed with business requirements may be supported by architectural modeling methods. However, there is still lack of modeling methods that cover microservices principles. In this paper, microservices logical architectures are derived from functional requirements, which are modeled in SoaML diagrams. This paper discusses design, data management, inter-service communication and automatization based in the derived architecture diagram.

ABSTRACT. While several service-based maintainability metrics have been proposed in the scientific literature, tool support to automatically collect these metrics is lacking. Since static analysis is complicated in decentralized and technologically diverse microservice-based systems, we propose a dynamic approach to calculate such metrics from runtime data via distributed tracing. The approach focuses on simplicity, extensibility, and broad applicability. As a first prototype, we implemented a Java application with a Zipkin integrator, 23 different metrics, and five export formats. We demonstrated the feasibility of the prototype by analyzing the runtime data of an example microservice-based system. During an exploratory study with six participants, 14 of the 18 services were invoked via the system's web interface. For these services, all metrics were calculated correctly from the generated traces.

ABSTRACT. Design by contract is a paradigm that aims at capturing the interactions of different software components, and formalizing them so that they can be relied upon in other phases of the design. Such a characteristic is especially helpful in the context of microservice architecture, where each service is an independent entity that can be individually (re)deployed. With contracts, testing of microservice based systems can be improved so that also the integration of different microservices can be tested in isolation by the developers working on the system. In this paper, we study how systems based on microservice architecture and their integrations can be tested more effectively by extending the testing approach with consumer-driven contract tests. Furthermore, we study how the responsibilities and purposes of each testing method are affected when introducing the consumer-driven contract tests to the system.

ABSTRACT. Collaborative software development requires developers to communicate with each other. Communication via instant messaging (e.g., Slack) supports collaboration by enabling discussions and knowledge sharing in small groups, companies and physically distributed teams. Recently, various messaging tools have been released. In this work, we introduce a comparison framework aiming at evaluating team-based communication channels for (a) practitioners interested in using or improving instant messaging as part of their project and team communication, and (b) researchers interested in utilising team communication channels to answer research questions (e.g., to analyse developer communication through mining studies). The framework includes criteria derived from other empirical works and industrial experience reports related to development tools. We illustrate the framework by analysing four communication tools (Microsoft Teams, Slack, Gitter, Spectrum).

ABSTRACT. Vehicles innovation is nowadays principally driven by electronics components and software that play today a predominant role for the vehicle’s functions. Because the quality of on-board automotive electronic systems is strongly dependent on the quality of their development practices, car-makers and suppliers proactively focused on improvement of technical and organizational processes. In this setting, several reference standards for the assessment and improvement of automotive electronics processes and projects have been conceived and used in the last decade, among them the most popular and impacting is Automotive SPICE. Although the effects of the application of SPI standards in automotive industry in the last decade have been generally positive, some drawbacks and weaknesses can be identified from their actual application on the field. This paper aims at showing that an alternative sound approach, able to overtake some of the weaknesses of automotive SPI initiatives as well as to address relevant process improvement success factors is viable. Such a new approach is based on a recently developed scheme (named PISA Model) able to address both project evaluation and process improvement and targeting a hand-on approach for the practitioners. The PISA Model allows the evaluation of software development project by addressing the quality characteristic of Adequacy. The PISA Model provides the automotive community with a quality model with innovative features that targets the specific needs of the automotive industry in the context of the development of electronic systems. This paper presents an overview of the PISA Model with specific focus on the its added value with respect other reference standards used in automotive.

ABSTRACT. This work proposes a new unsupervised deep generative model for system logs. It is designed to be generic and may be used in various downstream anomaly detection tasks, such as system failure or intrusion detection. It is based on the (reasonable) assumption that most log lines follow rather fixed syntactic structures, which enables us to replace the costly traditional convolutional and recurrent architectures by a much faster component: a deep averaging network. Our model still exploits a standard recurrent model with attention to capture the dependencies between successive log lines. We experimentally validate the proposed generative model on a real dataset obtained from a state-of-the-art High Performance Computing cluster and show the effectiveness of the proposed approach in modeling the "normal" behaviour of the system.

ABSTRACT. Software startups are temporary organizations that develop innovative software-intensive products or services. Although numerous successful stories, most startups fail. Several methodologies were proposed both in the scientific and commercial literature, and a common element among them is the idea of experimentation. This concept was brought to software development as an approach focused on taking critical product assumptions as hypotheses and developing experiments to support or refute them. Although well-known methodologies are based on this idea, the literature shows that software startups still do not follow this approach. The goal of this paper is to identity the enablers and inhibitors of experimentation use in early-stage software startups. To achieve the goal, we performed a multiple-case study of four software startups following a theoretical sampling strategy. The results comprise of a set of enablers and inhibitors divided into individual, team, and environmental.