A critical factor in work group coordination, communication has been studied extensively. Yet, we are missing objective evidence of the relationship between successful coordination outcome and communication structures. Using data from IBM's Jazztrade project, we study communication structures of development teams with high coordination needs. We conceptualize coordination outcome by the result of their code integration build processes (successful or failed) and study team communication structures with social network measures. Our results indicate that developer communication plays an important role in the quality of software integrations. Although we found that no individual measure could indicate whether a build will fail or succeed, we leveraged the combination of communication structure measures into a predictive model that indicates whether an integration will fail. When used for five project teams, our predictive model yielded recall values between 55% and 75%, and precision values between 50% to 76%.

Nowadays, distributed development is common in software development. Besides many advantages, research in the last decade has consistently found that distribution has a negative impact on collaboration in general, and communication and task completion time in particular. Adapted processes, practices and tools are demanded to overcome these challenges. We report on an empirical study of communication structures and delay, as well as task completion times in IBM's distributed development project Jazz. The Jazz project explicitly focuses on distributed collaboration and has adapted processes and tools to overcome known challenges. We explored the effect of distance on communication and task completion time and use social network analysis to obtain insights about the collaboration in the Jazz project. We discuss our findings in the light of existing literature on distributed collaboration and delays.

In global development projects, different modeling techniques are used to create and manage the requirements, analyze the problem domain, identify potential hazards and develop the system design. For each modeling technique, separate tools (e.g. UML case tool, requirements database, Word) are used. Each tool comes with its own meta-model, which hinders the interchange of models across tools and makes automated traceability and quality analysis across all models unmanageable. We propose the integration of different modeling techniques by adding new relationships. The integrated requirements model supports complete traceability across feature modeling, use case modeling, requirements and hazard analysis, detailed requirements and system design. We propose design rules and metrics for a formal and automated quality assurance, project monitoring and control. The model is implemented in a central repository, accessible from distributed sites. Synchronous online collaboration, asynchronous offline access and model-based configuration management is supported for the entire unified requirements model.

In global software projects, informal communication across sites is severely hampered, making it difficult to disseminate implicit knowledge. Participants have a partial view of the overall organization, do not have access to the complete rationale behind decisions, and when changes arise, participants from other sites are surprised. Consequently, issues that could be clarified almost immediately require days until the relevant stakeholders are identified, the issues are understood, and a resolution is agreed upon. We focus on the specific problem of externalizing issues with their context, stakeholders, and organizational roles in distributed settings. The challenge is to capture sufficient knowledge as a side effect of development, while structuring it for long-term use. We describe Sysiphus, a distributed environment providing a uniform framework for system models, collaboration artifacts, and organizational models. Sysiphus encourages participants to make communication and issues explicit in the context of system models and become aware of relevant stakeholders

Software engineering courses often use industrial modeling tools for their infrastructure, as it exposes students to the state-of-the practice and increases their awareness about the complexity of their craft. However, this approach has the risk of expending a disproportionate amount of effort on tools as opposed to teaching concepts. Moreover, industrial tools often do not include didactic concepts needed for education. In this paper, we discuss our experience with an integrated, rationale-based modeling tool in a variety of software engineering courses. By providing an integrated modeling environment, students use a single tool for requirements, system design, test planning, and collaboration. By attaching rationale to the models, students are encouraged to reflect on their work while instructors can monitor them and provide more insightful feedback

Architectural knowledge consists of architecture design as well as the design decisions, assumptions, context, and other factors that together determine why a particular solution is the way it is. Except for the architecture design part, most of the architectural knowledge usually remains hidden, tacit in the heads of the architects. We conjecture that an explicit representation of architectural knowledge is helpful for building and evolving systems. If we had a repository of architectural knowledge for a system, what would it ideally contain, how would we build it, and exploit it in practice? In this paper we describe a use case model for an architectural knowledge system.