Tools used in Global Software Engineering: A systematic mapping review

ContextThis systematic mapping review is set in a Global Software Engineering (GSE) context, characterized by a highly distributed environment in which project team members work separately in different countries. This geographic separation creates specific challenges associated with global communication, coordination and control.ObjectiveThe main goal of this study is to discover all the available communication and coordination tools that can support highly distributed teams, how these tools have been applied in GSE, and then to describe and classify the tools to allow both practitioners and researchers involved in GSE to make use of the available tool support in GSE.MethodWe performed a systematic mapping review through a search for studies that answered our research question, “Which software tools (commercial, free or research based) are available to support Global Software Engineering?” Applying a range of related search terms to key electronic databases, selected journals, and conferences and workshops enabled us to extract relevant papers. We then used a data extraction template to classify, extract and record important information about the GSD tools from each paper. This information was synthesized and presented as a general map of types of GSD tools, the tool’s main features and how each tool was validated in practice.ResultsThe main result is a list of 132 tools, which, according to the literature, have been, or are intended to be, used in global software projects. The classification of these tools includes lists of features for communication, coordination and control as well as how the tool has been validated in practice. We found that out the total of 132, the majority of tools were developed at research centers, and only a small percentage of tools (18.9%) are reported as having been tested outside the initial context in which they were developed.ConclusionThe most common features in the GSE tools included in this study are: team activity and social awareness, support for informal communication, Support for Distributed Knowledge Management and Interoperability with other tools. Finally, there is the need for an evaluation of these tools to verify their external validity, or usefulness in a wider global environment.     

The impact of global dispersion on coordination,team performance and software quality – A systematic literature review

ContextGlobal software development (GSD) contains different context setting dimensions, which are essential for effective teamwork and success of projects. Although considerable research effort has been made in this area, as yet, no agreement has been reached about the impact of these dispersion dimensions on team coordination and project outcomes.ObjectiveThis paper summarizes empirical evidence on the impact of global dispersion dimensions on coordination, team performance and project outcomes.MethodWe performed a systematic literature review of 46 publications from 25 journals and 19 conference and workshop proceedings, which were published between 2001 and 2013. Thematic analysis was used to identify global dimensions and their measures. Vote counting was used to decide on the impact trends of dispersion dimensions on team performance and software quality.ResultsGlobal dispersion dimensions are consistently conceptualized, but quantified in many different ways. Different dispersion dimensions are associated with a distinct set of coordination challenges. Overall, geographical dispersion tends to have a negative impact on team performance and software quality. Temporal dispersion tends to have a negative impact on software quality, but its impact on team performance is inconsistent and can be explained by type of performance.ConclusionFor researchers, we reveal several opportunities for future research, such as coordination challenges in inter-organizational software projects, impact of processes and practices mismatches on project outcomes, evolution of coordination needs and mechanism over time and impact of dispersion dimensions on open source project outcomes. For practitioners, they should consider the tradeoff between cost and benefits while dispersing tasks, alignment impact of dispersion dimensions with individual and organizational objectives, coordination mechanisms as situational approaches and collocation of development activities of high quality demand components in GSD projects.     

Managing uncertainty in software projects

Although it is impossible to predict problems that will occur in software projects, project managers can employ strategies that imbue their projects with greater resilience. Throughout a software project, a series of practices can be established to manage uncertainties. This paper proposes an approach to managing uncertainty in software projects. The approach seems to improve project performance and success. This work is based on the principles of evidence-based software engineering. We conduct an exploratory literature search and a systematic literature review. In addition, we carry out action research in a software development project. Semi-structured interviews were conducted to evaluate and improve this approach. Finally, we held a focus group to evaluate the final proposed approach. The exploratory review helped to characterise the difference between risk and uncertainty. The systematic literature review revealed five methods and 18 practices for reducing uncertainties. The action research applied some of these techniques and investigated whether they contributed to a better uncertainty management. In the semi-structured interviews, practical points of view were added to the approach. This work defines an approach to uncertainty management and describes strategies that allow team members to explicitly formalise and manage uncertainty in software projects.     

Users’ involvement may help respect social and ethical values and improve software quality

Global informatization brings potential threats. It is possible to reduce them if software developers are aware of those threats and if customers insist on eliminating them. The survey described in the paper shows that future programmers are aware of numerous threats associated with global informatization. Many threats may be reduced by users’ involvement in the software process. Software developers should learn and develop cooperation with users, as emphasized in agile methodologies. It is a task for academic teachers to promote collaboration between software authors and users, to show how to organize it, and to convince programmers that it is valuable. Users’ involvement requires changes in the software life cycle and in the set of established processes. Such changes, in the form of additionally established processes and phases in the software development cycle, are identified in the paper. One recommended process is the software product assessment intended to elicit feedback from users. Users’ involvement may help to respect ethical and social values and to produce software adapted to user expectations.     

