Jil Klünder

Martin Obaidi, Marc Herrmann, Jendrik Martensen et al.

Communication is a crucial social factor in the success of software projects, as positively or negatively perceived statements can influence how recipients feel and affect team collaboration through emotional contagion. Whether a developer perceives a written message as positive, negative, or neutral is likely shaped by multiple factors. In this paper, we investigate how mood traits and states, life circumstances, project phases, and group dynamics relate to the perception of text-based messages in software development. We conducted a four-round survey study with 81 students in team-based software projects. Across rounds, participants reported these factors and labeled 30 decontextualized statements for sentiment, including meta-data on labeling rationale and uncertainty. Our results show: (1) Sentiment perception is only moderately stable within individuals, and label changes concentrate on ambiguity-prone statements; (2) Correlation-level signals are small and do not survive global multiple-testing correction; (3) In statement-level repeated-measures models (GEE), higher mood trait and reactivity are associated with more positive (and less neutral) labeling, while predictors of negative labeling are weaker and at most trend-level (e.g., task conflict); (4) We find no clear evidence of systematic project-phase effects. Overall, sentiment perception varies within persons and is strongly statement-dependent. Although our study was conducted in an academic setting, the observed variability and ambiguity effects suggest caution when interpreting sentiment analysis outputs and motivate future work with contextualized, in-project communication.

Marc Herrmann, Jil Klünder

Sentiment analysis gets increasing attention in software engineering with new tools emerging from new insights provided by researchers. Existing use cases and tools are meant to be used for textual communication such as comments on collaborative version control systems. While this can already provide useful feedback for development teams, a lot of communication takes place in meetings and is not suited for present tool designs and concepts. In this paper, we present a concept that is capable of processing live meeting audio and classifying transcribed statements into sentiment polarity classes. We combine the latest advances in open source speech recognition with previous research in sentiment analysis. We tested our approach on a student software project meeting to gain proof of concept, showing moderate agreement between the classifications of our tool and a human observer on the meeting audio. Despite the preliminary character of our study, we see promising results motivating future research in sentiment analysis on meetings. For example, the polarity classification can be extended to detect destructive behaviour that can endanger project success.

Martin Obaidi, Jil Klünder

Software development is a collaborative task and, hence, involves different persons. Research has shown the relevance of social aspects in the development team for a successful and satisfying project closure. Especially the mood of a team has been proven to be of particular importance. Thus, project managers or project leaders want to be aware of situations in which negative mood is present to allow for interventions. So-called sentiment analysis tools offer a way to determine the mood based on text-based communication. In this paper, we present the results of a systematic literature review of sentiment analysis tools developed for or applied in the context of software engineering. Our results summarize insights from 80 papers with respect to (1) the application domain, (2) the purpose, (3) the used data sets, (4) the approaches for developing sentiment analysis tools and (5) the difficulties researchers face when applying sentiment analysis in the context of software projects. According to our results, sentiment analysis is frequently applied to open-source software projects, and most tools are based on support-vector machines. Despite the frequent use of sentiment analysis in software engineering, there are open issues, e.g., regarding the identification of irony or sarcasm, pointing to future research directions.

Marco Kuhrmann, Paolo Tell, Regina Hebig et al.

Together with many success stories, promises such as the increase in production speed and the improvement in stakeholders' collaboration have contributed to making agile a transformation in the software industry in which many companies want to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a purely traditional or agile manner (under 15%). That said, most project disciplines and most practices show a clear trend towards increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and present a roadmap for future research.

Oliver Karras, Eklekta Kristo, Jil Klünder

Vision videos are established for soliciting feedback and stimulating discussions in requirements engineering (RE) practices, such as focus groups. Different researchers motivated the transfer of these benefits into crowd-based RE (CrowdRE) by using vision videos on social media platforms. So far, however, little research explored the potential of using vision videos for CrowdRE in detail. In this paper, we analyze and assess this potential, in particular, focusing on video comments as a source of feedback. In a case study, we analyzed 4505 comments on a vision video from YouTube. We found that the video solicited 2770 comments from 2660 viewers in four days. This is more than 50% of all comments the video received in four years. Even though only a certain fraction of these comments are relevant to RE, the relevant comments address typical intentions and topics of user feedback, such as feature request or problem report. Besides the typical user feedback categories, we found more than 300 comments that address the topic safety, which has not appeared in previous analyses of user feedback. In an automated analysis, we compared the performance of three machine learning algorithms on classifying the video comments. Despite certain differences, the algorithms classified the video comments well. Based on these findings, we conclude that the use of vision videos for CrowdRE has a large potential. Despite the preliminary nature of the case study, we are optimistic that vision videos can motivate stakeholders to actively participate in a crowd and solicit numerous of video comments as a valuable source of feedback.

Oliver Karras, Alexandra Risch, Jil Klünder

