Previous studies suggest that motivation is a critical factor in developer productivity and project outcome, i.e., software project failures are significantly associated with low motivation of software teams. Surveys with software engineers also indicate that culture can affect software development team motivation through differences in developers' motivational factors. In this study, we conduct a survey with 15 Finnish software engineers and 21 non-Finnish software engineers who live in Finland to investigate 1) the relationship between team motivation and project outcome, and 2) the factors that motivate Finnish software engineers. We compare the motivational factors found from the Finnish data with those identified in prior research with developers from four different countries. An analysis of the data from our 36 subjects indicates that project outcome is not associated with team motivation in Finland though this result contradicts prior research. There is a single motivational factor, “team work” that appears to be culturally independent. Unique team motivational factors for Finnish software engineers are found to be “the authority of project manager” and “the vision of project manager”. Our results indicate that cultural differences affect team motivation and that project managers need to consider these when working in a global environment.

Context: There has been an increase in research into global software development (GSD) and in the number of systematic literature reviews (SLRs) addressing this topic. Objective: The aim of this research is to catalogue GSD SLRs in order to identify the topics covered, the active researchers, the publication vehicles, and to assess the quality of the SLRs identified. Method: We performed a broad automated search to find SLRs dealing with GSD. We differentiate between SLR studies and papers reporting those studies. Data relating to each of the following was extracted and synthesized from each study: authors and their affiliation at the time of publication, the journal or conference in which the paper was published, the quality of each study and the main GSD study topic. Results: Twenty-four GSD SLR studies and 37 papers reporting those studies were identified. Major GSD topics covered include: (1) organizational environment, (2) project execution, and (3) project planning and control. The main research groups are based in Brazil (17), Ireland (8), and Sweden (7). Conclusions: GSD SLR studies are most frequently reported in the International Conference on Global Software Engineering and IEEE Software; the two most popular topics for research are risk factors due to the organizational environment and the development process. The most active researchers are based in Brazil. The quality of the SLR studies has not changed over time.