Exploring the relationship between software project duration and risk exposure: A cluster analysis

Software projects often fail. Thus it is important to find ways to ensure a successful outcome. One significant area is a better understanding of the relationship between the software project duration and risk exposure, as this helps project managers with pertinent information to be effective in managing risky projects. We addressed this need by adopting a cluster analysis technique to provide managers with insight into effective planning and control of their projects. The results not only revealed that risk exposures associated with user, requirement, planning & control and team risk dimensions were affected by project duration, but also showed how to manage software risks effectively through observing trends in the risk components. Based on our findings, project managers can adopt appropriate attitudes, skills, and practices to deal with risky areas more effectively rather than just identifying those software risks with which project managers should be concerned.     

Managing Knowledge in Global Software Development Efforts: Issues and Practices

The knowledge-intensive nature of current global software development efforts poses interesting challenges. Organizations must manage knowledge in all stages of software development efforts—from encapsulating design requirements to creating and testing programs, installation, and maintenance. Knowledge even extends to the improvement of organizational software development processes and practices. This article examines knowledge management practices in more than 50 software organizations over the last three years, describing the major findings in the context of knowledge management in software development efforts on a global scale.This article is part of a special issue on Global Software Development.     

Evaluating performance in the development of software-intensive products

ContextOrganizational performance measurements in software product development have received a lot of attention in the literature. Still, there is a general discontent regarding the way performance is evaluated in practice, with few studies really focusing on why this is the case. In this paper research focusing on the context of developing software-intensive products in large established multi-national organizations is reported on.ObjectiveThe purpose of this research is to investigate performance measurement practices related to software product development activities. More specifically, focus is on exploring how managers engaged in software product development activities perceive and evaluate performance in large organizations from a managerial perspective.MethodThe research approach pursued in this research consist of exploratory multiple case studies. Data is collected mainly through 54 interviews in five case studies in large international organizations developing software-intensive products in Sweden. Focused group interviews with senior managers from eight companies have also been used in the data collection.ResultsThe results of this research indicate that managers within software product development in general are dissatisfied with their current way of evaluating performance. Performance measurements and the perception of performance are today focused on cost, time, and quality, i.e. what is easily measurable and not necessarily what is important. The dimensions of value creation and learning are missing. Moreover, measurements tend to be result oriented, rather than process oriented, making it difficult to integrate these measurements in the management practices.ConclusionManagers that are dissatisfied with their performance measurement system and want to improve the current situation should not start by focusing on the current measurements directly; instead they should focus on how the organization perceives performance and how important performance criteria are being developed. By developing relevant performance criteria the first step in developing an effective performance measurement system is made. Moreover, it is concluded that manager’s perception of performance is affected by the currently used measurements, hence limiting the scope of the performance criteria. Thus, a change in the way managers perceive performance is necessary before there can be any changes in the way performance is evaluated.     

How experienced project managers assess risk

Software development projects, given their diverse and abstract nature, offer unique challenges and risks. Although a substantial body of literature has been written to address project risk management, my experience in the field led me to question whether this literature accurately mirrors the concerns of real-world project managers. To confirm my suspicions, I surveyed 14 experienced application systems developers, all located in Ireland. All survey participants manage custom-built, software-intensive application development projects that originate from external clients. The survey focused on three major areas: (1) Which characteristics of the customer, the application, and so on, do experienced software project managers consider important when planning new development projects for new, external clients? (2) How do these characteristics relate to accepted software project risk drivers? (3) Do most project managers characterize new projects in generally the same way, or do different project managers use different perceptual lenses when viewing new projects? This survey of a homogenous group of project managers revealed a surprising diversity of risk management concerns     

Innovative Practices for IT Projects

Abstract

Based on 57 interviews with senior IT project managers in the UK Canada, USA and New Zealand, this article presents innovative practices they have developed during difficult projects. In our respondents' view, traditional project management methods and techniques are only a starting point. Through their quotes, they show how one has to be creative and entrepreneurial to lead projects successfully.     

An empirical research agenda for understanding formal methods productivity

