DOCSLIB.ORG

On the Impact of Affect in Software Engineering

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
On the Impact of Affect in Software Engineering UNIVERSITÉ DE MONTRÉAL ON THE IMPACT OF AFFECT IN SOFTWARE ENGINEERING PARASTOU TOURANI DÉPARTEMENT DE GÉNIE INFORMATIQUE ET GÉNIE LOGICIEL ÉCOLE POLYTECHNIQUE DE MONTRÉAL THÈSE PRÉSENTÉE EN VUE DE L’OBTENTION DU DIPLÔME DE PHILOSOPHIÆ DOCTOR (GÉNIE INFORMATIQUE) DÉCEMBRE 2016 c Parastou Tourani, 2016. UNIVERSITÉ DE MONTRÉAL ÉCOLE POLYTECHNIQUE DE MONTRÉAL Cette thèse intitulée: ON THE IMPACT OF AFFECT IN SOFTWARE ENGINEERING présentée par: TOURANI Parastou en vue de l’obtention du diplôme de: Philosophiæ Doctor a été dûment acceptée par le jury d’examen constitué de: M. BELTRAME Giovanni, Ph. D., président M. ADAMS Bram, Doctorat, membre et directeur de recherche M. KHOMH Foutse, Ph. D., membre Mme SHARIF Bonita, Ph. D., membre externe iii DEDICATION This thesis is lovingly dedicated to my mother, Akhtar Ganji. iv ACKNOWLEDGEMENTS Firstly, I would like to express my sincere appreciation to my advisor Dr. Bram Adams for the continuous support of my Ph.D study and for his patience, motivation, and immense knowledge. Besides my advisor, I would like to thank the rest of my thesis committee: Dr. Bonita Sharif, Dr. Foutse Khomh, and Dr. Giovanni Beltrame for accepting my invitation to be jury members, Dr. Sofiane Achiche to be representative of my defense. My sincere thanks also goes to Prof. Giuliano Antoniol, Prof. Yann-Gaël Guéhéneuc, Dr. Alexander Serebrenik, and Dr. Peter Rigby that gave me insightful advice in my academic life. Last but not least, I would like to thank every single one of my labmates who created such a good positive atmosphere in the lab: Zohreh, Yujuan, Mahdis, Rodrigo, Azadeh, Zephyrin, Armstrong, Le, Mbarka, Ons, Laleh, Venera, and Rubén. Thank you so much for be the part of my life. v RÉSUMÉ Selon les études scientifiques, l’une des meilleures façons d’améliorer la performance des développeurs de logiciels peut être réalisée en se concentrant sur les individus. Par exemple, Agile Manifesto a évalué les individus et leurs interactions sur les processus et les outils, tout en mettant l’accent sur le fait de fournir un environnement favorable et souhaitable aux employés. En outre, les recherches menées dans les autres domaines comme la psychologie, le comportement économique et organisationnel révèlent que le bien-être émotionnel des gens agit comme une force causale de leur productivité. Les affects d’individus, c’est-à-dire leurs émotions, leurs sentiments et leur humeur influencent sur leur comportement et leurs inter- actions et, par conséquent, le développement de logiciels en tant qu’activité collaborative des développeurs peuvent également être influencé par ces affects. Surtout sachant que le développement logiciel est un processus complexe, cognitif et intellectuel, ces affects peuvent avoir un impact significatif sur son succès. Jusqu’à présent, très peu d’études ont été menées dans un contexte de génie logiciel pour étudier comment les affects des développeurs pour- raient influencer le processus de développement logiciel et quelles conséquences ils peuvent apporter. Cette thèse vise à étudier le lien entre les affects des développeurs et les aspects cruciaux du processus d’ingénierie logicielle, il s’agit de la qualité du travail en résultat et le temps nécessaire pour y parvenir. À cette fin, nous avons effectué plusieurs études empiriques sur des projets "open source" populaires. Dans un premier temps, nous avons essayé d’analyser la présence d’affects dans des artefacts de génie logiciel/ de l’ingénierie du logiciel, d’inspecter leurs significations dans ce contexte et de vérifier la faisabilité du support automatique d’outil pour la détection de l’affect dans le domaine du génie logiciel/ de l’ingénierie du logiciel grâce à ces études empiriques. Ensuite, deux grandes études de cas empiriques ont été réalisées pour analyser l’impact des systèmes métriques liés affectifs. Dans la première étude, nous avons examiné l’impact de divers facteurs, y compris le sentiment de l’issue et les commentaires sur la défectuosité-pronostic d’un correctif. Ensuite, les commentaires ont laissé dans le repérage de la sortie et des dépôts utilisés comme proxy pour les discussions humaines. Les modèles explicatifs ont montré une précision et un rappel significatif, en particulier en raison de l’impact des facteurs humains de la discussion humaine, tandis que les paramètres liés au sentiment y jouent également un rôle. Dans notre deuxième étude, nous nous sommes concentrés sur la durée de l’examen du code et la résolution des problèmes, qui sont deux activités principales dans le développement de logiciels. Bien que cette étude utilise les mêmes données que l’étude précédente, les facteurs analysés l’ont plus largement été sélectionnés, vi par exemple, pour les facteurs liés à l’affect, les mesures, y compris le sentiment, l’émotion et la politesse des commentaires ont été calculés. Les facteurs liés à l’affect sont apparus parmi les 10 principaux éléments influents des modèles proposés. Tandis que, des modèles explicatifs forts ont été obtenus avec une haute précision et un rappel élevé, c’est-à-dire plus de 75% pour aussi bien la précision que pour le rappel. Les découvertes de ces deux études ont révélé que des facteurs concernant l’affect ont un impact sur de principales mesures du processus de développement de logiciels, incluant la qualité et le temps pris pour mettre fin aux activités principales, il s’agit de l’examen de code et la résolution des problèmes (publication). Cela est encore plus important pour les projets "open source", car récemment, de nombreux projets "open source" populaires et même des référentiels de code comme Github ont commencé à chercher une solution possible pour traiter des conflits, sous forme de codes de conduite. De grands projets logiciels, comme des projets "open source", sont construits et entretenus en collaboration par des équipes de développeurs et de testeurs, qui sont typiquement et géographiquement dispersés. Cette dispersion crée une distance entre des membres de l’équipe, cachant des sentiments de détresse ou (un) bonheur de leur gestionnaire, ce qui les empêche d’utiliser des techniques de remédiation de ces sentiments. La mesure automatique de l’incidence des artefacts du génie logiciel peut aider des gestion- naires à contrôler leurs environnements d’équipe en fonction de leurs besoins et à augmenter leur conscience émotionnelle. Cela pourrait finalement conduire à une meilleure prise de décision pour ces directeurs au moment désiré à stimuler l’ambiance de leur équipe et de traiter des conflits ou des obstacles avant qu’ils deviennent perplexes et insolubles. Nous avons conduit une étude empirique pour comprendre des codes de conduite et leur rôle dans des projets "open source". Nous espérons que cette évaluation de codes de conduite et nos résultats avec des mesures d’affect automatisées pourront permettre aux praticiens de non seulement remarquer des problèmes, mais également d’évaluer des contre-mesures éventuelles à prendre. vii ABSTRACT According to scientific studies, one of the best ways to improve software developers’ per- formance is by focusing on people. For instance, Agile manifesto valued individuals and their interactions over processes and tools, while emphasizing a supportive and desirable en- vironment for employees. Moreover, research in other fields like psychology, economic and organizational behaviour reveals that emotional well-being of people acts as a causal force for their productivity. Affects of individuals, i.e. their emotions, feelings, and mood influence human behaviour and interactions, and therefore, software development as a collaborative activity of developers can be influenced by affect too. Especially knowing that software de- velopment is a complex, cognitive, and intellectual process, affect might have a significant impact on its success. So far, very few studies have been conducted in a software engineering context to investigate how developer affect may influence the software development process and what consequences they can bring about. This PhD dissertation aims to investigate the link between affect of developers and important aspects of software engineering process, i.e., quality of the resulting work and the time taken to achieve it. For this purpose, we conducted several empirical studies on popular open source projects. First, we tried to analyze the presence of affects in software engineering artifacts, inspect their meanings in this context and verify the feasibility of automatic tool support for affect detection in the software engineering domain through empirical studies. Next, two large empirical case studies were done to analyze the impact of affective-related metrics. In the first study, comments left in the issue tracking and review repositories were considered as proxy for human discussions. Then, we investigated the impact of various factors including sentiment of issue and review comments on defect-proneness of a patch. Explanatory models showed significant precision and recall, especially due to the impact of human discussion factors while sentiment-related metrics play a role in them too. In our third study, we focused on the duration of code reviewing and issue resolution, which are two major activities in software development. While this study used the same data as the previous study, the analyzed factors were selected more widely, for instance, for affect- related factors, measurements including sentiment, emotion and politeness of comments were computed. Affect-related factors appeared among the top 10 influential factors of proposed models. While, strong explanatory models were obtained with high precision and recall, i.e., mostly higher than 75% for both precision and recall. Findings of these last two studies revealed that affect-related factors impact major metrics in viii software development process including quality and time taken to finish main activities, i.e., code reviewing and issue resolution. This is even more important for open source projects, since recently, many popular open source projects and even code repository like Github started to look for a possible solution to deal with conflicts, in the form of codes of conduct.
Load more

