The COVID-19 pandemic triggered a natural experiment of an unprecedented scale as companies closed their offices and sent employees to work from home. Many managers were concerned that their engineers would not be able to work effectively from home, or lack the motivation to do so, and that they would lose control and not even notice when things go wrong. As many companies announced their post-COVID permanent remote-work or hybrid home/office policies, the question of what can be expected from software engineers who work from home becomes more and more relevant. To understand the nature of home telework we analyze the evidence of perceived changes in productivity comparing office work before the pandemic with the work from home during the pandemic from thirteen empirical surveys of practitioners. We analyzed data from six corporate surveys conducted in four Scandinavian companies combined with the results of seven published surveys studying the perceived changes in productivity in industrial settings. In addition, we sought explanations for the variation in perceived productivity among the engineers from the studied companies through the qualitative analysis of open-ended questions and interviews. Combined results of 7686 data points suggest that though on average perceived productivity has not changed significantly, there are developers who report being more productive, and developers being less productive when working from home. Positively affected individuals in some surveys form large groups of respondents (up to 50%) and mention benefiting from a better organization of work, increased flexibility and focus. Yet, there are equally large groups of negatively affected respondents (up to 51%) who complain about the challenges related to remote teamwork and collaboration, as well as emotional issues, distractions and poor home office environment and equipment. Finally, positive trends are found in longitudinal surveys, i.e., developers’ productivity in the later months of the pandemic show better results than those in the earlier months. We conclude that behind the average “no change” lays a large variation of experiences, which means that the work from home might not be for everyone. Yet, a longitudinal analysis of the surveys is encouraging, as it shows that the more pessimistic results might be influenced by the initial experiences of an unprecedented crisis. At the end, we put forward the lessons learned during the pandemic that can inspire the new post-pandemic work policies.

Quality requirements deal with how well a product should perform the intended functionality, such as start-up time and learnability. Researchers argue they are important and at the same time studies indicate there are deficiencies in practice. Our goal is to review the state of evidence for quality requirements. We want to understand the empirical research on quality requirements topics as well as evaluations of quality requirements solutions. We used a hybrid method for our systematic literature review. We defined a start set based on two literature reviews combined with a keyword-based search from selected publication venues. We snowballed based on the start set. We screened 530 papers and included 84 papers in our review. Case study method is the most common (43), followed by surveys (15) and tests (13). We found no replication studies. The two most commonly studied themes are (1) differentiating characteristics of quality requirements compared to other types of requirements, (2) the importance and prevalence of quality requirements. Quality models, QUPER, and the NFR method are evaluated in several studies, with positive indications. Goal modeling is the only modeling approach evaluated. However, all studies are small scale and long-term costs and impact are not studied. We conclude that more research is needed as empirical research on quality requirements is not increasing at the same rate as software engineering research in general. We see a gap between research and practice. The solutions proposed are usually evaluated in an academic context and surveys on quality requirements in industry indicate unsystematic handling of quality requirements.

Driver behaviour monitoring is a broad area of research, with a variety of methods and approaches. Distraction from the use of electronic devices, such as smartphones for texting or talking on the phone, is one of the leading causes of vehicle accidents. With the increasing number of sensors available in vehicles, there is an abundance of data available to monitor driver behaviour, but it has only been available to vehicle manufacturers and, to a limited extent, through proprietary solutions. Recently, research and practice have shifted the paradigm to the use of smartphones for driver monitoring and have fuelled efforts to support driving safety. This systematic review paper extends a preliminary, previously carried out author-centric literature review on smartphone-based driver monitoring approaches using snowballing search methods to illustrate the opportunities in using smartphones for driver distraction detection. Specifically, the paper reviews smartphone-based approaches to distracted driving behaviour detection, the smartphone sensors and detection methods applied, and the results obtained.

Component-based software engineering is a common approach in the development and evolution of contemporary software systems. Different component sourcing options are available, such as: (1) Software developed internally (in-house), (2) Software developed outsourced, (3) Commercial off-the-shelf software, and (4) Open-Source Software. However, there is little available research on what attributes of a component are the most important ones when selecting new components. The objective of this study is to investigate what matters the most to industry practitioners when they decide to select a component. We conducted a cross-domain anonymous survey with industry practitioners involved in component selection. First, the practitioners selected the most important attributes from a list. Next, they prioritized their selection using the Hundred-Dollar ($100) test. We analyzed the results using compositional data analysis. The results of this exploratory analysis showed that cost was clearly considered to be the most important attribute for component selection. Other important attributes for the practitioners were: support of the component, longevity prediction, and level of off-the-shelf fit to product. Moreover, several practitioners still consider in-house software development to be the sole option when adding or replacing a component. On the other hand, there is a trend to complement it with other component sourcing options and, apart from cost, different attributes factor into their decision. Furthermore, in our analysis, nonparametric tests and biplots were used to further investigate the practitioners’ inherent characteristics. It seems that smaller and larger organizations have different views on what attributes are the most important, and the most surprising finding is their contrasting views on the cost attribute: larger organizations with mature products are considerably more cost aware.