A wide variety of use case templates supports different variants to link a use case with its associated requirements. Regardless of the linking, a reader must process the related information simultaneously to understand them. Linking variants are intended to cause a specific reading behavior in which a reader interrelates a use case and its associated requirements. Due to the effort to create and maintain links, we investigated the impact of different linking variants on the reading behavior in terms of visual effort and the intended way of interrelating both artifacts. We designed an eye tracking study about reading a use case and requirements. We conducted the study twice each with 15 subjects as a baseline experiment and as a repetition. The results of the baseline experiment, its repetition, and their joint analysis are consistent. All investigated linking variants cause comparable visual effort. In all cases, reading the single artifacts one after the other is the most frequently occurring behavior. Only links embedded in the fields of a use case description significantly increase the readers' efforts to interrelate both artifacts. None of the investigated linking variants impedes reading a use case and requirements. However, only the most detailed linking variant causes readers to process related information simultaneously.

Paolo Tell, Jil Klünder, Steffen Küpper et al.

Hardly any software development process is used as prescribed by authors or standards. Regardless of company size or industry sector, a majority of project teams and companies use hybrid development methods (short: hybrid methods) that combine different development methods and practices. Even though such hybrid methods are highly individualized, a common understanding of how to systematically construct synergetic practices is missing. In this article, we make a first step towards a statistical construction procedure for hybrid methods. Grounded in 1467 data points from a large-scale practitioner survey, we study the question: What are hybrid methods made of and how can they be systematically constructed? Our findings show that only eight methods and few practices build the core of modern software development. Using an 85% agreement level in the participants' selections, we provide examples illustrating how hybrid methods can be characterized by the practices they are made of. Furthermore, using this characterization, we develop an initial construction procedure, which allows for defining a method frame and enriching it incrementally to devise a hybrid method using ranked sets of practice.

Jil Klünder, Melanie Busch, Natalie Dehn et al.

As software projects are very diverse, each software development process must be adjusted to the needs of the project and the corresponding development team. Frequently, we find different methods and practices combined in a so-called hybrid development method. Research has shown that these hybrid methods evolve over time and are devised based on experience. However, when devising a hybrid method, the methods and practices used should cover the whole software project with its different phases including, among others, project management, requirements analysis, quality management, risk management, and implementation. In this paper, we analyze which methods and practices are used in which phase of a software project. Based on an initial survey with 27 practitioners, we provide a mapping of methods and practices to different project phases and vice versa. Despite the preliminary nature of our study and the small sample size, we observe three remarkable aspects: (1) there are discrepancies between the intended use of methods and practices according to literature and the real use in practice, (2) practices are used more consistently than methods, and (3) parts of the software lifecycle such as maintenance and evolution are hardly covered by widely distributed methods and practices. Consequently, when devising a development process, it is worth a thought whether all phases of the software lifecycle are addressed or not.

Jil Klünder, Regina Hebig, Paolo Tell et al.

Software development methods are usually not applied by the book. Companies are under pressure to continuously deploy software products that meet market needs and stakeholders' requests. To implement efficient and effective development processes, companies utilize multiple frameworks, methods and practices, and combine these into hybrid methods. A common combination contains a rich management framework to organize and steer projects complemented with a number of smaller practices providing the development teams with tools to complete their tasks. In this paper, based on 732 data points collected through an international survey, we study the software development process use in practice. Our results show that 76.8% of the companies implement hybrid methods. Company size as well as the strategy in devising and evolving hybrid methods affect the suitability of the chosen process to reach company or project goals. Our findings show that companies that combine planned improvement programs with process evolution can increase their process' suitability by up to 5%.

Marco Kuhrmann, Joyce Nakatumba-Nabende, Rolf-Helge Pfeiffer et al.

Software engineering educators are continually challenged by rapidly evolving concepts, technologies, and industry demands. Due to the omnipresence of software in a digitalized society, higher education institutions (HEIs) have to educate the students such that they learn how to learn, and that they are equipped with a profound basic knowledge and with latest knowledge about modern software and system development. Since industry demands change constantly, HEIs are challenged in meeting such current and future demands in a timely manner. This paper analyzes the current state of practice in software engineering education. Specifically, we want to compare contemporary education with industrial practice to understand if frameworks, methods and practices for software and system development taught at HEIs reflect industrial practice. For this, we conducted an online survey and collected information about 67 software engineering courses. Our findings show that development approaches taught at HEIs quite closely reflect industrial practice. We also found that the choice of what process to teach is sometimes driven by the wish to make a course successful. Especially when this happens for project courses, it could be beneficial to put more emphasis on building learning sequences with other courses.

Paolo Tell, Jil Klünder, Steffen Küpper et al.

