Use of an agile bridge in the development of assistive technology

Engaging with end users in the development of assistive technologies remains one of the major challenges for researchers and developers in the field of accessibility and HCI. Developing usable software systems for people with complex disabilities is problematic, software developers are wary of using user-centred design, one of the main methods by which usability can be improved, due to concerns about how best to work with adults with complex disabilities, in particular Severe Speech and Physical Impairments (SSPI) and how to involve them in research. This paper reports on how the adoption of an adapted agile approach involving the incorporation of a user advocate on the research team helped in meeting this challenge in one software project and offers suggestions for how this could be used by other development teams

Safety-Critical Systems and Agile Development: A Mapping Study

In the last decades, agile methods had a huge impact on how software is developed. In many cases, this has led to significant benefits, such as quality and speed of software deliveries to customers. However, safety-critical systems have widely been dismissed from benefiting from agile methods. Products that include safety critical aspects are therefore faced with a situation in which the development of safety-critical parts can significantly limit the potential speed-up through agile methods, for the full product, but also in the non-safety critical parts. For such products, the ability to develop safety-critical software in an agile way will generate a competitive advantage. In order to enable future research in this important area, we present in this paper a mapping of the current state of practice based on {a mixed method approach}. Starting from a workshop with experts from six large Swedish product development companies we develop a lens for our analysis. We then present a systematic mapping study on safety-critical systems and agile development through this lens in order to map potential benefits, challenges, and solution candidates for guiding future research.Comment: Accepted at Euromicro Conf. on Software Engineering and Advanced Applications 2018, Prague, Czech Republi

When situativity meets objectivity in peer-production of knowledge:the case of the WikiRate platform

PurposeThe purpose of this paper is to further the debate on Knowledge Artefacts (KAs), by presenting the design of WikiRate, a Collective Awareness platform whose goal is to support a wider public contributing to the generation of knowledge on environmental, social and governance (ESG) performance of companies.Design/methodology/approachThe material presented in the paper comes from the first-hand experience of the authors as part of the WikiRate design team. This material is reflexively discussed using concepts from the field of science and technology studies.FindingsUsing the concept of the “funnel of interest”, the authors discuss how the design of a KA like WikiRate relies on the designers’ capacity to translate general statements into particular design solutions. The authors also show how this funnelling helps understanding the interplay between situativity and objectivity in a KA. The authors show how WikiRate is a peer-production platform based on situativity, which requires a robust level of objectivity for producing reliable knowledge about the ESG performance of companies.Originality/valueThis paper furthers the debate on KAs. It presents a relevant design example and offers in the discussion a set of design and community building recommendations to practitioners

Looking for Reasons behind Success in Dealing with Requirements Change

During development, requirements of software systems are subject to change. Unfortunately, managing changing requirements can take a lot of time and effort. Yet some companies show a better management of changes in requirements than others. Why? What is it that makes some projects deal with changing requirements better than others? We pursue the long term goal of understanding the mechanisms used to successfully deal with change in requirements. In this paper we gather knowledge about the state-of-the-art and the state-of-practice. We studied eight software development projects in four different companies --large and small, inclined toward structured and toward agile principles of development--, interviewing their project managers and analyzing their answers. Our findings include a list of practical (rather than theoretical) factors affecting the ability to cope with small changes in requirements. Results suggest a central role of size as a factor determining the flexibility showed either by the organization or by the software development team. We report the research method used and validate our results via expert interviews, who could relate to our findings

Creating business value from big data and business analytics : organizational, managerial and human resource implications

This paper reports on a research project, funded by the EPSRC’s NEMODE (New Economic Models in the Digital Economy, Network+) programme, explores how organizations create value from their increasingly Big Data and the challenges they face in doing so. Three case studies are reported of large organizations with a formal business analytics group and data volumes that can be considered to be ‘big’. The case organizations are MobCo, a mobile telecoms operator, MediaCo, a television broadcaster, and CityTrans, a provider of transport services to a major city. Analysis of the cases is structured around a framework in which data and value creation are mediated by the organization’s business analytics capability. This capability is then studied through a sociotechnical lens of organization/management, process, people, and technology. From the cases twenty key findings are identified. In the area of data and value creation these are: 1. Ensure data quality, 2. Build trust and permissions platforms, 3. Provide adequate anonymization, 4. Share value with data originators, 5. Create value through data partnerships, 6. Create public as well as private value, 7. Monitor and plan for changes in legislation and regulation. In organization and management: 8. Build a corporate analytics strategy, 9. Plan for organizational and cultural change, 10. Build deep domain knowledge, 11. Structure the analytics team carefully, 12. Partner with academic institutions, 13. Create an ethics approval process, 14. Make analytics projects agile, 15. Explore and exploit in analytics projects. In technology: 16. Use visualization as story-telling, 17. Be agnostic about technology while the landscape is uncertain (i.e., maintain a focus on value). In people and tools: 18. Data scientist personal attributes (curious, problem focused), 19. Data scientist as ‘bricoleur’, 20. Data scientist acquisition and retention through challenging work. With regards to what organizations should do if they want to create value from their data the paper further proposes: a model of the analytics eco-system that places the business analytics function in a broad organizational context; and a process model for analytics implementation together with a six-stage maturity model

Video Game Development in a Rush: A Survey of the Global Game Jam Participants

Video game development is a complex endeavor, often involving complex software, large organizations, and aggressive release deadlines. Several studies have reported that periods of "crunch time" are prevalent in the video game industry, but there are few studies on the effects of time pressure. We conducted a survey with participants of the Global Game Jam (GGJ), a 48-hour hackathon. Based on 198 responses, the results suggest that: (1) iterative brainstorming is the most popular method for conceptualizing initial requirements; (2) continuous integration, minimum viable product, scope management, version control, and stand-up meetings are frequently applied development practices; (3) regular communication, internal playtesting, and dynamic and proactive planning are the most common quality assurance activities; and (4) familiarity with agile development has a weak correlation with perception of success in GGJ. We conclude that GGJ teams rely on ad hoc approaches to development and face-to-face communication, and recommend some complementary practices with limited overhead. Furthermore, as our findings are similar to recommendations for software startups, we posit that game jams and the startup scene share contextual similarities. Finally, we discuss the drawbacks of systemic "crunch time" and argue that game jam organizers are in a good position to problematize the phenomenon.Comment: Accepted for publication in IEEE Transactions on Game