ContextFormal methods, and particularly formal verification, is becoming more feasible to use in the engineering of large highly dependable software-based systems, but so far has had little rigorous empirical study. Its artefacts and activities are different to those of conventional software engineering, and the nature and drivers of productivity for formal methods are not yet understood.ObjectiveTo develop a research agenda for the empirical study of productivity in software projects using formal methods and in particular formal verification. To this end we aim to identify research questions about productivity in formal methods, and survey existing literature on these questions to establish face validity of these questions. And further we aim to identify metrics and data sources relevant to these questions.MethodWe define a space of GQM goals as an investigative framework, focusing on productivity from the perspective of managers of projects using formal methods. We then derive questions for these goals using Easterbrook et al.’s (2008) taxonomy of research questions. To establish face validity, we document the literature to date that reflects on these questions and then explore possible metrics related to these questions. Extensive use is made of literature concerning the L4.verified project completed within NICTA, as it is one of the few projects to achieve code-level formal verification for a large-scale industrially deployed software system.ResultsWe identify more than thirty research questions on the topic in need of investigation. These questions arise not just out of the new type of project context, but also because of the different artefacts and activities in formal methods projects. Prior literature supports the need for research on the questions in our catalogue, but as yet provides little evidence about them. Metrics are identified that would be needed to investigate the questions. Thus although it is obvious that at the highest level concepts such as size, effort, rework and so on are common to all software projects, in the case of formal methods, measurement at the micro level for these concepts will exhibit significant differences.ConclusionsEmpirical software engineering for formal methods is a large open research field. For the empirical software engineering community our paper provides a view into the entities and research questions in this domain. For the formal methods community we identify some of the benefits that empirical studies could bring to the effective management of large formal methods projects, and list some basic metrics and data sources that could support empirical studies. Understanding productivity is important in its own right for efficient software engineering practice, but can also support future research on cost-effectiveness of formal methods, and on the emerging field of Proof Engineering.     

Performance appraisal of software testers

ContextTo determine the effectiveness of software testers a suitable performance appraisal approach is necessary, both for research and practice purposes. However, review of relevant literature reveals little information of how software testers are appraised in practice.Objective(i) To enhance our knowledge of industry practice of performance appraisal of software testers and (ii) to collect feedback from project managers on a proposed performance appraisal form for software testers.MethodA web-based survey with questionnaire was used to collect responses. Participants were recruited using cluster and snowball sampling. 18 software development project managers participated.ResultsWe found two broad trends in performance appraisal of software testers – same employee appraisal process for all employees and a specialized performance appraisal method for software testers. Detailed opinions were collected and analyzed on how performance of software testers should be appraised. Our proposed appraisal approach was generally well-received.ConclusionFactors such as number of bugs found after delivery and efficiency of executing test cases were considered important in appraising software testers’ performance. Our proposed approach was refined based on the feedback received.     

A little bit of knowledge is a dangerous thing [knowledgemanagement]

After studying knowledge management in recent years, wondering if it could help me manage software projects better, I have concluded that indeed it can. To illustrate this point, I list potential knowledge management benefits and drawbacks organized around the classical functions software managers perform     

Exploring principles of user-centered agile software development: A literature review

ContextIn the last decade, software development has been characterized by two major approaches: agile software development, which aims to achieve increased velocity and flexibility during the development process, and user-centered design, which places the goals and needs of the system’s end-users at the center of software development in order to deliver software with appropriate usability. Hybrid development models, referred to as user-centered agile software development (UCASD) in this article, propose to combine the merits of both approaches in order to design software that is both useful and usable.ObjectiveThis paper aims to capture the current state of the art in UCASD approaches and to derive generic principles from these approaches. More specifically, we investigate the following research question: Which principles constitute a user-centered agile software development approach?MethodWe conduct a systematic review of the literature on UCASD. Identified works are analyzed using a coding scheme that differentiates four levels of UCASD: the process, practices, people/social and technology dimensions. Through subsequent synthesis, we derive generic principles of UCASD.ResultsWe identified and analyzed 83 relevant publications. The analysis resulted in a comprehensive coding system and five principles for UCASD: (1) separate product discovery and product creation, (2) iterative and incremental design and development, (3) parallel interwoven creation tracks, (4) continuous stakeholder involvement, and (5) artifact-mediated communication.ConclusionOur paper contributes to the software development body of knowledge by (1) providing a broad overview of existing works in the area of UCASD, (2) deriving an analysis framework (in form a coding system) for works in this area, going beyond former classifications, and (3) identifying generic principles of UCASD and associating them with specific practices and processes.     

Requirements for Security Enhancements to Legacy Software with RUP

ABSTRACT

This article describes how to adapt a specific part of the Rational Unified Process (RUP) framework for the purpose of conducting requirements gathering for software projects aimed at adding security features to legacy software. The RUP seems particularly fitting for this purpose because it aggregates numerous software engineering terms into a common body of knowledge and strives to give them clear and unambiguous semantics. Furthermore, the RUP allows project coordinators to pick and choose only the process elements best suited to meet the particular needs of a project.

The article should prove useful to project managers, process engineers, and software architects responsible for teaching old software new security functions. It should also prove useful to organizations that have already carried out basic software security projects such as those that fix buffer overflows, teach the software to perform better data validation, replace unsafe string handling functions, and recompile code with safe exception handling. This article covers only a small and very specific part of the RUP. It interprets the RUP in ways guided by the author's experience and specializes the Requirements discipline for use in projects tasked with adding new security features to legacy software.     