Recommended publications
  • Discrimination Against Intersex People in Codes of Conduct
    Discrimination against Intersex people in codes of conduct Introduction In the FOSS world there has been, over the better part of the last decade, a strong push to make most communities more accepting of the differences in its midst and foster a welcoming environment. Not to mention ensure that certain types of incidents in a number of communities never occurred again. These are laudable goals and there are few who would disagree with the intent. The problem here is not with the intent, though, it's with the execution. Specifically with the adoption and enforcement of the Contributor Covenant,1 the Community Covenant,2 and certain source documents upon which those are based.3 What is Intersex? The simplest working definition of intersex, as published by Intersex Human Rights Australia (IHRA) is: Intersex people are born with physical sex characteristics that don’t fit medical and social norms for female or male bodies.4 While the United Nations' Office of the High Commissioner for Human Rights (UN OHCHR) used this definition in the 2019 background briefing note on intersex human rights issues: Intersex is an umbrella term used to describe a wide range of innate bodily variations of sex characteristics. Intersex people are born with physical sex characteristics (such as sexual anatomy, reproductive organs, hormonal patterns and/or chromosomal patterns) that do not fit typical definitions for male or female bodies.5 The IHRA website provides a very gentle introduction to what this all means and addresses some common misconceptions of intersex
    [Show full text]
  • Growing Open Source Projects with a Stable Foundation
    Growing Open Source Projects with a Stable Foundation Martin Michlmayr April 2021 Preface Starting an open source project is easy. Running a successful project, on the other hand, comes with a lot of work and responsibilities, especially if the project attracts a large user base. While open source projects come in all shapes and forms, most projects encounter a similar set of growth issues throughout their life cycles. Because of this, various organizations have arisen to help projects handle these problems; these organizations are generally known as FOSS foundations. This primer covers non-technical aspects that the majority of projects will have to consider at some point. It also explains how FOSS foundations can help projects grow and succeed. This primer explains: • What issues and areas to consider • How other projects and foundations have approached these topics • What FOSS foundations bring to the table • How to choose a FOSS foundation ii Contents Contents iii Background1 1 Open source as digital infrastructure2 2 Growth issues3 3 The role of foundations4 Governance5 4 Open collaboration6 5 Level playing field8 6 Technical governance9 7 Stability and institutional memory 10 8 Conflict resolution 12 Community growth 14 9 Incubation 15 10 Mentorship 17 11 Marketing and promotion 18 iii 12 Culture 19 13 Community health 21 Financial 22 14 Fundraising 23 15 Spending 25 16 Face-to-face meetings 26 17 Development 27 18 Asset stewardship 29 19 Transparency 30 Legal 31 20 Licensing and copyright 32 21 Trademarks 33 22 Patents 35 23 Liability
    [Show full text]
  • 12 Years of Iphone – a Developer's Perspective
    12 Years of iPhone – A Developer’s Perspective Adrian Kosmaczewski 2019-04-21 This is the talk that I gave in the 4th MCE Conference in Warsaw, Poland, on May 8th, 2017 (conference organized by Polidea) and (with updates) at UIKonf on May 15th, 2018 and at NSConfArg on April 20th, 2019. • Introduction • 2007 • 2008 • 2009 • 2010 • 2011 • 2012 • 2013 • 2014 • 2015 • 2016 • 2017 • 2018 And Beyond • Slides • Video Introduction The iPhone celebrates its 12th anniversary this year. From a historical point of view, it had a tremendous impact in the industry and the careers of those involved in mobile application software development. At some point in my career, I was a .NET developer, and then one day I told myself that I wanted to write Objective-C for a living. This is how I started my career in this galaxy. This is how I got here. I could have chosen Windows Mobile. I could have chosen BlackBerry. I chose the iPhone. I started working on my first iPhone application back in July 2008, and back then everybody, and I mean every single person in the industry around me, told me that I was completely crazy and/or stupid for losing my time with a device nobody would buy. I have not stopped writing iOS applications ever since, even though lately I’ve been spending quite a bit of time around Android. 1 The iPhone turned out to be a far, far bigger platform than any of us could ever imagine. In this talk I am going to take you in a trip back in time, to remember frameworks, people, companies, events and projects that have marked our craft in the past decade.
    [Show full text]
  • Building a Successful Open Source Community Alan Turing Institute 4Th July 2019
    Building a Successful Open Source Community Alan Turing Institute 4th July 2019 The content of this presentation is available under the terms of the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license See https://creativecommons.org/licenses/by-sa/4.0/ for more information Modified versions must remove Red Hat trademarks. OPTIONAL SECTION MARKER OR TITLE About us “”Engineering Manager @ Red Hat (7 months) “”Senior Software Engineer @RedHat (4 years) Software Engineer @ Red Hat (6 months) IT jobs @Newcastle University (10 years) Research Associate @NCL (15 years) Debian contributor (14 years) p/t PhD student (CS, 2 years) Simon Woodman Jonathan Dowland Engineering Manager | AMQ Streams & Knative Eventing Senior Software Engineer | OpenJDK 2 Source: Insert source data here Insert source data here Insert source data here Who drives Open Source software? We know what OS software is but who drives it? Yes, you can put your software on GH but is that really maximising the value? The maximum bang for your buck? You tick a few boxes - your boss is happy, the funders are happy. But who drives the progress in that project? It's the developers and the community So, what is a community? Who drives Open Source software? 5 Reasons to build a community around your project 5 Reasons to NOT build a community around your project 1. Time It takes a lot of time to build the community which obviously takes time away from other things you could be doing ● Publicity ● Helping people ● Documentation, documentation, documentation ● Letting others learn which will take longer than doing it yourself 2.
    [Show full text]
  • Linux Process Documentation
    Linux Process Documentation The kernel development community Jul 14, 2020 CONTENTS i ii Linux Process Documentation So you want to be a Linux kernel developer? Welcome! While there is a lot to be learned about the kernel in a technical sense, it is also important to learn about how our community works. Reading these documents will make it much easier for you to get your changes merged with a minimum of trouble. Below are the essential guides that every developer should read. CONTENTS 1 Linux Process Documentation 2 CONTENTS CHAPTER ONE LINUX KERNEL LICENSING RULES The Linux Kernel is provided under the terms of the GNU General Public License version 2 only (GPL-2.0), as provided in LICENSES/preferred/GPL-2.0, with an explicit syscall exception described in LICENSES/exceptions/Linux-syscall-note, as described in the COPYING file. This documentation file provides a description of how each source file shouldbe annotated to make its license clear and unambiguous. It doesn’t replace the Kernel’s license. The license described in the COPYING file applies to the kernel source as a whole, though individual source files can have a different license which is required tobe compatible with the GPL-2.0: GPL-1.0+ : GNU General Public License v1.0 or later GPL-2.0+ : GNU General Public License v2.0 or later LGPL-2.0 : GNU Library General Public License v2 only LGPL-2.0+ : GNU Library General Public License v2 or later LGPL-2.1 : GNU Lesser General Public License v2.1 only LGPL-2.1+ : GNU Lesser General Public License v2.1 or later Aside from that, individual files can be provided under a dual license, e.g.one of the compatible GPL variants and alternatively under a permissive license like BSD, MIT etc.
    [Show full text]