WorkShop Teamware: Solutions Guide: - Strategies for Deploying Configuring in Software Development Organizations

# Strategies for Deploying Configuring in Software Development Organizations |

After you decide how you want to use Sun WorkShop TeamWare to help manage your development process, you have to deploy that solution throughout your organization. It is a good idea to think about how you will deploy your solution even as you devise and implement it. This topic describes how a software development organization efficiently and effectively deployed its solution without disrupting release schedules.

## Scenario

A large software development company recently decided to use the TeamWare Configuring tool to help manage its software development process. The company has two products: voice recognition software and card reading software. The voice recognition project employs 25 developers, and the card reading project employs 20 developers. A group of 10 other developers produces common code used by both product groups.

Management analyzed the development organization and determined ways to use Configuring to enhance the code management process. They then devised a transition strategy to deploy Configuring to the development groups.

Major goals for the transition strategy:

- Prototype the company's planned use of Configuring. Management wanted to try out the workspace hierarchy strategy they devised for a small group before deploying it to the entire organization.

- Gracefully incorporate Configuring into active development projects. Management wanted to impact current development schedules as little as possible.

## Implementation

The following sections describe the company's:

- Pre-Configuring source file organization

- Configuring solution

- Transition plan that incrementally adopts Configuring into the development organization

### Before Configuring

The company's pre-Configuring source hierarchy was structured so that each development group worked in its own subdirectory under a common source directory. SCCS was used for version control. Figure 17 shows the layout of the source hierarchy.

    Click for closeup.

#### Figure 17 Source File Hierarchy

Developers worked directly in the main project directories containing the files they were concerned with. Often the developers checked files out from SCCS and then copied them to their own work areas, returning them to the project directories when they checked them back in.

This method of development made it difficult to coordinate the work of developers who shared common and interdependent files. Using SCCS in this manner provided only serial access to common files, one developer at a time -- this process created a productivity bottleneck. To get around the bottleneck, developers sometimes made copies of already checked-out files and copied them to their private work areas where they made changes. Changes were extremely difficult to track when the code was merged together.

### The Configuring Solution

After analyzing its products, source base, and development organization, the company decided that a three-level workspace hierarchy was the best solution. The three-level hierarchy provides:

- A top-level release workspace. This workspace contains all of the product source files.

- An integration workspace for each functional group. Senior developers from each group work in these workspaces to integrate changes made by developers. The workspaces contain only the relevant sources for each group.

- A workspace for each developer or task. Development workspaces contain only the files that developers need to do their work.

See the TW Topic "Workspace Hierarchy Strategies for Software Development and Release on page 37" for details about workspace hierarchy strategies.

Figure 18 shows the final hierarchy and the types of files contained at each level.

    Click for closeup.

#### Figure 18 Configuring Workspace Hierarchy

As you can see by comparing the file system hierarchy (Figure 17) with the workspace hierarchy (Figure 18), the workspace hierarchy is analogous to the file system hierarchy. In addition, this hierarchy strongly reflects the company's engineering organization.

A major advantage of this workspace hierarchy is that it lends itself very well to the company's incremental transition plan. That plan is described in the next section.

### The Transition Plan

The company's goal was to incrementally adopt Configuring into the development organization. The strategy was to prototype the solution in a smaller group in order to cause minimal disruption to current product development schedules.

The company decided on the following transition plan:

  1. Initially, deploy the Configuring solution only in the CC group. This group was chosen for prototyping because:

- The CC group was the smallest of the three groups.

- The code produced by this group was used by both of the other projects. Therefore, the larger projects would be exposed to some Configuring concepts during the transition period.

  2. Allow the VR and CR groups to work uninterrupted in their usual manner during the initial deployment.

  3. After testing the solution, smoothly deploy the Configuring solution to the entire development organization as schedules permitted.

The transition plan is shown in Figure 19 on page 72.

A workspace hierarchy is created: The existing project source hierarchy becomes the release workspace \xac . The source developed by the CC group is brought over to create an integration workspace \xad . Developer workspaces are created as required \xae . | Click for closeup.
Development continues: The VR and CR groups work directly in the Release workspace using their traditional methods. The CC group begins development in workspaces, using Configuring commands to transfer changes between the developer workspaces and the integration workspace, and between the integration workspace and the release workspace. Product releases are created from the Release workspace. | Click for closeup.
The VR and CR groups convert to Configuring workspaces when: The company decides that the Configuring process is working well in the CC group. VR and CR product development is at a convenient juncture (typically, just after a release). | Click for closeup.

#### Figure 19 The Transition Plan

#### Notes

- The only difference between a Configuring workspace and a standard directory is that the workspace contains a `Codemgr_wsdata` directory. Therefore, the CR and VR groups' use of the Release workspace as their source directory was totally transparent to them; for their purposes the Release workspace was just like their traditional project source directory.

- All developers in the CC group had their own workspaces. Periodically, changes made in those workspaces were integrated in the CC integration workspace and those changes were then integrated in the release workspace. Conversely, changes made by the CR and VR developers in the release workspace were brought down into the integration workspace, and then to the individual developers' workspaces. See the TW Topic Workspace Hierarchy Strategies for Software Development and Release on page 37" for more information about workspace hierarchies.