Abstract. Background: Agile techniques recently have received attention from the developers of safety-critical systems. However, a lack of empirical knowledge of performing safety assurance techniques, especially safety analysis in a real agile project hampers further steps. Aims: In this article, we aim at (1) understanding and optimizing the S-Scrum development process, a Scrum extension with the integration of a systems theory based safety analysis technique, STPA (System-Theoretic Process Analysis), for safety-critical systems; (2) validating the Optimized S-Scrum development process further. Method: We conducted a two-stage exploratory case study in a student project at the University of Stuttgart, Germany. Results: The results in stage 1 showed that S-Scrum helps to ensure safety of each release but is less agile than the normal Scrum. We explored six challenges on: priority management; communication; time pressure on determining safety requirements; safety planning; time to perform upfront planning; and safety requirements' acceptance criteria. During stage 2, the safety and agility have been improved after the optimizations, including an internal and an external safety expert; pre-planning meeting; regular safety meeting; an agile safety plan; and improved safety epics and safety stories. We have also gained valuable suggestions from industry, but the generalization problem due to the specific context is still unsolved.

Background. Today, redundancy in source code, so-called ''clones'' caused by copy &paste can be found reliably using clone detection tools. Redundancy can arise also independently, however, not caused by copy&paste. At present, it is not clear how only functionally similar clones (FSC) differ from clones created by copy&paste. Our aim is to understand and categorise the syntactical differences in FSCs that distinguish them from copy&paste clones in a way that helps clone detection research. Methods. We conducted an experiment using known functionally similar programs in Java and C from coding contests. We analysed syntactic similarity with traditional detection tools and explored whether concolic clone detection can go beyond syntax. We ran all tools on 2,800 programs and manually categorised the differences in a random sample of 70 program pairs. Results. We found no FSCs where complete files were syntactically similar. We could detect a syntactic similarity in a part of the files in <16% of the program pairs. Concolic detection found 1 of the FSCs. The differences between program pairs were in the categories algorithm, data structure, OO design, I/O and libraries. We selected 58 pairs for an openly accessible benchmark representing these categories. Discussion. The majority of differences between functionally similar clones are beyond the capabilities of current clone detection approaches. Yet, our benchmark can help to drive further clone detection research.

Communication is essential in software engineering. Especially in distributed open-source teams, communication needs to be supported by channels including mailing lists, forums, issue trackers, and chat systems. Yet, we do not have a clear understanding of which communication channels stakeholders in open-source projects use. In this study, we fill the knowledge gap by investigating a statistically representative sample of 400 GitHub projects. We discover the used communication channels by regular expressions on project data. We show that (1) half of the GitHub projects use observable communication channels; (2) GitHub Issues, e-mail addresses, and the modern chat system Gitter are the most common channels; (3) mailing lists are only in place five and have a lower market share than all modern chat systems combined.