Search

This is a demonstration of how to use a deck of Concept Craft Cards that represent the first iteration of a toolkit for Animal-Computer Interaction (ACI) developers. The cards will be available to share, discuss and deploy online in relation to a series of non-human client briefs. At the top conceptual level, we offer suggestions for ACI developers embarking on a new design journey; the next conceptual level considers user experience and offers our recommendations for interaction design that values cognitive and sensory enrichment; at a practical level, we provide a set of topic cards, to be used during development to support the realization of design concepts through crafting and tinkering.

peer-reviewed Developers turn to Stack Overflow and other on-line sources to find solutions to security problems, but little is known about how they engage with and guide one another in these environments or the perceptions of software security this may encourage. This study joins recent calls to understand more about how developers use Internet sources to solve security problems. Using qualitative methods, a set of questions within the security channel of Stack Overflow were selected and examined for themes. Preliminary findings reveal more about this community of practitioners: who are the askers and commenters, how security questions are asked and how developers frame technical information using social and experience-based perceptions of security.

Agile approaches arose as a way of addressing some of the main challenges in software development, such as changing requirements, lack of understanding about the system scope, and out-of-sync between code, requirements, and documentation. Studies show that agile projects still suffer from lack of customer support, resulting in difficulties to represent customer needs on requested features. Behavior-Driven Development (BDD) brings a structured way to represent user behaviors and to validate user stories by using an ubiquitous language, shared among everyone involved on the development of the software. The approach allows the creation of scenarios that can be used by the team to share information between different stakeholders, enabling all those players to successfully collaborate and coordinate their work. In this paper, we report on an empirical study conducted with 24 IT professionals with practical experience on BDD. Through this, we identify the perceived benefits and challenges of adopting BDD.

This case study describes our progress towards the goal of providing technology-enhanced enrichment for an Asian elephant so that she can exercise choice and control. We offer guidelines for developers to show how interaction design with a captive elephant might be approached.

Background: Most companies practicing Agile are not fully Agile but instead they combine both Agile and traditional practices in their operations. It is not clear how these practices can be successfully used together in an organisation.Aims: We investigate practitioners' mitigation strategies related to the challenge of doing Agile in a non-Agile environment.Method: Strategies were collected during two studies, an online survey and an interactive workshop run at an Agile meetup and analysed thematically.Results: Strategies related to the wider organisation and not just software development. Two perspectives emerged from the data: an organisational and a change perspective. Five organisational themes were identified with Management and decision-making and Culture the two biggest themes. Nine change themes were identified, with Being open, Using specific approaches and Educating the biggest themes.Conclusions: Better understanding is needed of how Agile practitioners can accomplish bottom-up change in their organisation.

This extended abstract summarises some key points regarding the role of representations in software design and development, specifically how physical, virtual and hybrid representations support creativity and collaboration.

This research is investigating the potential for designing digital toys and games as playful cognitive enrichment activities for captive elephants. The new field of Animal Computer Interaction is exploring a range of approaches to the problem of designing user-centred systems for animals and this investigation into devices for elephants aims to directly contribute towards a methodological approach for designing smart and playful enrichment for all species.

Context -- Motivation and job satisfaction are not the same thing, and although business organization research recognized this a long time ago, in Software Engineering research, we have not. As a result, thirty years of research on motivation in software engineering has produced knowledge on what makes software engineers generally happier, but not about how to increase their motivation. Goal -- In this article, we aim to identify visible signs of a software engineer who is motivated to work. Method -- We describe a field study in which 62 practitioners in Brazil reported their view of "motivation" in the context of their practical work. Data was collected by means of audio-recorded semi-structured interviews, and a thematic analysis was applied to identify the most relevant descriptors of motivation. Results -- Our data reveal that (1) motivated Software Engineers are engaged, focused, and collaborative; and (2) the term "motivation" is used as an umbrella term to cover several distinct organizational behaviours that are not necessarily related to the individual's desire to work. Conclusions -- Without a clear picture of the difference between these two concepts, work-based motivation programs may not be designed effectively to address either turnover or performance issues. Overall, this work indicates the need for a more effective conceptual system to investigate and encourage both job satisfaction and work motivation in software engineering research and practice.

