As programmers work on source code, they ask an array of questions that are difficult to answer manually. To help answer these questions, programmers often employ software tools; often in attempting to use these tools, the programmers encounter many obstacles which frustrate their efforts and lead to less than optimal tool utilization. Possibly worse, programmers often intentionally under utilize available tools as they prefer to answer questions only with tools they have used before. We hypothesize that we can coach programmers towards a more systematic use of appropriate software tools that would enable the programmers to be more productive in the completion of their work. We propose to use activity logs collected automatically to deduce the questions a given programmer asks a frequently and then to coach the programmer automatically on appropriate, possibly unfamiliar, tools to answer those questions more effectively. By using activity logs to inform coaching decisions, our approach is based on an objective cost metric. We envision an environment that enables a programmer to learn how to use appropriate tools systematically.
{"title":"A sketch of the programmer's coach: making programmers more effective","authors":"D. Shepherd, G. Murphy","doi":"10.1145/1370114.1370139","DOIUrl":"https://doi.org/10.1145/1370114.1370139","url":null,"abstract":"As programmers work on source code, they ask an array of questions that are difficult to answer manually. To help answer these questions, programmers often employ software tools; often in attempting to use these tools, the programmers encounter many obstacles which frustrate their efforts and lead to less than optimal tool utilization. Possibly worse, programmers often intentionally under utilize available tools as they prefer to answer questions only with tools they have used before. We hypothesize that we can coach programmers towards a more systematic use of appropriate software tools that would enable the programmers to be more productive in the completion of their work. We propose to use activity logs collected automatically to deduce the questions a given programmer asks a frequently and then to coach the programmer automatically on appropriate, possibly unfamiliar, tools to answer those questions more effectively. By using activity logs to inform coaching decisions, our approach is based on an objective cost metric. We envision an environment that enables a programmer to learn how to use appropriate tools systematically.","PeriodicalId":107901,"journal":{"name":"Proceedings of the 2008 international workshop on Cooperative and human aspects of software engineering","volume":"27 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-05-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"125644330","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}
Li-Te Cheng, Jonathan Sillito, M. Storey, B. Tessem, Gina Venolia, C. D. Souza, Y. Dittrich, Michael John, O. Hazzan, F. Maurer, H. Sharp, J. Singer, S. Sim
Welcome to CHASE 2008. We are delighted to present a selection of excellent papers all focusing on the cooperative and human side of software engineering. We received 34 submissions to the workshop, and accepted 28 for presentation. Reflecting the diversity of software engineering research, the 28 accepted papers ranged in topic from data to theory, requirements to testing, ethnography to experiments, and individuals to organizations. The diversity of the papers is interesting in that it shows how broadly the notion of the cooperative and human aspects of software engineering can be applied. As we experience this renaissance in the study of the human and cooperative aspects, we hope that more such research will be produced and integrated successfully into the software engineering discipline. An understanding and accounting for of both the technical and human aspects will be necessary to enhance and progress software engineering research. We look forward to beginning to meet this challenge at CHASE 2008.
{"title":"Proceedings of the 2008 international workshop on Cooperative and human aspects of software engineering","authors":"Li-Te Cheng, Jonathan Sillito, M. Storey, B. Tessem, Gina Venolia, C. D. Souza, Y. Dittrich, Michael John, O. Hazzan, F. Maurer, H. Sharp, J. Singer, S. Sim","doi":"10.1145/1370114","DOIUrl":"https://doi.org/10.1145/1370114","url":null,"abstract":"Welcome to CHASE 2008. We are delighted to present a selection of excellent papers all focusing on the cooperative and human side of software engineering. We received 34 submissions to the workshop, and accepted 28 for presentation. Reflecting the diversity of software engineering research, the 28 accepted papers ranged in topic from data to theory, requirements to testing, ethnography to experiments, and individuals to organizations. The diversity of the papers is interesting in that it shows how broadly the notion of the cooperative and human aspects of software engineering can be applied. As we experience this renaissance in the study of the human and cooperative aspects, we hope that more such research will be produced and integrated successfully into the software engineering discipline. An understanding and accounting for of both the technical and human aspects will be necessary to enhance and progress software engineering research. We look forward to beginning to meet this challenge at CHASE 2008.","PeriodicalId":107901,"journal":{"name":"Proceedings of the 2008 international workshop on Cooperative and human aspects of software engineering","volume":"67 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-05-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127135228","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}
In this study, we explore whether the degree of centrality, betweenness and density of the open source software or OSS team communications network have any bearing on the quality of the software developed. We measure the quality of OSS in terms of number of defect fixed per software promotion, the number of defects reported at different severity levels and the average number of days for a defect to be fixed for each project team. The data required to conduct the analysis needs to be of OSS projects, their team structure and also contribution of the projects user community and immediate development team. We extract the communications pattern of OSS projects development teams from online forums or message boards as the developers are usually located in different geographic areas. We use SorceForge.net for collecting relevant coordination related data for this study; which is the central resource for hosting more than 100,000 open source development projects and with over 1 million registered users that participate in the development of high profile OSS projects. The outcome of this study suggests that there is a correlation between social network characteristics and strong and poor performing projects in an OSS environment.
{"title":"Measuring OSS quality trough centrality","authors":"L. Hossain, David Zhou","doi":"10.1145/1370114.1370131","DOIUrl":"https://doi.org/10.1145/1370114.1370131","url":null,"abstract":"In this study, we explore whether the degree of centrality, betweenness and density of the open source software or OSS team communications network have any bearing on the quality of the software developed. We measure the quality of OSS in terms of number of defect fixed per software promotion, the number of defects reported at different severity levels and the average number of days for a defect to be fixed for each project team. The data required to conduct the analysis needs to be of OSS projects, their team structure and also contribution of the projects user community and immediate development team. We extract the communications pattern of OSS projects development teams from online forums or message boards as the developers are usually located in different geographic areas. We use SorceForge.net for collecting relevant coordination related data for this study; which is the central resource for hosting more than 100,000 open source development projects and with over 1 million registered users that participate in the development of high profile OSS projects. The outcome of this study suggests that there is a correlation between social network characteristics and strong and poor performing projects in an OSS environment.","PeriodicalId":107901,"journal":{"name":"Proceedings of the 2008 international workshop on Cooperative and human aspects of software engineering","volume":"27 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-05-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114876026","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}
Determining responsibility for a piece of source code is difficult when software is being developed collaboratively with weak code ownership. Nonetheless, a major factor for preventing "cowboy coding" and careless development of code is liability. We propose a tool for statistically acquiring per developer per document accountabilities and enable learning and self-monitoring processes within a development team while maintaining anonymity to a certain degree to not endanger team spirit. In this paper we want to examine possible social effects on the development team that employment of our tool has.
{"title":"Social aspects of a continuous inspection platform for software source code","authors":"Christian R. Prause, M. Eisenhauer","doi":"10.1145/1370114.1370136","DOIUrl":"https://doi.org/10.1145/1370114.1370136","url":null,"abstract":"Determining responsibility for a piece of source code is difficult when software is being developed collaboratively with weak code ownership. Nonetheless, a major factor for preventing \"cowboy coding\" and careless development of code is liability. We propose a tool for statistically acquiring per developer per document accountabilities and enable learning and self-monitoring processes within a development team while maintaining anonymity to a certain degree to not endanger team spirit. In this paper we want to examine possible social effects on the development team that employment of our tool has.","PeriodicalId":107901,"journal":{"name":"Proceedings of the 2008 international workshop on Cooperative and human aspects of software engineering","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-05-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123955012","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}
Maintaining a developer's awareness of changes in the software on which she depends is challenging. Awareness is often impeded at two ends of the spectrum: a lack of information, when the changes only become apparent when a build breaks or bugs appear; or an excess of information, where the changes are announced but the majority of the changes are not relevant to the developer in her particular project and context. In the middle ground lies the possibility of support for developer-specific awareness (DSA), wherein information about the changes is filtered on the basis of the developer's own code and interests. This paper discusses how the DSA problem is manifested in software development and briefly examines the design space involved in providing DSA notifications. A particular point in the space is proposed for a target implementation, called the YooHoo awareness system, that will help developers in loose organizations to keep apprised of any code changes that are specifically relevant to the source code for which they are responsible.
{"title":"Promoting developer-specific awareness","authors":"Reid Holmes, R. Walker","doi":"10.1145/1370114.1370130","DOIUrl":"https://doi.org/10.1145/1370114.1370130","url":null,"abstract":"Maintaining a developer's awareness of changes in the software on which she depends is challenging. Awareness is often impeded at two ends of the spectrum: a lack of information, when the changes only become apparent when a build breaks or bugs appear; or an excess of information, where the changes are announced but the majority of the changes are not relevant to the developer in her particular project and context. In the middle ground lies the possibility of support for developer-specific awareness (DSA), wherein information about the changes is filtered on the basis of the developer's own code and interests. This paper discusses how the DSA problem is manifested in software development and briefly examines the design space involved in providing DSA notifications. A particular point in the space is proposed for a target implementation, called the YooHoo awareness system, that will help developers in loose organizations to keep apprised of any code changes that are specifically relevant to the source code for which they are responsible.","PeriodicalId":107901,"journal":{"name":"Proceedings of the 2008 international workshop on Cooperative and human aspects of software engineering","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-05-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129769406","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}
Making a change to a large software system requires investing time in understanding the system first. In the context of programming, navigation refers to the process of finding one's way through a complex network of programming constructs and other software artifacts. The process consists of answering questions such as "What am I looking at?" and "What do I want to look at next?", along with the question of "How do I get there?". This paper looks at the range of techniques used to aid navigation, and categorizes them using three perspectives: perceptual techniques, which use graphical representations and exploit spatial memory to aid navigation; filtering techniques, which operate by automatically reducing the amount of information provided so that the appropriate pieces of information are easy to find; and enrichment techniques, which involve augmenting the view of the software with peripheral information, so that the relative information can be more easily identified.
{"title":"Towards a framework for software navigation techniques","authors":"Andrew Sutherland, Kevin A. Schneider","doi":"10.1145/1370114.1370140","DOIUrl":"https://doi.org/10.1145/1370114.1370140","url":null,"abstract":"Making a change to a large software system requires investing time in understanding the system first. In the context of programming, navigation refers to the process of finding one's way through a complex network of programming constructs and other software artifacts. The process consists of answering questions such as \"What am I looking at?\" and \"What do I want to look at next?\", along with the question of \"How do I get there?\". This paper looks at the range of techniques used to aid navigation, and categorizes them using three perspectives: perceptual techniques, which use graphical representations and exploit spatial memory to aid navigation; filtering techniques, which operate by automatically reducing the amount of information provided so that the appropriate pieces of information are easy to find; and enrichment techniques, which involve augmenting the view of the software with peripheral information, so that the relative information can be more easily identified.","PeriodicalId":107901,"journal":{"name":"Proceedings of the 2008 international workshop on Cooperative and human aspects of software engineering","volume":"34 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-05-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128852257","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}
Because the knowledge required for the construction of a complex software system is often widely distributed among its members, programmers routinely engage in collaboration with each other to acquire knowledge resided in the heads of their peers to accomplish their own programming tasks. We call this kind of collaboration situated knowledge collaboration. Situated knowledge collaboration comes with costs and the costs vary depending on the communication mechanism used. To understand the cost-benefit structure of different communication mechanisms in support of situated knowledge collaboration, we propose the conceptual framework of collective attention economy. The analytic power of the conceptual framework is illustrated in the comparison of two communication mechanisms.
{"title":"The economy of collective attention for situated knowledge collaboration in software development","authors":"Y. Ye, K. Nakakoji, Yasuhiro Yamamoto","doi":"10.1145/1370114.1370142","DOIUrl":"https://doi.org/10.1145/1370114.1370142","url":null,"abstract":"Because the knowledge required for the construction of a complex software system is often widely distributed among its members, programmers routinely engage in collaboration with each other to acquire knowledge resided in the heads of their peers to accomplish their own programming tasks. We call this kind of collaboration situated knowledge collaboration. Situated knowledge collaboration comes with costs and the costs vary depending on the communication mechanism used. To understand the cost-benefit structure of different communication mechanisms in support of situated knowledge collaboration, we propose the conceptual framework of collective attention economy. The analytic power of the conceptual framework is illustrated in the comparison of two communication mechanisms.","PeriodicalId":107901,"journal":{"name":"Proceedings of the 2008 international workshop on Cooperative and human aspects of software engineering","volume":"46 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-05-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124302255","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}
Conducting controlled experiments about programming activities often requires the use of multiple tasks of similar difficulty. In previously reported work about a controlled experiment investigating software exploration tools, we tried to select two change tasks of equivalent difficulty to be performed on a medium-sized code base. Despite careful effort in the selection and confirmation from our pilot subjects finding the two tasks to be of equivalent difficulty, the data from the experiment suggest the subjects found one of the tasks more difficult than the other. In this paper, we report on early work to create a metric to estimate the cognitive difficulty for a software change task. Such a metric would help in comparing between studies of different tools, and in designing future studies. Our particular approach uses a graph-theoretic statistic to measure the complexity of the task solution by the connectedness of the solution elements. The metric predicts the perceived difficulty for the tasks of our experiment, but fails to predict the perceived difficulty for other tasks to a small program. We discuss these differences and suggest future approaches.
{"title":"Creating a cognitive metric of programming task difficulty","authors":"B. D. Alwis, G. Murphy, S. Minto","doi":"10.1145/1370114.1370122","DOIUrl":"https://doi.org/10.1145/1370114.1370122","url":null,"abstract":"Conducting controlled experiments about programming activities often requires the use of multiple tasks of similar difficulty. In previously reported work about a controlled experiment investigating software exploration tools, we tried to select two change tasks of equivalent difficulty to be performed on a medium-sized code base. Despite careful effort in the selection and confirmation from our pilot subjects finding the two tasks to be of equivalent difficulty, the data from the experiment suggest the subjects found one of the tasks more difficult than the other. In this paper, we report on early work to create a metric to estimate the cognitive difficulty for a software change task. Such a metric would help in comparing between studies of different tools, and in designing future studies. Our particular approach uses a graph-theoretic statistic to measure the complexity of the task solution by the connectedness of the solution elements. The metric predicts the perceived difficulty for the tasks of our experiment, but fails to predict the perceived difficulty for other tasks to a small program. We discuss these differences and suggest future approaches.","PeriodicalId":107901,"journal":{"name":"Proceedings of the 2008 international workshop on Cooperative and human aspects of software engineering","volume":"26 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-05-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121699516","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}
In this paper we present a new variation of cultural probes, called Infrastructure Probes (IP). IPs can be seen as an additional ethnographic method to get a deeper understanding of the user's working context and thus help to improve the collaboration between users and developers regarding requirements elicitation. They consist of a screenshot tool, a digital camera, Post-it's, forms, an IT diary and a writing pad, allowing end users to observe and document their use of the IT infrastructure in question with special emphasis on problematic situations. The results of a first evaluation of the concept show that IPs could supplement traditional ethnographic methods to give researchers as well as software engineers a deeper insight into the working habits of users, but could also be a means for users to document and exchange technology usages. For a reflection of the IP concept we conducted feedback workshops together with the participants of the evaluation. The feedback resulted in an improved version which is currently already under evaluation.
{"title":"Fostering user-developer collaboration with infrastructure probes","authors":"Christian Dörner, Jan Hess, V. Pipek","doi":"10.1145/1370114.1370126","DOIUrl":"https://doi.org/10.1145/1370114.1370126","url":null,"abstract":"In this paper we present a new variation of cultural probes, called Infrastructure Probes (IP). IPs can be seen as an additional ethnographic method to get a deeper understanding of the user's working context and thus help to improve the collaboration between users and developers regarding requirements elicitation. They consist of a screenshot tool, a digital camera, Post-it's, forms, an IT diary and a writing pad, allowing end users to observe and document their use of the IT infrastructure in question with special emphasis on problematic situations. The results of a first evaluation of the concept show that IPs could supplement traditional ethnographic methods to give researchers as well as software engineers a deeper insight into the working habits of users, but could also be a means for users to document and exchange technology usages. For a reflection of the IP concept we conducted feedback workshops together with the participants of the evaluation. The feedback resulted in an improved version which is currently already under evaluation.","PeriodicalId":107901,"journal":{"name":"Proceedings of the 2008 international workshop on Cooperative and human aspects of software engineering","volume":"5 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-05-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126455741","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}
In this paper we discuss how the cooperation between developers and operations staff is practiced. We have analyzed data collected from a focus group of experienced software engineers and project managers, as well as interviews from two case studies. Our position is that well performed cooperation between the development team and the operations team is crucial for successful deployment and operations of a new or extensively revised software system. The data shows that cooperation can be improved in several development activities like requirements engineering, system design, documentation, testing, training, and deployment planning. Likely consequences of poor cooperation in these activities are lower productivity in development and operations, as well as unsatisfied users.
{"title":"Cooperation between developers and operations in software engineering projects","authors":"B. Tessem, Jon Iden","doi":"10.1145/1370114.1370141","DOIUrl":"https://doi.org/10.1145/1370114.1370141","url":null,"abstract":"In this paper we discuss how the cooperation between developers and operations staff is practiced. We have analyzed data collected from a focus group of experienced software engineers and project managers, as well as interviews from two case studies. Our position is that well performed cooperation between the development team and the operations team is crucial for successful deployment and operations of a new or extensively revised software system. The data shows that cooperation can be improved in several development activities like requirements engineering, system design, documentation, testing, training, and deployment planning. Likely consequences of poor cooperation in these activities are lower productivity in development and operations, as well as unsatisfied users.","PeriodicalId":107901,"journal":{"name":"Proceedings of the 2008 international workshop on Cooperative and human aspects of software engineering","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2008-05-13","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130445845","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
扫码关注我们
求助内容：
应助结果提醒方式：