Artifact-based software process improvement and management: a method proposal

When it comes to software process improvement (SPI), process engineers look for SPI methods to support process analysis, design, realization, deployment, and management. Although a number of di erent SPI methods and models exist, process engineers tend to view these as too generic, too large, or a poor t for the organization in which SPI is conducted. A strategy to overcome these shortcomings is to concentrate on the artifacts, which precisely de ne the desired outcomes, rather than on speci c methods. In this paper, we present the Artifact-based Software Process Improvement & Management (ArSPI) model that provides a uni ed perspective on SPI and company-wide software process management (SPM), the required key artifacts, and the life cycle models. ArSPI is shown to be of practical support to industry who called for a practical way to de ne the interfaces between SPI projects. This paper concludes with an example of how ArSPI paved the way for several organizations through applying the model in real-world SPI projects

Global software engineering education practice continuum special issue of the ACM transactions on computing education

We are pleased to introduce this Special Issue on Global Software Engineering Education published by the ACM Transactions on Computing Education (TOCE) that focuses on educational practices to prepare students for a global workplace. This issue comes at a time when universities are recognizing the need to provide courses that address the challenges of distributed development and presents research that will facilitate course leaders currently running, or embarking on, Global Software Engineering Education (GSE-Ed)

How agile is hybrid agile? An analysis of the HELENA data

Context: Many researchers advocate “tailoring” agile methods to suit a project’s or company’s specific environment and needs. This includes combining agile methods with more traditional “plan driven” practices.Objective: This study aims to assess to what extent projects actually combine agile and traditional practices.Method: Data from the HELENA survey of nearly 700 projects were examined to assess how many projects combine agile methods and traditional methods, and also to what extent they used different software development practices.Results: The data show that, overall, two-thirds of the projects in the survey combine agile and traditional methods to some extent. However, projects that combine agile and traditional methods are significantly less likely to use agile practices than projects that solely use agile methods.Conclusions: We hypothesize that the mindset of an organization, rather than technical necessity, determines whether a project will adopt a hybrid vs. purely agile approach.</p

A qualitative study of open source software development: the OpenEMR project

Open Source software is competing successfully in many areas. The commercial sector is recognizing the benefits offered by Open Source development methods that lead to high quality software. Can these benefits be realized in specialized domains where expertise is rare? This study examined discussion forums of an Open Source project in a particular specialized application domain – electronic medical records – to see how development roles are carried out, and by whom. We found through a qualitative analysis that the core developers in this system include doctors and clinicians who also use the product. We also found that the size of the community associated with the project is an order of magnitude smaller than predicted, yet still maintains a high degree of responsiveness to issues raised by users. The implication is that a few experts and a small core of dedicated programmers can achieve success using an Open Source approach in a specialized domain

Stakeholder dissonance: disagreements on project outcome and its impact on team motivation across three countries

When a project perceived to be a failure by one set of stakeholders is perceived as a success by another set of stakeholders we have outcome disagreement. Our objective is to discover if team motivation is affected when developers and managers disagree on a project's outcome. We also investigate if culture influences team motivation. We collected questionnaire data on 290 completed projects from software engineering practitioners based in Australia, Chile, and USA. We asked if the respondent considered their project was successful and if higher level management considered the project a success. We found that more projects were perceived successful by management than by developers. Also, successful projects are associated with higher levels of team motivation than failed projects or projects with outcome disagreement. Culture makes a difference to levels of team motivation for both failed projects, and projects with outcome disagreement. An over-riding influence on team motivation is agreement with other stakeholders. To motivate practitioners, stakeholders need to agree on what constitutes a successful or a failed project before the start of the project

Usability recommendations for designers of smartphone applications for older adults: an empirical study

