Beyond Textual Issues: Understanding the Usage and Impact of GitHub Reactions

Recently, GitHub introduced a new social feature, named reactions, which are "pictorial characters" similar to emoji symbols widely used nowadays in text-based communications. Particularly, GitHub users can use a pre-defined set of such symbols to react to issues and pull requests. However, little is known about the real usage and impact of GitHub reactions. In this paper, we analyze the reactions provided by developers to more than 2.5 million issues and 9.7 million issue comments, in order to answer an extensive list of nine research questions about the usage and adoption of reactions. We show that reactions are being increasingly used by open source developers. Moreover, we also found that issues with reactions usually take more time to be handled and have longer discussions.Comment: 10 page

An Exploratory Study of Productivity Perceptions in Software Teams

Software development is a collaborative process requiring a careful balance of focused individual effort and team coordination. Though questions of individual productivity have been widely examined in past literature, less is known about the interplay between developers' perceptions of their own productivity as opposed to their team’s. In this paper, we present an analysis of 624 daily surveys and 2899 self-reports from 25 individuals across five software teams in North America and Europe, collected over the course of three months. We found that developers tend to operate in fluid team constructs, which impacts team awareness and complicates gauging team productivity. We also found that perceived individual productivity most strongly predicted perceived team productivity, even more than the amount of team interactions, unplanned work, and time spent in meetings. Future research should explore how fluid team structures impact individual and organizational productivity

Google Summer of Code: Student Motivations and Contributions

Several open source software (OSS) projects expect to foster newcomers' onboarding and to receive contributions by participating in engagement programs, like Summers of Code. However, there is little empirical evidence showing why students join such programs. In this paper, we study the well-established Google Summer of Code (GSoC), which is a 3-month OSS engagement program that offers stipends and mentors to students willing to contribute to OSS projects. We combined a survey (students and mentors) and interviews (students) to understand what motivates students to enter GSoC. Our results show that students enter GSoC for an enriching experience, not necessarily to become frequent contributors. Our data suggest that, while the stipends are an important motivator, the students participate for work experience and the ability to attach the name of the supporting organization to their resum\'es. We also discuss practical implications for students, mentors, OSS projects, and Summer of Code programs.Comment: 30 page

Técnicas para realizar a validação de requisitos no contexto de internet das coisas (IoT)

Trabalho de conclusão de curso (graduação) — Universidade de Brasília, Instituto de Ciências Exatas, Departamento de Ciência da Computação, 2021.A internet das coisas vem ocupando um espaço cada vez maior em equipes de desenvolvi mento de software e na sociedade. O nível de aplicação da IoT é abrangente. Tráfego de pessoas, casas inteligentes, ambientes otimizados e gestão de água/energia são alguns dos exemplos da sua aplicabilidade. Nesse universo de possibilidades, desenvolvedores e empresas de tecnologia devem estar preparados para adaptar seus projetos e absorver essa tecnologia em expansão. Como essa tecnologia é recente, falhas de projeto e retrabalho acontecem com frequência e dificultam o desenvolvimento de produtos de alta qualidade atualmente. O objetivo deste trabalho é identificar por meio de uma pesquisa explo ratória, processos e técnicas de validação, voltadas ao contexto da internet das coisas. Além disso, investigamos a percepção dos desenvolvedores de software IoT sobre as suas atividades relacionadas a Engenharia de Requisitos em seus projetos. A percepção dos profissionais foi coletada através de entrevistas onde eles relataram as dificuldades e de safios que enfrentam durante suas atividades diárias. Foram encontrados 22 processos e 9 técnicas de validação para o contexto de IoT na literatura. A partir das entrevistas, foi possível perceber que stakeholders de projetos IoT não utilizam um processo formal de engenharia de requisitos. Normalmente, são utilizadas técnicas distintas como reuniões e diagramas, sempre com base na demanda e na necessidade do projeto. Apesar dos profissionais e stakeholders acharem importante a Engenharia de Requisitos, a adesão à processos e técnicas voltadas a IoT não é unânime devido a curva de aprendizado para adotar novos métodos e a falta de maleabilidade nos processos durante o desenvolvimento de software.Internet of things occupies more and more space in development teams and in society in general. The applicability that IoT covers is huge. Smart houses, water/energy consup tion, traffic management and smart buildings are some examples of what has been made in this context. In this vast universe of possibilities, developers and tech companies need to be prepared and adapt their projects to cover it. With that in mind, failures/reworks in projects happens more easily and makes it more difficult to produce high standards products. The objective of this paper is to identify, based on a exploratory research, processes and validation techniques in IoT context. Furthermore, this work investigates the professionals‘ perception in their activities with requirenment engineering in IoT projects. Their reports were collected through interviews so they could explain the difficulties and problems that arise in their daily work. In total, 22 processes and 9 validation techniques has been found in literature. From the interviews, it had been realized that stakeholders don´t use formal processes in their IoT projects. Usually, single techniques are used, like reunions and diagramans, to handle the requirements engineering.The stakeholders implement these methods based on the demand and size of the project. Although stakeholders thinks that RE is a important part inside a project, the use of processes and techniques for IoT development isn´t unanimous due to the learning curve to adopt such methods and the lack of flexibility in these processes during the development phase

