Enterprise software development is a complex effort that may last years. Enterprise software is often developed by a systems integrator that makes modifications to a pre-made package or builds tailored software for the specific purpose. The development may include many developer organizations, the user organization, and their different departments and sub-units. Their collaboration evolves through project incidents, phases and even crises. The practices of project management, communication, contracts, and ultimately personal relationships change intentionally or unintentionally. These changes may cause uncertainties and discontinuities for the development. This study observes changes during enterprise software development and their influence on collaboration practices in different situations. During twenty years of development both internal and external crises and changes in the business environment triggered changes in collaboration. The collaboration practices are classified with four modes of collaboration (contract, cooperation, personified, and process) that illustrate emphasis in collaboration in different circumstances.
{"title":"Collaboration Change in Enterprise Software Development","authors":"K. Smolander, M. Rossi, Samuli Pekkola","doi":"10.1145/2897586.2897590","DOIUrl":"https://doi.org/10.1145/2897586.2897590","url":null,"abstract":"Enterprise software development is a complex effort that may last years. Enterprise software is often developed by a systems integrator that makes modifications to a pre-made package or builds tailored software for the specific purpose. The development may include many developer organizations, the user organization, and their different departments and sub-units. Their collaboration evolves through project incidents, phases and even crises. The practices of project management, communication, contracts, and ultimately personal relationships change intentionally or unintentionally. These changes may cause uncertainties and discontinuities for the development. This study observes changes during enterprise software development and their influence on collaboration practices in different situations. During twenty years of development both internal and external crises and changes in the business environment triggered changes in collaboration. The collaboration practices are classified with four modes of collaboration (contract, cooperation, personified, and process) that illustrate emphasis in collaboration in different circumstances.","PeriodicalId":318848,"journal":{"name":"2016 IEEE/ACM Cooperative and Human Aspects of Software Engineering (CHASE)","volume":"37 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-05-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123808995","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}
Norihito Kitagawa, Hideaki Hata, Akinori Ihara, K. Kogiso, Ken-ichi Matsumoto
Code review is a common practice for improving the quality of source code changes and expediting knowledge transfer in a development community. In modern code review, source code changes or patches are considered to be assessed and approved for integration by multiple reviews. However, from our empirical study, we found that some patches are reviewed by only one reviewer, and some reviewers did not continue the review discussion, which can have negative effects on software quality. To understand these reviewers' behaviors, we model the code review situation based on the snowdrift game, which is used to analyze social dilemmas. With this game-theoretical modeling, we found that it can explain reviewers' behaviors well.
{"title":"Code Review Participation: Game Theoretical Modeling of Reviewers in Gerrit Datasets","authors":"Norihito Kitagawa, Hideaki Hata, Akinori Ihara, K. Kogiso, Ken-ichi Matsumoto","doi":"10.1145/2897586.2897605","DOIUrl":"https://doi.org/10.1145/2897586.2897605","url":null,"abstract":"Code review is a common practice for improving the quality of source code changes and expediting knowledge transfer in a development community. In modern code review, source code changes or patches are considered to be assessed and approved for integration by multiple reviews. However, from our empirical study, we found that some patches are reviewed by only one reviewer, and some reviewers did not continue the review discussion, which can have negative effects on software quality. To understand these reviewers' behaviors, we model the code review situation based on the snowdrift game, which is used to analyze social dilemmas. With this game-theoretical modeling, we found that it can explain reviewers' behaviors well.","PeriodicalId":318848,"journal":{"name":"2016 IEEE/ACM Cooperative and Human Aspects of Software Engineering (CHASE)","volume":"11 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-05-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124217182","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}
Jan-Peter Krämer, Michael Hennings, Joel Brandt, Jan O. Borchers
Animations are an essential part of many modern user interfaces. They are often defined programmatically, which allows for parametrization and reuse. Two programming paradigms to define animations are common: Procedural animation programming allows the developer to make explicit updates to object properties at each frame, allowing maximum control over behavior. Declarative animation programming allows the developer to specify keyframes, i.e., the value of an object’s property at a given point in time. All frames between two keyframes are automatically interpolated by the animation library. In this paper, we investigate how these common programming paradigms differ in terms of developers’ productivity. In a controlled laboratory study, we asked developers to implement a set of simple animations using both paradigms. We found that developers can implement a given behavior faster using declarative animation programming, but the abstraction introduced by automatically creating the animation through keyframe interpolation left participants with unexpected behavior for some tasks.
{"title":"An Empirical Study of Programming Paradigms for Animation","authors":"Jan-Peter Krämer, Michael Hennings, Joel Brandt, Jan O. Borchers","doi":"10.1145/2897586.2897597","DOIUrl":"https://doi.org/10.1145/2897586.2897597","url":null,"abstract":"Animations are an essential part of many modern user interfaces. They are often defined programmatically, which allows for parametrization and reuse. Two programming paradigms to define animations are common: Procedural animation programming allows the developer to make explicit updates to object properties at each frame, allowing maximum control over behavior. Declarative animation programming allows the developer to specify keyframes, i.e., the value of an object’s property at a given point in time. All frames between two keyframes are automatically interpolated by the animation library. In this paper, we investigate how these common programming paradigms differ in terms of developers’ productivity. In a controlled laboratory study, we asked developers to implement a set of simple animations using both paradigms. We found that developers can implement a given behavior faster using declarative animation programming, but the abstraction introduced by automatically creating the animation through keyframe interpolation left participants with unexpected behavior for some tasks.","PeriodicalId":318848,"journal":{"name":"2016 IEEE/ACM Cooperative and Human Aspects of Software Engineering (CHASE)","volume":"7 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-05-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125346569","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}
Post-completion errors have been observed in a variety of tasks by psychologists, but there is a lack of empirical studies in software engineering. This paper investigates whether post-completion errors occur in software development and the likelihood that software developers commit this error when a post-completion scenario is presented. An experimental study was conducted in the context of a programming contest. In the experiment, a programming task specification that contained a post-completion sub-task requirement was presented to the subjects. The results showed that 41.82% of the subjects committed the post-completion error in the same way¬—forgetting to design and implement a software requirement which is supposed to be the last sub-task and is not necessary for the completion of the main sub-task. This percentage of subjects committing the post-completion error was significantly higher than that of subjects committing other errors. This study has confirmed that post-completion error occurs in software development and, moreover, different software developers tend to commit this error in the same way with a high likelihood at the location where a post-completion scenario is presented. Strategies are proposed to prevent post-completion errors in software development.
{"title":"Post-Completion Error in Software Development","authors":"Fuqun Huang","doi":"10.1145/2897586.2897608","DOIUrl":"https://doi.org/10.1145/2897586.2897608","url":null,"abstract":"Post-completion errors have been observed in a variety of tasks by psychologists, but there is a lack of empirical studies in software engineering. This paper investigates whether post-completion errors occur in software development and the likelihood that software developers commit this error when a post-completion scenario is presented. An experimental study was conducted in the context of a programming contest. In the experiment, a programming task specification that contained a post-completion sub-task requirement was presented to the subjects. The results showed that 41.82% of the subjects committed the post-completion error in the same way¬—forgetting to design and implement a software requirement which is supposed to be the last sub-task and is not necessary for the completion of the main sub-task. This percentage of subjects committing the post-completion error was significantly higher than that of subjects committing other errors. This study has confirmed that post-completion error occurs in software development and, moreover, different software developers tend to commit this error in the same way with a high likelihood at the location where a post-completion scenario is presented. Strategies are proposed to prevent post-completion errors in software development.","PeriodicalId":318848,"journal":{"name":"2016 IEEE/ACM Cooperative and Human Aspects of Software Engineering (CHASE)","volume":"18 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-05-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128310365","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}
C. Uchida, Kiyoshi Honda, H. Washizaki, Y. Fukazawa, Kentarou Ogawa, Tomoaki Yagi, Mikako Ishigaki, Masashi Nakagawa
When developers operate a service, both the business objectives and users’ requirements must be satisfied. However, the interest between a business strategy and an action for the users is often unclear. Moreover, users’ requirements that are inferred from user data analysis may not correspond with users’ real requirements. In this paper, we propose the GO-MUC method (Goal-oriented Measurement for Usability and Conflict) and apply it to Yahoo!Crowdsourcing. The GO-MUC method can develop a strategy considering requirements of both the user and the business. Our results validate this method; this method can find an interest between the business side and users side and plan more effective and user-friendly strategies to resolve a conflicting interest.
当开发人员操作服务时，业务目标和用户需求都必须得到满足。然而，业务策略和用户行为之间的利益往往是不明确的。此外，从用户数据分析中推断出的用户需求可能与用户的实际需求不一致。本文提出了GO-MUC方法(Goal-oriented Measurement for Usability and Conflict)，并将其应用于雅虎众包。GO-MUC方法可以制定同时考虑用户和业务需求的策略。我们的结果验证了这种方法;该方法可以找到业务方和用户方之间的利益，并计划更有效和用户友好的策略来解决利益冲突。
{"title":"GO-MUC: A Strategy Design Method Considering Requirements of User and Business by Goal-Oriented Measurement","authors":"C. Uchida, Kiyoshi Honda, H. Washizaki, Y. Fukazawa, Kentarou Ogawa, Tomoaki Yagi, Mikako Ishigaki, Masashi Nakagawa","doi":"10.1145/2897586.2897618","DOIUrl":"https://doi.org/10.1145/2897586.2897618","url":null,"abstract":"When developers operate a service, both the business objectives and users’ requirements must be satisfied. However, the interest between a business strategy and an action for the users is often unclear. Moreover, users’ requirements that are inferred from user data analysis may not correspond with users’ real requirements. In this paper, we propose the GO-MUC method (Goal-oriented Measurement for Usability and Conflict) and apply it to Yahoo!Crowdsourcing. The GO-MUC method can develop a strategy considering requirements of both the user and the business. Our results validate this method; this method can find an interest between the business side and users side and plan more effective and user-friendly strategies to resolve a conflicting interest.","PeriodicalId":318848,"journal":{"name":"2016 IEEE/ACM Cooperative and Human Aspects of Software Engineering (CHASE)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-05-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"117319866","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}
Without understanding the programming difficulties faced by developers with visual impairments, the research community cannot begin to work on effective solutions to overcome these potential problems. This paper will describe our initial empirically based study to identify the problems blind software developers face. We analyzed 69 survey responses with blind developers in an effort to identify the aspects that are indeed a challenge to software development. The results indicate a number of difficulties, workarounds, and basis requirements that will serve as domain and stakeholder understand.
{"title":"Eliciting Programming Challenges Faced by Developers with Visual Impairments: Exploratory Study","authors":"Khaled Albusays, S. Ludi","doi":"10.1145/2897586.2897616","DOIUrl":"https://doi.org/10.1145/2897586.2897616","url":null,"abstract":"Without understanding the programming difficulties faced by developers with visual impairments, the research community cannot begin to work on effective solutions to overcome these potential problems. This paper will describe our initial empirically based study to identify the problems blind software developers face. We analyzed 69 survey responses with blind developers in an effort to identify the aspects that are indeed a challenge to software development. The results indicate a number of difficulties, workarounds, and basis requirements that will serve as domain and stakeholder understand.","PeriodicalId":318848,"journal":{"name":"2016 IEEE/ACM Cooperative and Human Aspects of Software Engineering (CHASE)","volume":"2008 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-05-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127723563","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}
Group or team formation has been a well-studied field in numerous contexts, such as business teams, project teams, and educational teams. There has, however, been little consideration of how groups or particularly project teams might have to be reorganized during a lecture in order to yield an optimal learning outcome. Empirical studies show that the outcome of groups will be affected by a number of factors, including the individual behavior of each group member, their skills and inclinations. In this research, the authors aim at finding correlations between the individual characteristics and learning outcomes during a running lecture so that teaching and learning can be improved. A study has been carried out that involved software engineering students over the past three years. The results show an improvement in the learning outcomes for groups that were systematically formed, which, for future settings, could enable educators as well as project leaders to systematically form groups and improve the outcomes of these groups in various domains.
{"title":"Improving Learning Outcomes through Systematic Group Reformation - The Role of Skills and Personality in Software Engineering Education","authors":"A. Mujkanovic, A. Bollin","doi":"10.1145/2897586.2897615","DOIUrl":"https://doi.org/10.1145/2897586.2897615","url":null,"abstract":"Group or team formation has been a well-studied field in numerous contexts, such as business teams, project teams, and educational teams. There has, however, been little consideration of how groups or particularly project teams might have to be reorganized during a lecture in order to yield an optimal learning outcome. Empirical studies show that the outcome of groups will be affected by a number of factors, including the individual behavior of each group member, their skills and inclinations. In this research, the authors aim at finding correlations between the individual characteristics and learning outcomes during a running lecture so that teaching and learning can be improved. A study has been carried out that involved software engineering students over the past three years. The results show an improvement in the learning outcomes for groups that were systematically formed, which, for future settings, could enable educators as well as project leaders to systematically form groups and improve the outcomes of these groups in various domains.","PeriodicalId":318848,"journal":{"name":"2016 IEEE/ACM Cooperative and Human Aspects of Software Engineering (CHASE)","volume":"5 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-05-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128101745","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}
Requirements gathering are an important aspect of application development, especially when users are people with special needs. Traditionally, this process is being conducted using conventional methods, such as interviews, workshops and questionnaires. These approaches, however, are unable to grasp the full context when collecting data from the communities of people with special needs, mainly because of the difficult access to participants and incomprehensiveness of the data gathered. To mitigate such issues, in this position paper, we argue that existing traditional methods could be complemented by means of Internet of Things. The immense amount of data gathered from various devices interconnected could help generate meaningful data that will complement the usually insufficient amount collected using traditional methods. This new approach is, however, associated with challenges that are discussed along with a possible scenario on how data complementing from traditional and the indirect method could be done.
{"title":"Augmenting Requirements Gathering for People with Special Needs Using IoT: A Position Paper","authors":"Mexhid Ferati, Arianit Kurti, Bahtijar Vogel, Bujar Raufi","doi":"10.1145/2897586.2897617","DOIUrl":"https://doi.org/10.1145/2897586.2897617","url":null,"abstract":"Requirements gathering are an important aspect of application development, especially when users are people with special needs. Traditionally, this process is being conducted using conventional methods, such as interviews, workshops and questionnaires. These approaches, however, are unable to grasp the full context when collecting data from the communities of people with special needs, mainly because of the difficult access to participants and incomprehensiveness of the data gathered. To mitigate such issues, in this position paper, we argue that existing traditional methods could be complemented by means of Internet of Things. The immense amount of data gathered from various devices interconnected could help generate meaningful data that will complement the usually insufficient amount collected using traditional methods. This new approach is, however, associated with challenges that are discussed along with a possible scenario on how data complementing from traditional and the indirect method could be done.","PeriodicalId":318848,"journal":{"name":"2016 IEEE/ACM Cooperative and Human Aspects of Software Engineering (CHASE)","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-05-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130541212","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}
There are many techniques to improve software quality. One is using automatic static analysis tools. We have observed, however, that despite the low-cost help they offer, these tools areunderused and often discourage beginners. There is evidence that personality traits influence the perceived usability of a software. Thus, to support beginners better, we need to understand how theworkflow of people with different prevalent personality traits using these tools varies. For this purpose, we observed users’ solution strategies and correlated them with their prevalent personality traits in an exploratory study with student participants within a controlled experiment. We gathered data by screen capturing and chat protocols as well as a Big Five personality traits test. We found strong correlations between particular personality traits and different strategies of removing the findings of static code analysis as well as between personality and tool utilization. Based on that, we offer take-away improvement suggestions. Our results imply that developers should be aware of these solution strategies and use this information to build tools that are more appealing to people with different prevalent personality traits.
{"title":"Does Personality Influence the Usage of Static Analysis Tools? An Explorative Experiment","authors":"Jan-Peter Ostberg, S. Wagner, Erica Weilemann","doi":"10.1145/2897586.2897599","DOIUrl":"https://doi.org/10.1145/2897586.2897599","url":null,"abstract":"There are many techniques to improve software quality. One is using automatic static analysis tools. We have observed, however, that despite the low-cost help they offer, these tools areunderused and often discourage beginners. There is evidence that personality traits influence the perceived usability of a software. Thus, to support beginners better, we need to understand how theworkflow of people with different prevalent personality traits using these tools varies. For this purpose, we observed users’ solution strategies and correlated them with their prevalent personality traits in an exploratory study with student participants within a controlled experiment. We gathered data by screen capturing and chat protocols as well as a Big Five personality traits test. We found strong correlations between particular personality traits and different strategies of removing the findings of static code analysis as well as between personality and tool utilization. Based on that, we offer take-away improvement suggestions. Our results imply that developers should be aware of these solution strategies and use this information to build tools that are more appealing to people with different prevalent personality traits.","PeriodicalId":318848,"journal":{"name":"2016 IEEE/ACM Cooperative and Human Aspects of Software Engineering (CHASE)","volume":"79 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-05-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127012770","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}
It is widely recognized that human factors are critical for successful Software Engineering. Recent research in this field provides insights on what are these factors are and how they affect Software Engineering productivity. How- ever knowing challenges is not enough; it is important to elaborate on how it will be possible to address them. This paper focuses on sociodrama as a technique which helps in improving organizational climate and may positively affect teams productivity.
{"title":"Sociodrama: One More Technique to Foster Collaboration in Software Engineering","authors":"Alexander S. Lesnevsky","doi":"10.1145/2897586.2897600","DOIUrl":"https://doi.org/10.1145/2897586.2897600","url":null,"abstract":"It is widely recognized that human factors are critical for successful Software Engineering. Recent research in this field provides insights on what are these factors are and how they affect Software Engineering productivity. How- ever knowing challenges is not enough; it is important to elaborate on how it will be possible to address them. This paper focuses on sociodrama as a technique which helps in improving organizational climate and may positively affect teams productivity.","PeriodicalId":318848,"journal":{"name":"2016 IEEE/ACM Cooperative and Human Aspects of Software Engineering (CHASE)","volume":"26 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2016-05-14","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114728228","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}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：