Global Software Engineering (GSE) has been a topic on the software engineering research agenda for more than 10 years. Researchers have investigated many of the hurdles and subsequently presented solutions to the software industry. We, the guest editors, have spent much of our time in this space. We have obtained a deeper understanding of the issues faced by software engineers in a global environment and have been involved in the development of solutions that are now being used in the industry. It is interesting to note the patterns of GSE research—where it has come from and where it is going. When the international GSE community commenced our research into GSE, we did so with an expectation that the problems that were being experienced were because of issues that belonged to software engineering. This, we discovered, was not the case. In fact, what we found was that many of the problems were social issues. We noted that global distance—temporal, linguistic, cultural and geographical—is important when setting up GSE teams. We discovered that teams did not know how to communicate with each other due to linguistic differences and misuse of communication tools. We realized that there was a need to discuss methods of collaboration ‘up front’. Employees in the outsourced companies were concerned about their job security which also caused project issues. Cultural distance, which results in a misunderstanding of how team members from other cultures work, affects the output. Some, but not many of the problems, were hardcore software engineering issues. None of this devalues the research which has been carried out by GSE researchers—in fact, it has provided us with a much needed understanding of what exactly is happening within the industry, thus giving us a strong basis for moving forward. However, we believe that the time has come for GSE researchers to shift focus, moving away from problem-based research to developing and presenting solutions to the issues that exist. We should be using software engineering research to support the development of solutions to the problems we have discovered. We should be moving, as a body of researchers, in this direction. Some such research has commenced—but this is sporadic and many GSE publications are still problem-based rather than solution-based. Of course, new problems may arise, but have we not found many issues for which solutions need to be found? Can we develop tools to support communication problems? Is there architecture knowledge that can be implemented to improve GSE? Should specific software processes be developed for use in the global environment? Are there requirements engineering techniques that could be used to improve the current situation? Do we understand the solutions implemented in both the outsourcing and insourcing sites? There are many interesting research questions that remain to be answered—GSE is not solved yet. What we are urging is that the software engineering researchers who are interested in ‘global’ seriously look at how we can bring software engineering solutions to the multitude of problems which still exist in the GSE environment. In parallel, and we have seen some evidence of this happening in the recent years, software engineering researchers should be collaborating with those from other disciplines, such as sociology and organizational management. This will ensure that when we are researching the ‘socio’ in the ‘socio-tech’ of GSE, we are bringing in those who are trained in such research. We believe that these directions are important for the growth and usefulness of GSE research. This special issue has been compiled following the 4th International Conference on Global Software Engineering, ICGSE 2009 which was hosted by Lero—the Irish Software Engineering Research Centre at the University of Limerick from 12–16 July 2009. In reading the submitted papers we have noticed a trend towards GSE solutions—but this is not yet as strong as we might like! Researchers at the conference presented papers on many topics including: trust and culture, collaboration, architecture and design, on- and off-shoring, communications, and processes. Following peer review to select conference papers followed by further reviews for this special issue, we chose the six papers published in this special issue. The papers discuss a variety of topics from which we hope that you, the reader, can learn more about GSE research—both the problems and the solutions. In his paper on ‘Propinquity in global software engineering: examining perceived distance in globally distributed project teams’, Prikladnicki is interested in examining the phenomenon of ‘feeling distant from geographically distributed people’. He proposes a perceived distance index that contains the factors culture, trust, communication, time zone, distance, and context which should support project managers of distributed software teams and projects, helping them to identify the potential human factor-related risks early in the project. He evaluates this model in a study between project team members based in India and Brazil. In his discussion, Prikladnicki discusses the implications for practice and for research, as well as identifying the limitations to his model. Recognizing the importance of knowledge management (KM) practices within software development, Boden et al. discuss the importance of culture when implementing KM into global projects. Their paper ‘Knowledge sharing practices and the impact of cultural factors: reflections on two case studies of offshoring in SME?’ presents a discussion on KM in GSE and on cross-cultural aspects of GSE. They have analysed two global case studies: German–Russian and Irish–Romanian. Of note is that these are two inter-European cases, crossing the Western–Eastern European boundary—unlike many GSE case studies that are presented which focus on U.S.A./Western Europe—Far East (e.g. China, India). The authors have found that cultural factors are ‘rather intertwined with other complex issues’—going on to discuss some of these issues. They also discuss KM within the cases, thus giving the reader a greater insight into how culture and KM are interrelated. Quality is a consideration when implementing GSE within organizations. Cataldo and Nambiar examine this topic in their paper ‘The impact of geographic distribution and the nature of technical coupling on the quality of global software development projects’, where they present a multi-dimensional view of distribution following a study of 189 distributed development teams. Measuring quality as ‘the number of defects reported during integration and system testing’, they report results from logistic regressions. They present a number of conclusions—larger number of sites, higher temporal dispersion, and uneven distribution of developers and development effort are all more likely to result in lower quality/higher defects. Continuing on the theme of quality, ‘Quality indicators on global software development projects: does ‘getting to know you’ really matter?’ by Gotel et al., focuses on a study of student teams. This research project, across five institutions, four counties and seven distinct sites, studied students' knowledge of each other's countries and cultures and of their teammates. The project also included ‘activities designed to promote and assure software quality’. Thestudy concludes that getting to know other team members does indeed matter in a software development environment. Recent studies have identified that fear and lack of trust in GSE teams, particularly in relation to job security, have had a negative effect on the output. Piri et al. continue this theme in their paper ‘Fear and distrust in global software engineering projects’, in which they present results from 59 interviews in 8 GSD projects in 2 major software companies within Finland. Through detailed presentation of the interviews which they carried out, they analyse the consequences of fear and distrust between onsite and offsite software engineering groups. The final paper in this special issue, authored by Babar, is ‘A framework for groupware-supported software architecture evaluation process in global software development’. Following a description of the generic process for evaluating software architecture and a presentation of groupware system support, the author proposes a framework which will allow software architecture evaluation to proceed successfully within a GSE environment. He illustrates his proposal with an example and discusses the required groupware features which were identified during empirical studies, anecdotal evidence, and extensive discussions. The papers in this special issue offer new insights into GSE, and we hope that you enjoy reading them as much as we did. We anticipate that these results will be used in the future GSE research, and we wish our colleagues who are currently organizing ICGSE 2010 in Princeton, New Jersey, U.S.A., every success with the conference.

Requirements sometimes can turn out to be either incomplete or inconsistent. Factors contributing to this situation include the selection of the elicitation technique and other approaches used. Some approaches used for requirements gathering such as single elicitation approach, and their effects during requirements elicitation, can cause deficiency in many requirements elicitation methods. Our experimental study showed that when an interview technique is used, choice-based and integration-based approaches are far better than a single elicitation approach, as they provide an effective process for eliciting complete and correct requirements.

