Streamed Lines: Branching Patterns for Parallel Software Development

Copyright © 1998 by Brad Appleton, Stephen Berczuk, Ralph Cabrera, and Robert Orenstein.
Permission is granted to copy for the PLoP '98 conference.

Table of Contents
[printing/downloading instructions]
Send us your comments!

Introduction to SCM Patterns

The approach an organization takes to Software Configuration Management (SCM) can significantly affect the quality and timeliness with which a software product is developed. By SCM, we essentially mean the process of identifying, organizing, controlling, and tracking both the decomposition and recomposition of: software system structure, functionality, evolution, and teamwork. In short, SCM is the "glue" between software artifacts, features, changes, and team members; it forms the ties that bind them all together from concept to delivery and beyond. This paper presents some of the patterns from a pattern language for SCM which we began developing at ChiliPLoP'98.

Motivation for an SCM Pattern Language

There are many approaches to SCM, and the structures, policies, and processes work best when applied in the appropriate context. This context is determined by organizational and architectural decisions, as well as previously existing SCM policies. Our goal is to place SCM structures in the context of these other existing structures, making it easier to decide how to structure an SCM process which will be effective for your context.

These SCM structures may be described as "patterns": named nuggets of insight conveying battle-proven solutions to recurring problems, each of which balances a set of competing concerns (see [Appleton97]). SCM Patterns fit into a framework of Organizational Patterns which can be grouped as follows:

Organizational Patterns:
Patterns which define how the organization is structured. This includes patterns which describe the size of the team, management style, etc. (see [Beedle97] and [OrgPats]).

Architectural Patterns:
Patterns which define how the software is structured at a high level. Some examples of these sorts of patterns have been published in prior PLoP Proceedings ([Berczuk95] and [Berczuk96]) and in books such as [POSA].

Process Defining (forming) Patterns:
These SCM Patterns describe structures, such as the project directory hierarchy, which are set up near the beginning of a project.

Maintaining (preserving) Patterns:
These are SCM patterns which affect the day to day workings of the organization.

These categories of patterns are shown in the figure at right.

SCM pattern categories

The line between the Forming and Maintaining patterns may be blurry, but we feel the distinction is conceptually important to understand the architecture of the development process pattern language. Because of the strong relationship between the patterns in each category (for example, how you set up the directory tree affects the process you follow for checking files in and out) we shouldn't spend too much time looking at where a pattern fits, but rather focus on which patterns it follows from.

The patterns we are documenting should be applied with an understanding of the context in which the problem exists. The figure below shows the patterns we are working on, with their relationships in the language in bold face. Some of the other kinds of patterns have been published previously ([Berczuk97]). Others are in "patlet" form now.

Relationships Between SCM Patterns

SCM patterns in progress and their relationships

[back to the table of contents]

Send us your comments!