Risk management capability model for the development of medical device software

Failure of medical device (MD) software can have potentially catastrophic effects, leading to injury of patients or even death. Therefore, regulators penalise MD manufacturers who do not demonstrate that sufficient attention is devoted to the areas of hazard analysis and risk management (RM) throughout the software lifecycle. This paper has two main objectives. The first objective is to compare how thorough current MD regulations are with relation to the Capability Maturity Model Integration (CMMI^®) in specifying what RM practices MD companies should adopt when developing software. The second objective is to present a Risk Management Capability Model (RMCM) for the MD software industry, which is geared towards improving software quality, safety and reliability. Our analysis indicates that 42 RM sub-practices would have to be performed in order to satisfy MD regulations and that only an additional 8 sub-practices would be required in order to satisfy all the CMMI^® level 1 requirements. Additionally, MD companies satisfying the CMMI^® goals of the RM process area by performing the CMMI^® RM practices will not meet the requirements of the MD software RM regulations as an additional 20 MD-specific sub-practices have to be added to meet the objectives of RMCM.     

Stakeholders in Global Requirements Engineering: Lessons Learned from Practice

Due to its communication and collaboration-intensive nature, as well as inherent interaction with most other development processes, the practice of requirements engineering is becoming a key challenge in global software engineering (GSE). In distributed projects, cross-functional stakeholder groups must specify and manage requirements across cultural, time-zone, and organizational boundaries. This creates a unique set of problems, not only when an organization opens new development subsidiaries across the world but also when software development is a multiorganizational business affair. We need innovative processes and technologies to manage stakeholders' expectations and interaction in global projects. This article reports on the state of the practice, drawn from industrial empirical studies, of stakeholders' interaction in global RE. The article revisits stakeholders' needs in global RE, discusses the challenges they face in distributed interaction, and offers practical advice to alleviate these challenges, as distilled from empirical studies of GSE practice     

Estimating,planning and managing Agile Web development projects under a value-based perspective

ContextThe processes of estimating, planning and managing are crucial for software development projects, since the results must be related to several business strategies. The broad expansion of the Internet and the global and interconnected economy make Web development projects be often characterized by expressions like delivering as soon as possible, reducing time to market and adapting to undefined requirements. In this kind of environment, traditional methodologies based on predictive techniques sometimes do not offer very satisfactory results. The rise of Agile methodologies and practices has provided some useful tools that, combined with Web Engineering techniques, can help to establish a framework to estimate, manage and plan Web development projects.ObjectiveThis paper presents a proposal for estimating, planning and managing Web projects, by combining some existing Agile techniques with Web Engineering principles, presenting them as an unified framework which uses the business value to guide the delivery of features.MethodThe proposal is analyzed by means of a case study, including a real-life project, in order to obtain relevant conclusions.ResultsThe results achieved after using the framework in a development project are presented, including interesting results on project planning and estimation, as well as on team productivity throughout the project.ConclusionIt is concluded that the framework can be useful in order to better manage Web-based projects, through a continuous value-based estimation and management process.     

Software Process Improvement barriers: A cross-cultural comparison

ContextSoftware Process Improvement initiatives have been around for many years with the growing globalisation of software development is making them increasingly important.ObjectiveThe objective of this exploratory research is to gain an in-depth understanding of barriers that can undermine SPI, in the context of Global Software Development, from the perspective of software development practitioners; this will enable SPI managers to better manage SPI initiatives. We intend to discover if the barriers to SPI initiatives in a developed country are different to those in a developing country.MethodIn an empirical study, Vietnamese software practitioners’ experiences of SPI barriers are compared with barriers identified by Australian practitioners. Face-to-face questionnaire-based survey sessions with 23 Vietnamese SPI practitioners were conducted. Our survey included barriers to SPI improvement initiatives identified in previous research. We asked the participants to rank each SPI barrier on a three-point scale (high, medium, low) to determine the importance of each barrier. We then compare our results, with results (identified in previous work), from 34 Australian software development practitioners.ResultsWe identify (1) lack of project management, (2) lack of resources, (3) lack of sponsorship, (4) inexperienced staff/lack of knowledge, and (5) lack of SPI awareness as ‘high’ value SPI barriers in Vietnam. The results also reveal similarities and differences between the experiences of Australian and Vietnamese practitioners regarding the importance of the SPI barriers identified. While the Australian practitioners were also concerned with (1) lack of SPI awareness, they were even more concerned with (2) organisational politics, and (3) lack of support.ConclusionsPractitioners identify SPI barriers based on previous SPI implementation experience. Their role(s) in their different organisations have helped them to understand the importance of that barrier. Vietnamese software practitioners cited more SPI barriers than their counterparts in Australia. The Vietnamese SPI barriers relate to project management, resources, and sponsorship while the Australian barriers are concerned with organisational politics and lack of support.