Together with many success stories, promises such as the increase in production speed and the improvement in stakeholders’ collaboration have contributed to making agile a transformation in the software industry in which many companies want to take part. However, driven either by a natural and expected evolution or by contextual factors that challenge the adoption of agile methods as prescribed by their creator(s), software processes in practice mutate into hybrids over time. Are these still agile? In this article, we investigate the question: what makes a software development method agile? We present an empirical study grounded in a large-scale international survey that aims to identify software development methods and practices that improve or tame agility. Based on 556 data points, we analyze the perceived degree of agility in the implementation of standard project disciplines and its relation to used development methods and practices. Our findings suggest that only a small number of participants operate their projects in a purely traditional or agile manner (under 15 percent). That said, most project disciplines and most practices show a clear trend towards increasing degrees of agility. Compared to the methods used to develop software, the selection of practices has a stronger effect on the degree of agility of a given discipline. Finally, there are no methods or practices that explicitly guarantee or prevent agility. We conclude that agility cannot be defined solely at the process level. Additional factors need to be taken into account when trying to implement or improve agility in a software company. Finally, we discuss the field of software process-related research in the light of our findings and present a roadmap for future research.

Background: Agile methods are no longer restricted to small projects and co-located teams. The last decade has seen the spread of agile into large scale, distributed and regulated domains. Many case studies show successful agile adoption in GSD, however, taken as a whole, it remains unclear how widespread this trend is, and what form the agile adoption takes in a global software development (GSD) setting. Aims: Our objective is to gain a deeper understanding of how organisations adopt agile development methods in distributed settings. Specifically we aim to plot the current development process landscape in GSD. Method: We analyse industrial survey data from 33 different countries collected as part of the HELENA project that explored the wider use of hybrid development approaches in software development. We extract and analyse the results of 263 surveys completed by participants involved in globally distributed projects. Results: In our sample, 72% of globally distributed projects implement a mix of both agile and traditional approaches (termed `hybrid'). 25% of GSD projects are predominantly agile, with only very few (2%) opting for traditional approaches. GSD projects that used only agile methods tended to be very large. Conclusions: Globally Distributed Software Development (and project size) is not a barrier to adopting agile practices. Yet, to facilitate project coordination and general project management, many adopt traditional approaches, resulting in a hybrid approach that follows defined rules.

The adoption, scaling and tailoring of agile methods depends on several factors, such as the size of the software development organization, business goals, and operative model. The Scaled Agile Framework (SAFe) was developed to support organizations in scaling agile practices across the enterprise.

Abstract Over the past decade, there have been increasing expectations and pressures placed on health care providers to deliver more efficient, quality, and safe health care services. As a result, this shifts the balance between supply‐and‐demand of health care services. It also brings about new challenges for health care professionals' capabilities to deliver safe and quality care in a timely manner. There are significant opportunities to exploit information and communications technology and transform how health care service is provided. Connected Health is one such transformation for health care management and changes in health care practice. However, the field of Connected Health is still in its infancy. This Special Issue in Software Engineering for Connected Health begins to address this and presents 5 quality contributions to demonstrate how software engineering research plays an important role in Connected Health research. These contributions also identify the limitations of the existing theories and to develop new or revised theories of Software Engineering for Connected Health.

Healthcare demands are making it harder to deliver timely and safe quality care. However, connected health solutions can support this. This Journal First session presents three papers which discuss the role of software engineering in connected health.

In this paper, we discuss how IBM is working with Lero -- the Irish Software Research Centre and the Ireland Smart Aging Exchange. The proposed project will observe, analyse and coordinate Smarter Care models as they apply to active ageing and healthy living, building on models taken from Connected Health. We consider these as socio-technical models, extending from the older person's home and family into wider society. They can and will include healthcare models, but will also include further elements such as social interaction, exercise, intellectual requirements and personal assistance.

Global software development (GSD) is increasingly the norm. As firms expand into new markets overseas, acquire companies in different countries, and recruit talented developers in new locations, projects become distributed by necessity. As projects become increasingly distributed, and include external participants such as outsourcing vendors, conventional top-down management oversight and control becomes more difficult. How can organizations ensure that the activities of all parties involved are aligned with the strategic objectives and values of a software development undertaking? The Global Teaming Model is a framework that specifies practices and recommendations for Global Software Development. As such, it serves as a means to organize GSD practices relevant to Software Development Governance. We conducted a case study of a small team engaged in Global Software Development, identifying governance shortcomings. Then, we used the Global Teaming Model to identify governance practices that would address those shortcomings. We identified several aspects of the team's interactions with other teams in the company that would be improved by recommendations from the Global Teaming Governance Model. The Global Teaming Model provides a blueprint for Software Development Governance that organizations seeking to globalize their current development projects in a controlled way can use to implement good Software Development Governance.

There was a time when researching software processes meant just that – we were interested in making sure that the process for software development was effective. From a software process perspective, we did not really have to worry about competition, the business nor the domain in which our software was used – because these were not seen as affecting the software processes through which the software was developed. But, things have changed! Software has become more ubiquitous. Software is used in products that are governed by regulation. Software is being developed in organizations that heretofore did not consider themselves software companies – such as automotive and medical device companies. Software is fundamental to many businesses that would not continue to survive if their software is not running effectively. In addition, modern software systems consist of a complex mix of products and services, some are decades old, and some are merely emerging. They may easily suffer from symptoms of aging and need to be continuously adapted to cope with changing requirements and environments. The sources of such changes may be new customers, intense competition, changing organizational structures and regulatory frameworks, changing interacting systems, bug fixing, software degradation and erosion, emerging opportunities and risks in the business environment, as well as emerging software technologies and platforms. In order to overcome or avoid the negative effects of software aging, we have to place change and evolution at the center of the software development and maintenance processes. Evolving process drivers are not necessarily software driven. If we consider drivers in (i) these will be evolved through software engineering, either being developed in industry or by researchers. Drivers in (ii) may possibly evolve through software engineering, and the world of software engineering will have an input. But, often it is the business case that takes priority. And, drivers in (iii) are determined by the business in which we work 5. In these cases, we, as software engineers must consider the business domain to establish what software processes are of interest and will be required to use particular processes 6. However, developing software engineering processes on a one-off basis and then letting them be used ad infinitum without any further changes will not work. Change in the evolving process drivers cause software engineering processes to evolve. In addition, these evolving process drivers can be critical, particularly as the software engineering process increasingly contributes to the company's profitability, be that a direct or indirect contribution. The latest trends of developing and maintaining emerging and evolving software systems also leads to new opportunities and challenges regarding the development processes, including, but not limited to, process evolution, scalability, and process verification and validation. The research presented in the International Conference on Software and Systems Process contributes to this evolution. International Conference on Software and Systems Process is also playing a role in answering these questions. The three papers chosen for this special issue all have an industry focus. It is through publishing such papers that we can bridge the industry-research gap, ensuring that our research will have an impact, not only through our teaching and graduate programs but also by having a direct effect on the improvement of processes within industry. During the evolution history of this conference series, from 1984 to 1996, the International Software Process Workshops (SPW) attracted many academic researchers and industrial practitioners. Then came the International Conference on the Software Process, (ICSP, from 1991 until 1996), the International Workshop on Software Process Simulation and Modeling (from 1998 until 2006), and the SPW (in 2005 and 2006). International Workshop on Software Process Simulation and Modeling and SPW were held together in 2006 and merged in 2007 to form the new International Conference on Software Process. In 2009, the third ICSP conference was held in Vancouver, Canada, on May 16–17, and was co-located with ICSE 2009 (the International Conference on Software Engineering). The ICSSP (International Conference on Software and System Process) conferences continue the successful ICSP conference series, while broadening ICSP's scope of software development processes to system development and explicitly including processes of other domains such as health care, business, and manufacturing. By sharing process development theories and practices from such domains, ICSSP 2014 aimed at investigating novel solutions to today's software and systems process challenges. The theme of ICSSP 2014 was ‘Processes for Emerging and Evolving Software Systems’. There were 55 submissions (including 35 full papers and 20 short papers) to the conference that were received from 18 countries and regions including Australia, Austria, Brazil, Canada, China, Estonia, Denmark, France, Germany, Ireland, Italy, Japan, Netherlands, Portugal, Russian Federation, Sweden, United Kingdom, and United States of America. After a rigorous review process, 23 papers were accepted for the proceedings of the ICSSP 2014 including 12 full papers and 11 short papers. Following the conference, the editors ranked the accepted full papers based on their reviews and sent invitations to authors of five papers to expand and submit their papers for consideration in the special issue. Papers were submitted, peer reviewed, and revised. Based on the reviews, the Guest Editors selected four out of five papers to be included in this special issue of the Journal of Software Evolution and Process. We have also included a paper from keynote speaker, Prof K. Ryan from Lero. In an extension of his talk at ICSSP 2014, he discusses the importance of changing processes because of the changing world of software. He specifically discusses how specialization, industrialization, globalization, and Agile methods have disrupted software development and presents examples of how software process research has evolved new methods to cope with these changes. Software process lines provide a systematic approach to develop and manage software processes. It defines a reference process containing general process assets, whereas a well-defined customization approach allows process engineers to create new process variants. Variability operations are an instrument to realize flexibility by explicitly declaring required modifications, which are applied to create a procedurally generated company-specific process. However, little is known about which variability operations are suitable in practice. M. Kuhrmann, D. Méndez Fernández and T. Ternité, in their paper ‘On the Use of Variability Operations in the V-Modell XT Software Process Line’, study the feasibility of variability operations to support the development of software process lines in the context of the V-Modell XT. They provide an initial catalog of variability operations as an improvement proposal for other process models. The identified variability operations allow for systematically modifying the content of process model elements and the process documentation, and they allow for altering the structure of a process model and its description. High-maturity software development processes, such as the Team Software Process and the accompanying Personal Software Process, can generate significant amounts of data that can be periodically analyzed to identify performance problems, determine their root causes and devise improvement actions. However, there is a lack of tool support for automating that type of analysis and hence diminish the manual effort and expert knowledge required. M. Raza and J. P. Faria, in their paper ‘A Model for Analyzing Performance Problems and Root Causes in the Personal Software Process’, propose a comprehensive performance model, addressing time estimation accuracy, quality, and productivity, to enable the automated (tool based) analysis of performance data produced by Personal Software Process developers, namely, identify, and rank performance problems and their root causes. Software test processes are complex and costly. To reduce testing effort without compromising effectiveness and product quality, automation of test activities has been adopted as a popular approach in software industry. However, because test automation usually requires substantial upfront investments, automation is not always more cost-effective than manual testing. V. Garousi and D. Pfahl, in their paper ‘When to Automate Software Testing? A Decision-Support Approach Based on Process Simulation’, investigate how the simulation model using the System Dynamics modeling technique can help decision-makers decide whether and to what degree the company should automate their test processes. Workflow temporal verification guarantees on-time completion which is one of the most important quality of service dimensions for business processes running in the cloud. However, as today's business systems often need to handle a large number of concurrent customer requests, conventional response time based process monitoring strategies conducted in a one by one fashion cannot be applied efficiently to a large batch of parallel processes because of significant time overhead. To address this problem, X. Liu, D. Wang, D. Yuan, F. Wang, Y/ Yang, in their paper ‘Workflow Temporal Verification for Monitoring ParallelBusiness Processes’, proposes a quality of service-aware throughput based checkpoint selection strategy, which can dynamically select a small number of checkpoints along the system timeline to facilitate the temporal verification of throughput constraints and achieve the target on-time completion rate, based on a novel runtime throughput consistency model. In conclusion, we would like to thank all the authors and reviewers of this special issue. We also would like to thank the ICSSP Steering Committee: Barry Boehm, Ross Jeffrey, Mingshu Li, Leon Osterweil, and David Raffo for their support and help with the conference. We hope you enjoy reading the papers and that, within industry, this research can be useful.

Over the last decade, an increasing number of organizations have started software development in a globally distributed environment. One of the major challenges is that many organizations endorse the process of global software development without testing their management readiness for the globally distributed development activity. This includes work distribution through task allocation in the globally distributed development environment. The objective of this research paper is to identify factors that influence task allocation in global software development through carrying out a systematic literature review. We used customized search terms, derived from our research question, to identify literature on work distribution and task allocation in a global context. We identified criteria such as site technical expertise, time zone difference, resource cost, task dependency, vendor reliability, task size and vendor maturity level as key task allocation factors in globally distributed software projects. Based on the systematic literature review results, we suggest that there is a need to develop work distribution strategies and standards through global task allocation to help software development organizations in achieving the true potential of global software development at lower development costs and shorter time-to-market.

After more than a decade of research in Global Software Engineering (GSE), organisations have a wealth of practices that they can draw on to support them in their global development activities. However, practitioners are now asking, "What is the current status of my GSE practices?", "How prepared is my company for GSE?", "What practices need improving?" We aim to give practitioners the answers they need by giving them a snapshot of their current GSE process strengths and weaknesses that can act as a guide for future software process improvement activities. We do this through our lightweight Global Teaming Assessment (GTA) based on 70 recommended GSE practices which we piloted in a small company.

A growing number of companies are discovering that their software development processes must be in compliance with some form of regulation. This is particularly so when it comes to safety-critical or business-critical systems such as Automotive Software, Robotics, Medical Devices or Finan- cial Management systems. These regulations aect the soft- ware development process itself in various forms. Further- more, much attention is being given to ways of improving the eciency of businesses, for example, by adopting lean principles. This raises the question for how to adopt lean principles for software development within a regulated envi- ronment? This poster presents the results of our empirical research into lean and regulated software development. Built from a combination of data sources, we have developed a conceptual framework comprising ve primary components. In addition the relationships they have with both the central focus of the framework (the situated software development practices) and with each other are indicated.

To overcome shortcomings associated with software process improvement (SPI), we previously recommended that process engineers focus on the artifacts to be developed in SPI projects. These artifacts should define desired outcomes, rather than specific methods. During this prior research, we developed a model for Artifact-based Software Process Improvement & Management (ArSPI). We are now carrying out studies to confirm our claims that ArSPI will provide benefits such as quality assurance. In this paper, we report on an experimental setting in which we developed and analyzed a strategy to use artifact models to direct process model improvement. We analyzed a process specification, the realized model, and the generated electronic process guide. We used ArSPI v0.9 as our process model and the Capability Maturity Model Integration (CMMI) as an external reference to provide a set of overall improvement goals. We propose an effective approach to analyze and improve a process model. In addition, the analysis revealed issues with ArSPI realization, which will be corrected in the next major release.

Context: More than a decade of empirical research into global software development has yielded a wealth of solutions to recurring problems. The Global Teaming Model is one example, organizing extensive empirical research into a cohesive process model for managing global software development projects. Problem: evidence shows that empirical research does not reach practitioners: software project managers do not read academic publications. Thus research results need to be cast in a form that is accessible to practitioners. Approach: We employ a two-pronged approach to address this problem. First, we translate research results into software process patterns, that describe a specific software development problem and an empirically derived and validated solution. Second, we enter the patterns into a knowledge based system that recommends patterns applicable to a software development project. Result: We used this approach to create a decision support system based on the Global Teaming Model. The result makes the sixty specific practices in the Global Teaming Model immediately accessible to managers and developers involved in Global Software Development. Also, the patternization of Global Teaming Model practices proved to be an efficient, low-overhead approach to translating research results into a practitioner-friendly format. Conclusion: The combination of patterns and knowledge-based decision support promises to bridge the research-practice divide by making research results more accessible to those who might benefit from them.

There was a time when researching software processes meant just that – we were interested in making sure that the process for software development was effective. We did not really have to worry about the domains in which our software was used – well, maybe that was up to the requirements engineers or even those who were interested in usability, but it did not really affect the software processes through which the software was developed. But, things have changed! Software has become more ubiquitous. Software is used in products that are governed by regulation. Software is being developed in organisations that heretofore did not consider themselves software companies – such as automotive and medical device companies. As the manner in which software is being used has changed, so too must the processes by which software is developed. This paper presents the position that software processes can no longer ignore the domain – they have to change to ensure that software can be used wherever it is needed.

As an approach to develop suitable development processes for software projects, Software Process Selection, Tailoring and Composition (SP-STC) attract lots of attention from both industry and academia. However, without effective guidelines, how to do SP-STC often remains a mystery. This special panel aims to 1) initiate a discussion on the current research status of SP-STC, 2) identify main challenges of SP-STC and possible solutions, and 3) work out a research agenda for future work.

Twelve years ago a group of practitioners and researchers came together to try to solve problems relating specifically to Global Software Engineering (GSE) practice. This paper aims to assess whether the many hundreds of GSE research papers written over this period have had an impact on practice. We conducted semi-structured interviews with senior managers and project managers from ten companies, four of which are large multinationals (three in Fortune 100), four are medium sized enterprises, and two are small startups. GSE research is perceived as useful by industry with all participants stating that studying the subject would improve GSE performance, but all were unanimous in saying they did not read articles on GSE. Practitioners go to books, blogs, colleagues, forums, experience reports of 1-2 pages in length, or depend on their own experience to solve problems in GSE. Controversially, many didn't see GSE as separate from general project management. Practitioners don't want frameworks, they want patterns of context specific help. While dissemination techniques need to be improved, that is not sufficient. Experience-based advice is just as important.

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.

Globally distributed software development teams face problems with software development life cycle phases, as the distributed nature of each of these phases make it even more challenging to communicate between the stakeholders. Global distance can give rise to incomplete requirements handovers which make the situation more difficult. It is important to address this issue as the end product is likely to deliver less business value when such problems arise. In this research, we propose a process to facilitate non-verbal communication among globally distributed requirements engineering teams. The focus of this research is the situation that occurs after requirements are handed to another site. Our proposed process endeavors to ensure that incomplete and conflicting requirements are identified and mitigated.

SUMMARY Software product lines (SPL) and Agile practices have emerged as new paradigms for developing software. Both approaches share common goals; such as improving productivity, reducing time to market, decreasing development costs and increasing customer satisfaction. These common goals provide the motivation for this research. We believe that integrating Agile practices into SPL can bring a balance between agility and formalism. However, there has been a little research on such integration. We have been researching the potential of integrating Agile approaches in one of the key SPL process areas, product derivation (PD). In this paper, we present an outline of our Agile process model for PD that was developed through industry‐based case study research. Copyright © 2010 John Wiley & Sons, Ltd.

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.

Software Engineering graduates are expected to enter the workforce with both technical and soft skills. In addition, software quality is a topic that is becoming increasingly important both because of educational and industry requirements. Software engineering lecturers need to bring their research into the classroom. Bringing all of these together can pose the lecturer with a dilemma that is not easily solvable. This paper presents how problem-based learning, a pedagogical methodology that is popular in medicine and other disciplines, can be used to accomplish these goals in a single course module. It describes a research project which analyses the implementation of problem-based learning within a M. Sc. Software Engineering Quality Module, and evaluates the outcomes against published expectations.

Service Based Systems (SBSs) are composed of loosely coupled services. Different stakeholders in these systems, e.g. service providers, service consumers, and business decision makers, have different types of concerns which may be dissimilar or inconsistent. Service Level Agreements (SLAs) play a major role in ensuring the quality of SBSs. They stipulate the availability, reliability, and quality levels required for an effective interaction between service providers and consumers. It has been noticed that because of having conflicting priorities and concerns, conflicts arise between service providers and service consumers while negotiating over the functionality of potential services. Since these stakeholders are involved with different phases the life cycle, it is really important to take into consideration these life cycle phases for proposing any kind of SLA negotiation methodology. In this research, we propose a stakeholder negotiation strategy for Service Level Agreements, which is based on prioritizing stakeholder concerns based on their frequency at each phase of the SBS development life cycle. We make use of a Collaxa BPEL Orchestration Server Loan service example to demonstrate the applicability of the proposed approach. In addition, we simulate the negotiation priority values to predict their potential impact on the cost of the SLA negotiation.

In this paper, we present the Global Teaming Model (GTM), which is empirically grounded, and outlines practices that managers need to consider when managing virtual teams. We explain how the model can be adapted to specific areas of software development, and use architectural knowledge management (AKM) as our exemplar. We focus on specific practices relating to how teams collaborate and share essential architectural knowledge across multiple sites. Through a review of the literature, we develop an in-depth view of recommended practices associated with AKM in a global environment. We then consider how we can incorporate these AKM practices into our Global Teaming model to ensure managers are given the necessary support. Our contribution to research therefore is to present AKM practices within the context of all other Global Software Development processes.

Cultural diversity is assumed to be a fundamental issue in global software development. Research carried out to date has raised concerns over how to manage cultural differences in global software development. Our empirical research in India, a major outsourcing destination, has helped us investigate this complex issue of global software development. A triangulated study based on a questionnaire, telephonic interviews and structured face-to-face interviews with 15 Project Managers and Senior Executives has revealed how they cope with the demands of cultural differences imposed by a geographically distributed environment. This research study brings forward various techniques initiated by these project managers to deal with cultural differences that exist within geographically distributed software development teams. We also discuss different strategies and make a case to explain how to build on and take advantage of cultural differences that exist in global software development.

In the late 1990s the Software Engineering community recognized that there was a problem with delivering global software projects to a high quality in an efficient manner. As a consequence, researchers, in the now 'Global Software Engineering Research community', carried out significant studies into GSE problems. But, did we really find what we expected? Did we expect that project delays were due solely to technical software engineering problems? Did we really think that software engineering techniques could resolve all GSE problems? Maybe that is what we expected but that is not what we found. Of course Software Engineering techniques can solve some of the problems! However, the reality is that many of the issues we now discuss within the GSE community are social and socio-technical. We talk about culture and communication. We consider gender issues. Project management is high on our agenda. And what this portrays is the interdisciplinary nature of GSE research.

There is a need to address the significant gap in our ability to measure and monitor the Key Performance Indicators (KPIs) across service networks. The unprecedented growth in service-based business processes over a short period of time has underscored the need for understanding the mechanisms and theorising the business models and business process management adopted across many organisations today. This research presents a survey of the literature and argues that the inability of current Business Process Management (BPM) techniques to visualise and monitor web-enabled business processes prevents us from transforming information on network activity and infrastructures. This inhibits managers in anticipating change and adapting to more agile business practices in service science. Thus, this research-in-progress sets out to propose the need to develop a framework to enhance a manager's ability to monitor key performance indicators (KPIs) while improving business process restructuring practices through social network analysis (SNA).

Software engineering lecturers are faced with the teaching of concepts which sometimes are not easy for inexperienced students to understand. Therefore, it can be useful to consider and use non-traditional teaching methods which can improve studentspsila learning. In this paper, we discuss problem-based learning and how its use can improve studentspsila understanding of concepts. We present factors which should exist in 'pure' problem-based learning. We then describe how one of the authors used problem-based learning in a class who were required to understand information flows through software engineering diagramming techniques, with the ultimate view to being able to analyze and design computerized information systems. This problem-based learning class was observed and analyzed by the second author. The analysis presented focuses on the problem-based learning factors, how they were implemented in class, and the strengths and weaknesses of the use of problem-based learning in this way. In conclusion, the authors discuss how the teaching could be improved through modifying the teaching method for a future class in which problem-based learning will be used. This modification is expected to enhance the studentspsila learning and their experience.

In global software engineering research, there have been many studies carried out from the perspective of the company who is outsourcing software development. However, very few studies focus on the companies to whom the software development is being outsourced. In this paper, we highlight India as a major outsourcing destination and present experience from companies that manage outsourced software development. In carrying out this activity, Indian software companies have confronted various issues which are local, remote, internal and external and for which solutions have been instigated. This paper presents research carried out within Indian software companies in which we investigated issues faced when implementing global software development and the solutions used by these companies. We present these solutions so that they can be followed by other outsourcing destinations thus enabling them to operate successfully across geographical, national and international cultural boundaries.

In this paper we consider the importance of explicit knowledge management, taking into account the growth of global software engineering and the importance of corporate knowledge. We conclude by suggesting specific areas of research which should be considered important for the implementation of knowledge management within global software engineering environments

Distributed software development has become the norm for the software industry today. As a result many organizations are leveraging the expertise of their existing staff by establishing virtual teams. Here we outline the results from three independent case studies undertaken over a period of eight years. The first study considered the operation of virtual teams whose members were situated in two locations in the same country. The second investigated why U.S. and Irish team members who worked very successfully while collocated, experienced serious problems when operating in virtual teams. The third focused on virtual testing teams with members based in Ireland and Malaysia. The Irish staff had extensive experience of having projects offshored to them and were now responsible for offshoring part of their work. The results from each case study highlighted the importance and impact fear played and the consequences this had for the success of the respective strategies.

In a globalised world economy, small and medium-sized companies (SMEs) are now entering the global software engineering (GSE) arena, but their involvement is more often opportunistic than carefully planned. Considered until a few years ago a major destination for outsourcing/offshoring, Ireland is now moving toward a dual role. Small Irish companies are becoming aware of the opportunities provided by offshoring their software development activities and are beginning to harvest the benefits. Two case studies were undertaken in two small Irish companies that have offshored their software development to subsidiaries in Romania and India respectively. Building on Lings' [1] reference model for distributed development, the current paper aims at illustrating particular ways of putting these strategies into practice in the case of small companies by relaying on people who can bridge the two cultures. Our paper demonstrates that, once particular strategies are implemented, small companies can also benefit from offshoring.

The need for software is increasingly growing in the automotive industry. Software development projects are, however, often troubled by time and budget overruns, resulting in systems that do not fulfill customer requirements. Both research and industry lack strategies to combine reducing the long software development lifecycles (as required by time-to-market demands) with increasing the quality of the software developed. Software process improvement (SPI) provides the first step in the move towards software quality, and assessments are a vital part of this process. Unfortunately, software process assessments are often expensive and time consuming. Additionally, they often provide companies with a long list of issues without providing realistic suggestions. The goal of this paper is to describe a new low-overhead assessment method that has been designed specifically for small-to-medium-sized (SMEs) organisations wishing to be automotive software suppliers. This assessment method integrates the structured-ness of the plan-driven SPI models of Capability Maturity Model Integration (CMMI) and Automotive SPICE with the flexibleness of agile practices.

Discussions of software engineering education tend to focus on the needs of industry and the preparation of graduates for professional careers. This is understandable, and may even be appropriate, but what about those who hope to go on to do research in software engineering - how well are we catering for them?

Given the requirement for software engineering graduates to operate in Global Software Development (GSD) environments, educators need to develop teaching methods to enhance and instill GSD knowledge in their students. In this paper, we discuss two projects that provided students with a first-hand learning experience of working within GSD teams. One project was with Siemens Corporate Research, whose focus was to shadow the development of a real-life GSD project. The second project, whose focus was virtual team software testing, was carried out in collaboration with Ball State University. In parallel with these projects we undertook qualitative research during which we analyzed students' own written reflections and face-to-face interviews that focused on their learning experiences in these contexts. We identified three specific forms of learning which had taken place: pedagogical, pragmatic and the acquisition of specific globally distributed knowledge. Our findings confirm that mimicking real work settings has educational benefits for problem-based learning environments.

When implementing software development in a global environment, a popular strategy is the establishment of virtual teams. The objective of this paper is to examine the effective project management of this type of team. In the virtual team environment problems arise due to the collaborative nature of software development and the impact distance introduces. Distance specifically impacts coordination, visibility, communication and cooperation within a virtual team. In these circumstances the project management of a virtual team must be carried out in a different manner to that of a team in a single-site location. Results from this research highlighted six specific project management related areas that need to be addressed to facilitate successful virtual team operation. Organizational structure, risk management, infrastructure, process, conflict management and team structure and organization. Additional related areas are the sustained support of senior management and the provision of effective infrastructure

The Global Studio Project integrated the work of Software Engineering students spread across four countries into a single project and represented, for most of the students, their first major "real-world" development experience. Interviews indicated that the major areas of learning were informal skills that included learning to establish and work effectively within a team, learning how to react quickly to frequent changes in requirements, architecture and organization, and learning to manage and optimize communications. Since all these skills require rapid reaction to unpredictable factors, we view them as improvisation and discuss the role of experiential education in facilitating improvisation.