Matthew Bass

Global software development at siemens: experience from nine projects

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.

On Coordination Mechanisms in Global Software Development

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.

Siemens Global Studio Project: Experiences Adopting an Integrated GSD Infrastructure

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 can 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

Collaboration in Global Software Projects at Siemens: An Experience Report

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.

Architectural Misalignment: An Experience Report

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.

A Coordination Risk Analysis Method for Multi-site Projects: Experience Report

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.

Integrating a software architecture-centric method into object-oriented analysis and design

The choice of methodology for the development of the architecture for software systems has a direct effect on the suitability of that architecture. If the development process is driven by the users functional requirements, we would expect the architecture to appropriately reflect those requirements. We would also expect other aspects not captured in the functional specification to be absent from the architecture. The same phenomenon is true in development approaches that stress the importance of systemic quality attributes or other non-functional requirements; those requirements are prominent in the resulting architecture, while other requirement types not stressed by the approach are absent. In other words, the final architecture reflects the focus of the development approach. An ideal approach, therefore, is one that incorporates all goals, expectations, and requirements: both business and technical. To accomplish this we have incorporated, into a single architectural development process, generalized Object-Oriented Analysis and Design (OOAD) methodologies with the software architecture-centric method, the Quality Attribute Workshop (QAW) and Attribute Driven Design (ADD). OOAD, while relatively intuitive, focuses heavily on functional requirements and has the benefit of semantic closeness to the problem domain making it an intuitive process with comprehendible results. Architecture-centric approaches, on the other hand, provide explicit and methodical guidance to an architect in creating systems with desirable qualities and goals. They provide minimal guidance in determining fine-grained architecture, however. The integrated approach described in this paper maximizes the benefits of the respective processes while eliminating their flaws and was applied in a eight university, global development research project with great success. A case study from that experiment is included here to demonstrate the method.

Monitoring GSD projects via shared mental models: a suggested approach

Team cognition research suggests that the degree to which teams have developed shared mental models is a significant factor in the performance of the team. Research in the software development domain has similar findings. This research is not, however, reflected in most commonly used project management practices. In geographically distributed software (GSD)development difficulty with team coordination is the norm. This paper looks at these issues, the research into team mental models, and suggests how project management practices may incorporate the findings to help address coordination issues in GSD.

Software Engineering Education in the New World: What Needs to Change?

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.

A survey of software related academic collaborations at siemens

As an employer of more than 30,000 software engineers, Siemens has a large financial stake in their software engineering practices. The direct influence that academia has on the software practices within Siemens, however, is relatively small. This paper looks at some of the industrial factors that come into play in industrial/academic collaborations, identifies the collaborative models used, and looks at lessons learned from these efforts.