2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)最新文献

{"title":"REACT: An Approach for Capturing Rationale in Chat Messages","authors":"Rana Alkadhi, Jan Ole Johanssen, Emitzá Guzmán, B. Brügge","doi":"10.1109/ESEM.2017.26","DOIUrl":"https://doi.org/10.1109/ESEM.2017.26","url":null,"abstract":"Developers' chat messages are a rich source of rationale behind development decisions. Rationale comprises valuable knowledge during software evolution for understanding and maintaining the software system. However, developers resist explicit methods for rationale capturing in practice, due to their intrusiveness and cognitive overhead. Aim: Our primary goal is to help developers capture rationale in chat messages with low effort. Further, we seek to encourage the collaborative capturing of rationale in development teams. Method: In this paper, we present REACT, a lightweight approach for annotating chat messages that contain rationale. To evaluate the feasibility of REACT, we conducted two studies. In the first study, we evaluated the approach with eleven development teams during a short-term design task. In the second study, we evaluated the approach with one development team over a duration of two months. In addition, we distributed a questionnaire to both studies' participants. Results: Our results show that REACT is easily learned and used by developers. Furthermore, it encourages the collaborative capturing of rationale. Remarkably, the majority of participants do not perceive privacy as a barrier when capturing rationale from their informal communication. Conclusions: REACT is a first step towards enhancing rationale capturing in developers' chat messages.","PeriodicalId":213866,"journal":{"name":"2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)","volume":"97 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132144442","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Looking for Peace of Mind? Manage Your (Technical) Debt: An Exploratory Field Study","authors":"Hadi Ghanbari, Terese Besker, A. Martini, J. Bosch","doi":"10.1109/ESEM.2017.53","DOIUrl":"https://doi.org/10.1109/ESEM.2017.53","url":null,"abstract":"Background: In the last two decades Technical Debt (TD) has received a considerable amount of attention from software engineering research and practice. Recently, a small group of studies suggests that, in addition to its technical and economic consequences, TD can affect developers' psychological states and morale. However, until now there has been a lack of empirical research clarifying such influences. Aims: In this study, we aim at taking the first step in filling this gap by investigating the potential impacts of TD and its management on developers' morale. Method: Drawing from previous literature on morale, we decided to explore the influence of TD and its management on three dimensions of morale called affective, future/goal, and interpersonal antecedents. In so doing, we conducted an exploratory field study and collected data from software professionals active in different industrial domains through eight qualitative interviews and an online survey (n=33). Results: Our results indicate that TD mainly has a negative influence on future/goal and affective antecedents of morale. This is mainly because the occurrence of TD hinders developers from performing their tasks and achieving their goals. TD management, on the other hand, has a positive influence on all the three dimensions of morale since it is associated with positive feelings and interpersonal feedback as well as a sense of progress. Conclusions: According to the results of this empirical study, the occurrence of TD reduces developers' morale, while its management increases developers' morale.","PeriodicalId":213866,"journal":{"name":"2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)","volume":"19 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127097105","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Beyond Continuous Delivery: An Empirical Investigation of Continuous Deployment Challenges","authors":"Mojtaba Shahin, M. Babar, Mansooreh Zahedi, Liming Zhu","doi":"10.1109/ESEM.2017.18","DOIUrl":"https://doi.org/10.1109/ESEM.2017.18","url":null,"abstract":"Context: A growing number of software organizations have been adopting Continuous DElivery (CDE) and Continuous Deployment (CD) practices. Researchers have started investing significant efforts in studying different aspects of CDE and CD. Many studies refer to CDE (i.e., where an application is potentially capable of being deployed) and CD (i.e., where an application is automatically deployed to production on every update) as synonyms and do not distinguish them from each other. Despite CDE being successfully adopted by a large number of organizations, it is not empirically known why organizations still are unable or demotivated to have automatic and continuous deployment (i.e., CD practice). Goal: This study aims at empirically investigating and classifying the factors that may impact on adopting and implementing CD practice. Method: We conducted a mixed-method empirical study consisting of interviewing 21 software practitioners, followed by a survey with 98 respondents. Results: Our study reveals 11 confounding factors that limit or demotivate software organizations to push changes automatically and continuously to production. The most important ones are \"lack of automated (user) acceptance test\", \"manual quality check\", \"deployment as business decision\", \"insufficient level of automated test coverage\", and \"highly bureaucratic deployment process\". Conclusion: Our findings highlight several areas for future research and provide suggestions for practitioners to streamline deployment process.","PeriodicalId":213866,"journal":{"name":"2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127007053","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"On Software Productivity Analysis with Propensity Score Matching","authors":"Masateru Tsunoda, S. Amasaki","doi":"10.1109/ESEM.2017.59","DOIUrl":"https://doi.org/10.1109/ESEM.2017.59","url":null,"abstract":"[Context:] Software productivity analysis is an essential activity for software process improvement. It specifies critical factors to be resolved or accepted from project data. As the nature of project data is observational, not experimental, the project data involves bias that can cause spurious relationships among analyzed factors. Analysis methods based on linear regression suffer from the spurious relationships and sometimes lead an inappropriate causal relation. The propensity score is a solution for this problem but has rarely been used. [Objective:] To investigate what differences the use of propensity score brings to software productivity analysis in comparison to a conventional method. [Method:] We revisited classical software productivity analyses on ISBSG and Finnish datasets. The differences of critical factors between the propensity score and the linear regression were investigated. [Results:] Both analysis methods specified different critical factors on the two datasets. The specified factors were both reasonable to some extent, and further considerations are needed for the propensity score results. [Conclusions:] The use of propensity score can lead new possible factors to be tackled. Although the contradiction does not necessarily indicate a flaw of the linear regression, the results by the propensity score should also be noticed for better actions.","PeriodicalId":213866,"journal":{"name":"2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)","volume":"160 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121432128","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Managing Hidden Dependencies in OO Software: A Study Based on Open Source Projects","authors":"N. Ajienka, A. Capiluppi, S. Counsell","doi":"10.1109/ESEM.2017.21","DOIUrl":"https://doi.org/10.1109/ESEM.2017.21","url":null,"abstract":"Dependency-based software change impact analysis is the domain concerned with estimating the sets of artifacts impacted by a change to a related artifact. Research has shown that analysing the various class dependency types independently will never completely reveal the impact sets. Therefore, dependency types are combined to improve the precision of estimated when compared to impact sets. Software classes can be linked in different ways; for instance semantically, if their meaning is somewhat related or, structurally, if one class depends on the services of other classes. 'Hidden' dependencies arise when two classes, linked structurally, do not share the same semantic namespace or when semantically dependent classes do not share a structural link. With the goal of revealing hidden dependencies during change impact analysis, we empirically investigated the relationship between structural and semantic class dependencies in object-oriented software systems. Results show that (i) semantic and structural links are significantly associated, (ii) the strengths of those links do not play a significant role and, (iii) a significant number of dependencies are hidden. We propose two refactoring techniques to deal with hidden dependencies, based on existing design patterns. We plan to investigate them further to assert whether either has the potential for reducing refactoring and testing effort.","PeriodicalId":213866,"journal":{"name":"2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123591553","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Estimating Energy Impact of Software Releases and Deployment Strategies: The KPMG Case Study","authors":"R. Verdecchia, Giuseppe Procaccianti, I. Malavolta, P. Lago, Joost Koedijk","doi":"10.1109/ESEM.2017.39","DOIUrl":"https://doi.org/10.1109/ESEM.2017.39","url":null,"abstract":"Background. Often motivated by optimization objectives, software products are characterized by different subsequent releases and deployed through different strategies. The impact of these two aspects of software on energy consumption has still to be completely understood and can be improved by carrying out ad-hoc analyses for specific software products. Aims. In this research we report on an industrial collaboration aiming at assessing the different impact that releases and deployment strategies of a software product can have on the energy consumption of its underlying hardware infrastructure. Method. We designed and performed an empirical experiment in a controlled environment. Deployment strategies, releases and use case scenarios of an industrial third-party software product were adopted as experimental factors. The use case scenarios were used as a blocking factor and adopted to dynamically load-test the software product. Power consumption and execution time were selected as response variables to measure the energy consumption. Results. We observed that both deployment strategies and software releases significantly influence the energy consumption of the hardware infrastructure. A strong interaction between the two factors was identified. The impact of such interaction highly varied depending on which use case scenario was considered, making the identification of the most frequently adopted use case scenario critical for energy optimisation. The collaboration between industry and academia has been productive for both parties, even if some practitioners manifested low interest/awareness on software energy efficiency. Conclusions. For the software product considered there is no absolute preferable release or deployment strategy with respect to energy efficiency, as the interaction of these factors has to be considered. The number of machines involved in a software deployment strategy does not simply constitute an additive effect of the energy consumption of the underlying hardware infrastructure.","PeriodicalId":213866,"journal":{"name":"2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)","volume":"2 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116915761","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Change-Aware Build Prediction Model for Stall Avoidance in Continuous Integration","authors":"Foyzul Hassan, Xiaoyin Wang","doi":"10.1109/ESEM.2017.23","DOIUrl":"https://doi.org/10.1109/ESEM.2017.23","url":null,"abstract":"Continuous Integration(CI) is a widely used development practice where developers integrate their work after submitting code changes at central repository. CI servers usually monitor central repository for code change submission and automatically build software with changed code, perform unit testing, integration testing and provide test summary report. If build or test fails developers fix those issues and submit the code changes. Continuous submission of code modification by developers and build latency time creates stalls at CI server build pipeline and hence developers have to wait long time to get build outcome. In this paper, we proposed build prediction model that uses TravisTorrent data set with build error log clustering and AST level code change modification data to predict whether a build will be successful or not without attempting actual build so that developer can get early build outcome result. With the proposed model we can predict build outcome with an average F-Measure over 87% on all three build systems (Ant, Maven, Gradle) under the cross-project prediction scenario.","PeriodicalId":213866,"journal":{"name":"2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)","volume":"7 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124367195","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Towards an Approach to Prevent Social Loafing in Software Development Teams","authors":"Ilenia Fronza, Xiaofeng Wang","doi":"10.1109/ESEM.2017.37","DOIUrl":"https://doi.org/10.1109/ESEM.2017.37","url":null,"abstract":"[Background] A high-functioning team is a decisive factor for a successful software development project. However building such a team is not easy. Among many issues and obstacles encountered by teams, social loafing is a common but difficult one to tackle. [Aim] We intend to construct an approach to effectively prevent social loafing behaviors in software development teams. [Method] We built one social loafing prevention approach based on existing literature and survey instruments. It has been applied in an educational context with 2nd-year computer science students working on software development projects in teams. [Results] The approach starts with increasing team members' awareness of social loafing. Team Expectations Agreement (TEA) is then used to help the team to write down the terms that explicitly prevent social loafing. During the project, a small survey instrument is used to track regularly if the specified terms are followed by the team members. At the end of a period, the presence/absence of social loafing is assessed by the team using another short survey. How to interpret the results of the surveys is explained as part of the presented approach. [Conclusions] This approach has potential to improve team-work skills of students, which is not adequately addressed in higher education programs. Meanwhile it can be adapted in professional software development environments to prevent social loafing and improve teamwork. The next step of our study will be using the collected data to evaluate the proposed approach, and formulating a set of recommendations to use the approach in the professional software development context.","PeriodicalId":213866,"journal":{"name":"2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124442687","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"Notifying and Involving Users in Experimentation: Ethical Perceptions of Software Practitioners","authors":"S. Yaman, Fabian Fagerholm, Myriam Munezero, Hanna Mäenpää, T. Männistö","doi":"10.1109/ESEM.2017.31","DOIUrl":"https://doi.org/10.1109/ESEM.2017.31","url":null,"abstract":"Background: Experiment-driven development with the help of real usage data helps to build software products and services that are of high value to their users. As more software companies use experimentation in their development practises, ethical concerns are increasingly important. Objective: There is a need for understanding the ethical issues companies must take into account when practising experimentation as a development strategy. This paper examines how software development practitioners experience the need for notifying users when involving them in experimentation. Method: We conducted a survey within four software companies, inviting employees in different functional roles to indicate their attitudes and perceptions through a number of statements. Results: Employees working in different roles have different viewpoints on ethical issues. While managers are more conscious about company-customer relationships, UX designers appear more familiar with involving users. Developers think that details of experiments can be withheld from users if the results depend on it. Conclusion: Barriers to successfully conducting experiment-driven development are different for different roles. Clear and specific guidelines are needed for ethical aspects of experimentation.","PeriodicalId":213866,"journal":{"name":"2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)","volume":"49 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134363057","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}

{"title":"The Influence of Requirements in Software Model Development in an Industrial Environment","authors":"Jorge Echeverría, Francisca Pérez, José Ignacio Panach, Carlos Cetina, Ó. Pastor","doi":"10.1109/ESEM.2017.41","DOIUrl":"https://doi.org/10.1109/ESEM.2017.41","url":null,"abstract":"Textual description of requirements is a specification technique that is widely used in industry, where time is key for success. How requirements are specified textually greatly depends on human factors. In order to study how requirements processing is affected by the level of detail in textual descriptions, this paper compares enriched textual requirements specifications with non-enriched ones. To do this, we have conducted an experiment in industry with 19 engineers of CAF (Construcciones y Auxiliares de Ferrocarril), which is a supplier of railway solutions. The experiment is a crossover design that analyzes efficiency, effectiveness, and perceived difficulty starting from a written specification of requirements that subjects must process in order to build software models. The results show that effectiveness and efficiency for enriched requirements are better, while non-enriched requirements are slightly more difficult to deal with. Therefore, even though enriched requirements require more time to be specified, the results are more successfully when using them.","PeriodicalId":213866,"journal":{"name":"2017 ACM/IEEE International Symposium on Empirical Software Engineering and Measurement (ESEM)","volume":"3 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2017-11-09","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"115234084","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}