Processos da engenharia de requisitos no contexto de internet das coisas (IoT) e técnicas de validação de requisitos

Trabalho de conclusão de curso (graduação)—Universidade de Brasília, Instituto de Ciências Exatas, Departamento de Ciência da Computação, 2021.A Internet das Coisas possibilitou um engrandecimento nas possibilidades de automação e de facilitação do cotidiano das pessoas. Desde automação residencial até a edifícios inteligentes, o aumento da popularidade da IoT traz um desafio para o desenvolvimento de software e a engenharia de requisitos. Desenvolvedores e empresas não estão familiarizados com os processos e técnicas de validação de requisitos existentes no contexto de sistema IoT. Por conta disso, possíveis falhas de projeto e retrabalhos durante o desenvolvimento de software são problemas a serem considerados pelas equipes de desenvolvimento. O objetivo desse artigo é investigar na literatura os processos de engenharia de requisitos no contexto de IoT e as técnicas de validação de requisitos utilizadas. Além disso, apresentar um guia para apoiar as equipes de desenvolvimento de software a ter acesso fácil aos processos e técnicas propostas na literatura para este contexto. Nós realizamos um survey com os practitioners da indústria para investigar se eles usam e conhecem os processos e técnicas identificadas na literatura. Nossos achados revelam que a técnica mais utilizada pelos practitioners para realizar a especificação de requisitos são as reuniões com as partes interessadas e brainstorming e para validar requisitos são utilizados os protótipos e casos de uso.The Internet of Things made possible an increase in the possibilities of automation and facilitation of people’s daily lives. From home automation to smart buildings, the rise in IoT’s popularity brings a challenge to software development and requirements engineering. Developers and companies are not familiar with the requirements validation processes and techniques that exist in the context of an IoT system. Therefore, possible project failures and rework during software development are issues to be considered by development teams. The aim of this article is to investigate the requirements engineering processes in the IoT context and the requirements validation techniques used in the literature. Also, present a guide to support software development teams to have easy access to the processes and techniques proposed in the literature for this context. We conducted a survey of industry practitioners to investigate whether they use and know the processes and techniques identified in the literature. Our findings reveal that the technique most used by practitioners to perform requirements specification are stakeholders meeting and brainstorming and to validate requirements are prototypes and use cases

OSS architecture for mixed-criticality systems – a dual view from a software and system engineering perspective

Computer-based automation in industrial appliances led to a growing number of logically dependent, but physically separated embedded control units per appliance. Many of those components are safety-critical systems, and require adherence to safety standards, which is inconsonant with the relentless demand for features in those appliances. Features lead to a growing amount of control units per appliance, and to a increasing complexity of the overall software stack, being unfavourable for safety certifications. Modern CPUs provide means to revise traditional separation of concerns design primitives: the consolidation of systems, which yields new engineering challenges that concern the entire software and system stack. Multi-core CPUs favour economic consolidation of formerly separated systems with one efficient single hardware unit. Nonetheless, the system architecture must provide means to guarantee the freedom from interference between domains of different criticality. System consolidation demands for architectural and engineering strategies to fulfil requirements (e.g., real-time or certifiability criteria) in safety-critical environments. In parallel, there is an ongoing trend to substitute ordinary proprietary base platform software components by mature OSS variants for economic and engineering reasons. There are fundamental differences of processual properties in development processes of OSS and proprietary software. OSS in safety-critical systems requires development process assessment techniques to build an evidence-based fundament for certification efforts that is based upon empirical software engineering methods. In this thesis, I will approach from both sides: the software and system engineering perspective. In the first part of this thesis, I focus on the assessment of OSS components: I develop software engineering techniques that allow to quantify characteristics of distributed OSS development processes. I show that ex-post analyses of software development processes can be used to serve as a foundation for certification efforts, as it is required for safety-critical systems. In the second part of this thesis, I present a system architecture based on OSS components that allows for consolidation of mixed-criticality systems on a single platform. Therefore, I exploit virtualisation extensions of modern CPUs to strictly isolate domains of different criticality. The proposed architecture shall eradicate any remaining hypervisor activity in order to preserve real-time capabilities of the hardware by design, while guaranteeing strict isolation across domains.Computergestützte Automatisierung industrieller Systeme führt zu einer wachsenden Anzahl an logisch abhängigen, aber physisch voneinander getrennten Steuergeräten pro System. Viele der Einzelgeräte sind sicherheitskritische Systeme, welche die Einhaltung von Sicherheitsstandards erfordern, was durch die unermüdliche Nachfrage an Funktionalitäten erschwert wird. Diese führt zu einer wachsenden Gesamtzahl an Steuergeräten, einhergehend mit wachsender Komplexität des gesamten Softwarekorpus, wodurch Zertifizierungsvorhaben erschwert werden. Moderne Prozessoren stellen Mittel zur Verfügung, welche es ermöglichen, das traditionelle >Trennung von Belangen< Designprinzip zu erneuern: die Systemkonsolidierung. Sie stellt neue ingenieurstechnische Herausforderungen, die den gesamten Software und Systemstapel betreffen. Mehrkernprozessoren begünstigen die ökonomische und effiziente Konsolidierung vormals getrennter Systemen zu einer effizienten Hardwareeinheit. Geeignete Systemarchitekturen müssen jedoch die Rückwirkungsfreiheit zwischen Domänen unterschiedlicher Kritikalität sicherstellen. Die Konsolidierung erfordert architektonische, als auch ingenieurstechnische Strategien um die Anforderungen (etwa Echtzeit- oder Zertifizierbarkeitskriterien) in sicherheitskritischen Umgebungen erfüllen zu können. Zunehmend werden herkömmliche proprietär entwickelte Basisplattformkomponenten aus ökonomischen und technischen Gründen vermehrt durch ausgereifte OSS Alternativen ersetzt. Jedoch hindern fundamentale Unterschiede bei prozessualen Eigenschaften des Entwicklungsprozesses bei OSS den Einsatz in sicherheitskritischen Systemen. Dieser erfordert Techniken, welche es erlauben die Entwicklungsprozesse zu bewerten um ein evidenzbasiertes Fundament für Zertifizierungsvorhaben basierend auf empirischen Methoden des Software Engineerings zur Verfügung zu stellen. In dieser Arbeit nähere ich mich von beiden Seiten: der Softwaretechnik, und der Systemarchitektur. Im ersten Teil befasse ich mich mit der Beurteilung von OSS Komponenten: Ich entwickle Softwareanalysetechniken, welche es ermöglichen, prozessuale Charakteristika von verteilten OSS Entwicklungsvorhaben zu quantifizieren. Ich zeige, dass rückschauende Analysen des Entwicklungsprozess als Grundlage für Softwarezertifizierungsvorhaben genutzt werden können. Im zweiten Teil dieser Arbeit widme ich mich der Systemarchitektur. Ich stelle eine OSS-basierte Systemarchitektur vor, welche die Konsolidierung von Systemen gemischter Kritikalität auf einer alleinstehenden Plattform ermöglicht. Dazu nutze ich Virtualisierungserweiterungen moderner Prozessoren aus, um die Hardware in strikt voneinander isolierten Rechendomänen unterschiedlicher Kritikalität unterteilen zu können. Die vorgeschlagene Architektur soll jegliche Betriebsstörungen des Hypervisors beseitigen, um die Echtzeitfähigkeiten der Hardware bauartbedingt aufrecht zu erhalten, während strikte Isolierung zwischen Domänen stets sicher gestellt ist