There is growing interest in applying agile practices in Global Software Development (GSD) projects. But project stakeholder distribution in GSD creates a number of challenges that make it difficult to use some agile practices. Moreover, little is known about what the key challenges or risks are, and how GSD project mangers deal with these risks while using agile practices. We conduct a Systematic Literature Review (SLR) following existing guidelines to identify primary papers that discuss the use of Scrum practices in GSD projects. We identify key challenges, due to global project distribution, that restrict the use of Scrum and explore the strategies used by project managers to deal with these challenges. Our findings are consolidated into a conceptual framework and we discuss various elements of this framework. This research is relevant to project managers who are seeking ways to use Scrum in their globally distributed projects.

B-SCP is a promising framework addressing alignment of IT with business strategy from a requirements engineering perspective. A problem with the B-SCP framework is that it is extremely difficult to track dependencies between requirements in a project of realistic complexity. We discuss how the RDF data model with OWL semantics, will greatly benefit an implementation using B-SCP. Our contribution is to extend B-SCP by describing an ontology data structure for representing the requirements and the complex rules which map them together. Seven Eleven-Japan is used as an exemplar to demonstrate improved productivity and consistency of B-SCP.

Organizations are increasingly outsourcing the development of strategic IT systems to external vendors. Because of the importance of such systems to a client organization, unaddressed risks that develop into serious problems may have a huge negative impact on the organization. There is much reported research on IT development and IT outsourcing risk, and risk management. However, research on risk in outsourced strategic IT system development, from the client perspective, have largely been ignored. We developed a risk framework for outsourced strategic IT development based on the literature. In this paper we review three reported cases of unsuccessful strategic IT system development that provide an initial validation of our outsourced risk framework. A number of risks critical to a client are identified. These risks fall into several categories associated with organizational environment, team, user, complexity, contract, requirements, planning and control, and execution. If critical outsourcing risks are clearly understood by a client organization then strategies for managing such risks can be implemented.

Without careful methodological guidance, case studies in software engineering are difficult to plan, design and execute. While there are a number of broad guidelines for case study research, there are none that specifically address the needs of a software engineer undertaking multiple case studies in an industrial setting. Through a synthesis of existing best practices in case study research, we provide a set of comprehensive guidelines for conducting multiple case studies in software engineering research. Our guidelines can assist software engineering researchers with all stages of multiple case study research, although in this paper we concentrate on the early phases, such as focusing the case study and detailed plan design. To date, three exploratory research projects found our guidelines very useful. We illustrate our guidelines with examples from one of these projects.

It has been suggested that there is more than one reason for a software development project to fail. However, most of the literature that discusses project failure tends to be rather general, supplying us with lists of risk and failure factors, and focusing on the negative business effects of the failure. Very little research has attempted an in-depth investigation of a number of failed projects to identify exactly what are the factors behind the failure. In this research we analyze data from 70 failed projects. This data provides us with practitionerspsila perspectives on 57 development and management factors for projects they considered were failures. Our results show that all projects we investigated suffered from numerous failure factors. For a single project the number of such factors ranges from 5 to 47. While there does not appear to be any overarching set of failure factors we discovered that all of the projects suffered from poor project management. Most projects additionally suffered from organizational factors outside the project managerpsilas control. We conclude with suggestions for minimizing the four most common failure factors.

Trust is considered one of the most important factors for successfully managing software outsourcing relationships. However, there is lack of research into factors that are considered important in establishing and maintaining trust between clients and vendors. The goal of this research is to gain an understanding of vendors’ perceptions of the importance of factors that are critical to the establishment and maintenance of trust in software outsourcing projects in Vietnam. We used a multiple case study methodology to guide our research and in-depth interviews to collect qualitative data. The participants of study were 12 Vietnamese software development practitioners drawn from 8 companies that have been developing software for off shore clients. Vendor companies identified that cultural understanding, creditability, capabilities, and personal visits are important factors in gaining the initial trust of a client, while cultural understanding, communication strategies, contract conformance, and timely delivery are vital factors in maintaining that trust. We also identify similarities and differences between Vietnamese and Indian practitioners’ views on factors affecting trust relationships.

Cost, schedule and quality are highly correlated factors in software development. They basically form three sides of the same triangle. Beyond a certain point (the "Quality is Free" point), it is difficult to increase the quality without increasing either cost or schedule or both for the software under development. As products and applications mature, users expect higher quality products. They want IT organizations to be responsible and accountable for the quality claims made by the product marketing teams. In the last couple decades, much software engineering research has focussed on standards, methodologies and techniques for improving software quality, measuring software quality and software quality assurance. Most of this research is focused on the internal/development view of quality. More recent studies done in conjunction with the marketing groups have made attempts to understand the customer view of quality. All of these different ongoing activities to understand quality from the various perspectives have made the field even more enriching and exciting. The Fourth Workshop on Software Quality aims to bring together academic, industrial and commercial communities interested in software quality topics to discuss the different technologies being defined and used in the software quality area.

