Software Engineering, as a discipline has made significant progress towards becoming an engineering profession over the last 45 years. As evidence of this the 3rd version of the guide to the Software Engineering Body of Knowledge was recently released. Additionally there are reference curricula for undergraduate and graduate education in software engineering. During the past 45 years the state of the practice has made significant progress as well. Some of that progress is reflected in the SWEBOK and associated curriculum, but the software engineering practice in the segment of industry that produces internet scale systems is not well supported by the guide to the SWEBOK, reference curriculum, or current software engineering degree programs. This paper presents a study of the current state of the practice in software engineering organizations and compares the results with the core body of knowledge recommended by the software engineering reference curriculum.

It has been widely recognized that coordination amongst the people involved in developing a software intensive system is required for successful completion. Many projects, particularly those with team members separated by geographic distance, have an impeded ability to coordinate amongst some project members, which may cause a mismatch between the need of the project to coordinate and the ability to coordinate resulting in coordination break downs. This paper presents a coordination risk analysis method for determining the significant coordination mismatches before they become an issue and experiences applying this method to geographically distributed projects.

As a globally operating company with about 30,000 software engineers worldwide, Siemens has accumulated a wide variety of experiences in global development. Many individuals and organizations have adjusted their practices to deal with the challenges related to the geographic distribution of the development effort. From a corporate perspective, Siemens has accumulated a rich base of knowledge about global development and how to approach it successfully. The Siemens software initiative - a company-wide improvement program for software development at Siemens - has worked on collecting this widely-distributed knowledge and synthesizing it in a form accessible to the wider software development community. In this paper, the approach as well as key learnings in people and communication-related aspects of collaboration are summarized.

This tutorial describes a structured approach for determining the GSD related risks specific to a given project, selecting appropriate tactics for addressing these risks, and suggesting ways in which the level of risk can be monitored during the execution of the project.

The ability of an organization to successfully carry out its tasks depends on the appropriate combination of organizational structure, processes, and communication and coordination mechanisms. In this paper, we present four case studies that exemplify coordination breakdown problems in global software development. Our analysis showed those problems took place even in the presence of a collection of processes, organizational mechanisms and communication tools established to increases the ability of the teams to perform their tasks. Finally, we discuss possible solutions to overcome the identified problems.

It has been well documented that there is a correlation between the structure of an architecture and the organization that produces it. More concretely there is a correlation between task interdependencies and coordination among the people or teams realizing these tasks. The amount of coordination needed among teams is related to the nature of these task interdependencies. As the scale and complexity of organization and systems grow it is not uncommon to have factors such as geographic boundaries, organization boundaries, cultural differences, and so forth impede the ability of certain individuals or teams to coordinate effectively. While there is some understanding of the factors that impede the ability of teams to coordinate, the factors that cause task interdependence in software systems is less well understood. The current view is that it is the interactions across module boundaries (assuming a module is assigned as a task or work item to a single team) that cause task interdependence; we have found that this view is not sufficient. In this paper we present three cases where additional architectural mechanisms created task interdependencies that the organizations were unable to accommodate. We go on to discuss the implications of these findings and suggest future research activities.

This paper talks through the practices and infrastructure that was used on the experimental Global Studio Project (GSP). While the architecture activities are highlighted, related practices such as project management, requirements engineering and integration and test in a distributed environment will also be discussed as lessons learned.

Environments and processes in typical software development are not fully adapted to the needs of global software development (GSD). In particular, they do not have all of the capabilities necessary for cross-site collaboration. While research literature is rich with examples of individual practices and tools that an be used in this setting, there is a lack of examples illustrating how these tools and processes can be used in combination. We have augmented a set of tools and processes for GSD and applied them to an experimental project called the Global Studio Project (GSP). This paper describes the tools and processes developed, and insights gained from applying them to the GSP.

We report on the experiences of Siemens Corporation in nine globally-distributed software development projects. These projects represent a range of collaboration models, from co-development to outsourcing of components to outsourcing the software for an entire project. We report experience and lessons in issues of project management, division of labor, ongoing coordination of technical work, and communication. We include lessons learned, and conclude the paper with suggestions about important open research issues in this area.