Older adults (OAs) are a growing and dominant part of the global population, with specific communication and usability needs. Information technology, such as smartphone applications, has the potential to help OAs stay connected, yet some designs do not appeal to this group of users. Current recommendations for the design of usable smartphone applications for OAs can be hard to apply and difficult to interpret. As a result, designers of smartphone applications do not have a clear set of recommendations for the design of smartphones for OAs. In this paper we elicit and transform usability trends and difficulties experienced directly by tech-savvy1 OA users, into an organised set of recommendations. To do this we conducted an empirical study in four stages: (1) Data extraction. Digital context is extracted through conducting Think Aloud sessions with tech-savvy OAs (aged 50+); (2) Data mapping. Digital content extractions are apped against 7 key aspects of usability; (3) Validation. Validated mappings through inter-rater reliability testing; (4) Presentation. Presented resultant recommendations as design patterns. Applying this method resulted in a set of 131 Usability recommendations with some overlap, transformed into a set of 14 design patterns that can act as a starting point for designers and developers of smartphone applications for OAs, and for pedagogy. Three of these patterns are presented in this study.</p

Using the PMBOK® guide to frame GSD coordination strategies

Global software development (GSD) carried out at various locations is impeded by global distance categorized as exterior and interior. To overcome this, specific communication strategies are required to coordinate a range of activities between client and vendor teams working on GSD projects. The literature on GSD recommends many coordination strategies, but tends to take the client viewpoint as vendor companies have been underrepresented in publications. In this paper, we compare coordination strategies identified in both the literature and in primary research which we conducted in Indian vendor companies with the Project Communication Management section of the PMBOK® Guide. This comparison helped us to define a set of expert-validated coordination strategies for use by GSD practitioners. While developed from the vendor rather than the client perspective, indications are that project managers from both client and vendor organisations can implement these strategies to overcome GSD coordination issues

Global software development and collaboration : barriers and solutions

While organisations recognise the advantages offered by global software development, there are many socio-technical barriers that affect successful collaboration in this inter-cultural environment. In this paper we present a review of the global software development literature where we highlight collaboration problems experienced by a cross-section of organisations in twenty-six studies. We also look at the literature to answer how organisations are over- coming these barriers in practice. We build on our previous study on global software development where we define collaboration as four practices related to agreeing, allocating, and planning goals, objectives, and tasks among distributed teams. We found that the key barriers to collaboration are geographic, temporal, cultural, and linguistic distance; the primary solutions to overcoming these barriers include site visits, synchronous communication technology, and knowledge sharing infrastructure to capture implicit knowledge and make it explicit

Global Software Development - Coordination and project management strategies from a vendor perspective

Global software development (GSD) is often impeded by global distance which may be geographical, cultural, temporal or linguistic. When compared to a collocated setting, specific methods are required to coordinate a range of activities in the GSD environment. Therefore, to manage and reduce global distance there is a need for continuous coordination within both client and vendor companies. Our literature review [Deshpande et al, 2011], shows that only 15% of the research studies for GSD are from the vendor’s perspective. There is a similar assertion made by Gonzalez et al (2006) where they identified that only 16% of the research studies explore outsourcing from the perspective of the service provider or vendor. Vendor companies have solved many of the global distance related issues. Both client and vendor companies need insight into these solutions which will assist them to successfully coordinate distributed projects. The research presented in this paper is addressing these gaps. Following our systematic literature review and empirical research within vendor companies, we have compared GSD coordination from the vendor perspective with the Project Management Body of Knowledge guide [PMBOK® Guide, 2008]. We have established that while the PMBOK® Guide partially supports GSD coordination within vendor companies, there are some solutions implemented by vendors but are not included in it. In this paper we present a comparative analysis between the human resource management techniques of the PMBOK® Guide with the coordination practices in GSD that in future will be incorporated into a model for coordination of tasks in GS

The case of Golden Jubilants: using a prototype to support healthcare technology research

This case study paper describes the development and evaluation of a prototype, Golden Jubilants, a smartphone app. Golden Jubilants was built within a software engineering in healthcare project, ReDEAP, that aimed to identify a set of recommendations for the design of smartphone apps for older adults aged over 50. Prototype development and evaluation is a recognized way to elicit meaningful feedback from any user group. This tangible artifact was interactive and provided fruitful engagement for us as researchers, and for the older adults who participated. This short paper presents the prototype evaluation process, and techniques used to ensure older adult involvement. To conclude, we discuss four key recommendations for consideration by software engineering in healthcare researchers who are using prototypes in their research – develop the research project through public and patient involvement, harness the potential of established evaluation and testing standards, develop a needed and tangible prototype, and involve an external group to evaluate findings