An agile software development team relies on communication and collaboration to perform requirements engineering activities, rather than on dedicated analysis tools or documentation. Evidence from practice indicates that two simple physical artefacts (story cards and the wall), used in a particular and disciplined manner, and supported by appropriate social activity, are key to the success of co-located agile teams. However, little is known about this social activity or how communication and collaboration supports requirements activities in this setting. This paper reports an empirical study of a commercial agile team to investigate this issue. Using a combination of qualitative data collection and cognitive analysis techniques, we found evidence of gathering, evolving and clarifying requirements that are managed through patterns of communication. These patterns suggest that a form of situated conceptualization, which we have termed 'shared conceptualization', underpins the team's requirements engineering activities.

Agile software development methods suggest that sharing tasks between a pair of developers has advantages over letting them work as individuals. This effect has been observed in designing and coding tasks too. However, it is not yet known whether or not pairing on requirements engineering tasks could deliver a similar benefit at an early phase of software projects. Based on first-hand experience in pairing development of the OpenOME tool, we analyse the evolving stakeholder requirements using the i*/Tropos method. Our findings show that sharing tasks of different roles becomes more effective when those roles are played by one stakeholder, possibly due to smaller communication delay at a shorter distance.

Software is created by people for people working in varied environments, under various conditions. Thus understanding cooperative and human aspects of software development is crucial to comprehend how methods and tools are used, and thereby improve the creation and maintenance of software. Over the years, both researchers and practitioners have recognized the need to study and understand these aspects. Despite recognizing this, researchers in cooperative and human aspects have no clear place to meet and are dispersed in different research conferences and areas. The goal of this workshop is to provide a forum for discussing high quality research on human and cooperative aspects of software engineering. We aim at providing both a meeting place for the growing community and the possibility for researchers interested in joining the field to present their work in progress and get an overview over the field.

Software practitioner motivation has been recognised as a key factor in system quality, yet much of what we know about practitioner motivation is based on research conducted decades ago. In this paper, we present the analysis of data collected from 23 current practitioners at a workshop on motivation. This is the third in a series of workshops, each aimed at investigating the motivational factors in current software practice. We found that people factors are those most often cited, which reinforces the findings from the two previous workshops. This has implications for motivational programmes in software organisations, and indicates the need for further empirical research in the area.

Software is created by people---software engineers---working in varied environments, under various conditions. Thus understanding cooperative and human aspect of software development is crucial to comprehend how methods and tools are used, and thereby improving the creation and maintenance of software. Inspired by the hosting country's concept of co-responsibility -- ubuntu -- we especially invited contributions that address community-based development like open source development and sustainability of ICT eco-systems. The goal of this workshop is to provide a forum for discussing high quality research on human and cooperative aspects of software engineering. We aim at providing both a meeting place for the growing community and the possibility for researchers interested in joining the field to present their work in progress and get an overview over the field.

This tutorial provides an overview of the role of ethnography in Software Engineering research. It describes the use of ethnographic methods as a means to provide an in-depth understanding of the socio-technological realities surrounding everyday software development practice. The knowledge gained can be used to improve processes, methods and tools as well as develop observed industrial practices. The tutorial begins with a brief historical account of ethnography in the fields of Software Engineering, CSCW, Information Systems and other related areas. This sets the stage for a more in-depth discussion of methods for data collection and analysis used in ethnographic studies. It then describes how these methods can be and have been used by software engineering researchers to understand developers' work practices, to inform the development of processes, methods and tools and to evaluate the applicability of current processes, methods and tools. Finally, some practical issues concerning the selection and use of ethnographic methods by software engineers are discussed. Throughout the tutorial, examples from the presenters' experience illustrate the points made.

The importance of integrating software engineering and HCI methods has been recognised for many years. Agile development is a new approach to software engineering that explicitly champions an active role for the customer. Indeed, eXtreme Programming (XP), one of the most popular agile development methods, strives to include a real user(s) in the team who is located 'on-site' with software developers.In this panel we will debate whether or not agile software development provides an opportunity to integrate HCI and software engineering concerns. The panel members represent a wide cross-section of experiences in this area and will consider how agile development can help improve the current situation, consider specific example scenarios provided by the audience, and, with the audience's help, will decide whether agile development is an opportunity not to be missed, or just another fad that will pull the two communities further apart.

The project, which started in 1996, aims to encourage the capture and dissemination of successful experience of learning and teaching OT from industry and academia. Today, a significant body of material exists. We welcome contributions from people with experiences to share, or whose own practice is reflected in existing material.