Trust is considered one of the most important factors for successfully managing software outsourcing relationships. However, there is lack of research into understanding the factors that are considered important in establishing and maintaining trust between clients and vendors. The goal of this research is to gain an understanding of software outsourcing vendors' perceptions of the importance of factors that are critical to the establishment and maintenance of trust in software outsourcing projects in Vietnam. We used a multiple case study design to guide our research and in-depth interviews to collect qualitative data from 12 Vietnamese software development practitioners drawn from 8 companies that have been developing software for Far Eastern, European, and American clients. Vendor companies identified that cultural understanding, creditability, capabilities, and personal visits are important factors in gaining the initial trust of a client, while cultural understanding, communication strategies, contract conformance, and timely delivery are vital factors in maintaining that trust.

To develop software on time and within budget is not good enough if the software produced is full of defects. As the software market matures, users want to be assured of quality. They no longer accept claims made by the IT department at face value, but expect concrete demonstrations of quality. Software stakeholders are also demanding higher quality software than ever before. In recent years, much software engineering research has focussed on standards, methodologies and techniques for improving software quality, measuring software quality and software quality assurance. Most of this research is focused on an internal view of quality whereas few measures of the customer view of quality exist. The Third Workshop on Software Quality aims to bring together academic, industrial and commercial communities interested in software quality topics to discuss the different technologies being defined and used in the software quality area.

Jackson problem diagrams, goal modeling, and business process modeling (BPM) are employed in a requirements engineering approach that captures both business strategy and process requirements for e-business systems. As a means of linking abstract, high-level business requirements to low-level system requirements, we leverage the paradigm of projection in both problem diagrams and goal models simultaneously. We use Jackson context diagram to describe the business model domain context while goal modeling is used to represent both requirements and to describe the objectives of business strategy. Role activity diagrams are used to describe business processes in detail where needed. The feasibility of our approach is shown by a proof-of-concept case study.

Agile methods may produce software faster but we also need to know how they meet our quality requirements. In this paper we compare the waterfall model with agile processes to show how agile methods achieve software quality under time pressure and in an unstable requirements environment, i.e. we analyze agile software quality assurance. We present a detailed waterfall model showing its software quality support processes. We then show the quality practices that agile methods have integrated into their processes. This allows us to answer the question "can agile methods ensure quality even though they develop software faster and can handle unstable requirements?".

We survey software practitioners' perceptions of the prototyping and waterfall approaches and find that department size has a significant effect on their attitudes to the advantages and disadvantages of the approaches.Overall respondents from small departments prefer a prototyping approach, respondents from medium sized departments prefer a waterfall approach, while respondents from large departments are more aware of the benefits of both approaches.However, until a mature controlled software development process is in place all the benefits provided by these software development approaches are unlikely to be perceived.

A bottom-up approach to software size estimation is described. It first identifies factors affecting software size, thus obtaining size explanation equations, and then seeks suitable predictors based on those explanation factors which can be used for size estimation. The approach, or model, is bottom-up in that it sizes individual software components or modules first, and then obtains subsystem and system sizes by summing component sizes. Since components may have different purposes and characteristics, the model allows for the partitioning of system components into several different types, each component type having different size explanation and estimation equations. The partitioning is not fixed, but depends on the particular software development technology. The model is applied to several different software systems, including both business applications and systems programs.>

The relationship between software models and metrics is examined. The opportunities for CASE application measurement are seen to be much greater than for conventional development. CASE metrics requirements are also seen to be different in a number of important ways from conventional software metrics requirements. CASE application metrics are examined under the headings of process metrics and product metrics. CASE measurement issues and methods are considered together with some potential uses of CASE development measurements.>

Because Function Point Analysis (FPA) has now been in use for a decade, and in spite of its increasing uouularitv has met with some recent criticisms, it is time to &view how appropriate it still is for todav's technoloaies.A critical review of the FPA approach exam&es in part&lar the pioneering and continuing work of Albrecht and more recent work by Symons.Technological dependencies in FPA-type metrics are identified and a general model for deriving a new FPA-type metric for a new software technology is given.A model for the calibration of FPA-type metrics for new technologies in terms of a reference technology is also presented.Such calibration is essential for comparative productivity studies.The role of module estimation in exposing parts of the 'anatomy' of the FPA approach is investigated.The derivation and calibration models are applied to a significant case study in which a new FPA-type metric suited to a particular software development technology is derived, calibrated and compared with other published versions of FPA metrics.