Among the multitude of software development processes available, hardly any is used by the book. Regardless of company size or industry sector, a majority of project teams and companies use customized processes that combine different development methods -- so-called hybrid development methods. Even though such hybrid development methods are highly individualized, a common understanding of how to systematically construct synergetic practices is missing. In this paper, we make a first step towards devising such guidelines. Grounded in 1,467 data points from a large-scale online survey among practitioners, we study the current state of practice in process use to answer the question: What are hybrid development methods made of? Our findings reveal that only eight methods and few practices build the core of modern software development. This small set allows for statistically constructing hybrid development methods. Using an 85% agreement level in the participants' selections, we provide two examples illustrating how hybrid development methods are characterized by the practices they are made of. Our evidence-based analysis approach lays the foundation for devising hybrid development methods.

Jil Klünder, Dzejlana Karajic, Paolo Tell et al.

Selecting a suitable development method for a specific project context is one of the most challenging activities in process design. Every project is unique and, thus, many context factors have to be considered. Recent research took some initial steps towards statistically constructing hybrid development methods, yet, paid little attention to the peculiarities of context factors influencing method and practice selection. In this paper, we utilize exploratory factor analysis and logistic regression analysis to learn such context factors and to identify methods that are correlated with these factors. Our analysis is based on 829 data points from the HELENA dataset. We provide five base clusters of methods consisting of up to 10 methods that lay the foundation for devising hybrid development methods. The analysis of the five clusters using trained models reveals only a few context factors, e.g., project/product size and target application domain, that seem to significantly influence the selection of methods. An extended descriptive analysis of these practices in the context of the identified method clusters also suggests a consolidation of the relevant practice sets used in specific project contexts.

Jil Klünder, Julian Horstmann, Oliver Karras

Software development encompasses many collaborative tasks in which usually several persons are involved. Close collaboration and the synchronization of different members of the development team require effective communication. One established communication channel are meetings which are, however, often not as effective as expected. Several approaches already focused on the analysis of meetings to determine the reasons for inefficiency and dissatisfying meeting outcomes. In addition to meetings, text-based communication channels such as chats and e-mails are frequently used in development teams. Communication via these channels requires a similar appropriate behavior as in meetings to achieve a satisfying and expedient collaboration. However, these channels have not yet been extensively examined in research. In this paper, we present an approach for analyzing interpersonal behavior in text-based communication concerning the conversational tone, the familiarity of sender and receiver, the sender's emotionality, and the appropriateness of the used language. We evaluate our approach in an industrial case study based on 1947 messages sent in a group chat in Zulip over 5.5 months. Using our approach, it was possible to automatically classify written sentences as positive, neutral, or negative with an average accuracy of 62.97% compared to human ratings. Despite this coarse-grained classification, it is possible to gain an overall picture of the adequacy of the textual communication and tendencies in the group mood.

Oliver Karras, Jil Klünder, Kurt Schneider

The adequate use of documentation for communication is one challenge in requirements engineering (RE). In recent years, several researchers addressed this challenge by using videos as a communication mechanism. All of them concluded that this way of using videos has the potential to facilitate requirements communication. Nevertheless, software professionals are not directors and thus do not necessarily know what constitutes a good video. This lack of knowledge is one crucial reason why videos are still not an established communication mechanism in RE. When videos shall be established in the RE activities, practices, and techniques, requirements engineers have to acquire the necessary knowledge to produce and use good videos on their own at moderate costs, yet sufficient quality. In our research project ViViReq (see Acknowledgment), we aspire to bridge this knowledge gap about what constitutes a good video. Whether a video is good or not depends on its quality perceived by its viewers. However, video quality is a rather ill-defined concept due to numerous unspecified technical and subjective characteristics. As part of our research plan, we develop a quality model for videos inspired by the idea of Femmer and Vogelsang to define and evaluate the quality of videos as RE artifacts. In addition to evaluating videos, this quality model can be used to identify the relevant characteristics of videos for their specific purpose which can be further used to specify requirements, their criteria for satisfaction, and corresponding measures. Therefore, software professionals may use the quality model as guidance for producing and using videos.

Oliver Karras, Jil Klünder, Kurt Schneider

The task board is an essential artifact in many agile development approaches. It provides a good overview of the project status. Teams often customize their task boards according to the team members' needs. They modify the structure of boards, define colored codings for different purposes, and introduce different card sizes. Although the customizations are intended to improve the task board's usability and effectiveness, they may also complicate its comprehension and use. The increased effort impedes the work of both the team and team externals. Hence, task board customization is in conflict with the agile practice of fast and easy overview for everyone. In an eye tracking study with 30 participants, we compared an original task board design with three customized ones to investigate which design shortened the required time to identify a particular story card. Our findings yield that only the customized task board design with modified structures reduces the required time. The original task board design is more beneficial than individual colored codings and changed card sizes. According to our findings, agile teams should rethink their current task board design. They may be better served by focusing on the original task board design and by applying only carefully selected adjustments. In case of customization, a task board's structure should be adjusted since this is the only beneficial kind of customization, that additionally complies more precisely with the concept of fast and easy project overview.