On the real world practice of Behaviour Driven Development

Surveys of industry practice over the last decade suggest that Behaviour Driven Development is a popular Agile practice. For example, 19% of respondents to the 14th State of Agile annual survey reported using BDD, placing it in the top 13 practices reported. As well as potential benefits, the adoption of BDD necessarily involves an additional cost of writing and maintaining Gherkin features and scenarios, and (if used for acceptance testing,) the associated step functions. Yet there is a lack of published literature exploring how BDD is used in practice and the challenges experienced by real world software development efforts. This gap is significant because without understanding current real world practice, it is hard to identify opportunities to address and mitigate challenges. In order to address this research gap concerning the challenges of using BDD, this thesis reports on a research project which explored: (a) the challenges of applying agile and undertaking requirements engineering in a real world context; (b) the challenges of applying BDD specifically and (c) the application of BDD in open-source projects to understand challenges in this different context. For this purpose, we progressively conducted two case studies, two series of interviews, four iterations of action research, and an empirical study. The first case study was conducted in an avionics company to discover the challenges of using an agile process in a large scale safety critical project environment. Since requirements management was found to be one of the biggest challenges during the case study, we decided to investigate BDD because of its reputation for requirements management. The second case study was conducted in the company with an aim to discover the challenges of using BDD in real life. The case study was complemented with an empirical study of the practice of BDD in open source projects, taking a study sample from the GitHub open source collaboration site. As a result of this Ph.D research, we were able to discover: (i) challenges of using an agile process in a large scale safety-critical organisation, (ii) current state of BDD in practice, (iii) technical limitations of Gherkin (i.e., the language for writing requirements in BDD), (iv) challenges of using BDD in a real project, (v) bad smells in the Gherkin specifications of open source projects on GitHub. We also presented a brief comparison between the theoretical description of BDD and BDD in practice. This research, therefore, presents the results of lessons learned from BDD in practice, and serves as a guide for software practitioners planning on using BDD in their projects

Fundamental Approaches to Software Engineering

This open access book constitutes the proceedings of the 23rd International Conference on Fundamental Approaches to Software Engineering, FASE 2020, which took place in Dublin, Ireland, in April 2020, and was held as Part of the European Joint Conferences on Theory and Practice of Software, ETAPS 2020. The 23 full papers, 1 tool paper and 6 testing competition papers presented in this volume were carefully reviewed and selected from 81 submissions. The papers cover topics such as requirements engineering, software architectures, specification, software quality, validation, verification of functional and non-functional properties, model-driven development and model transformation, software processes, security and software evolution