Activity: Create Development Workspace

Purpose A development workspace is a private development area that provides an environment in which a team member can make changes to artifacts without the changes becoming immediately visible to other team members. Part of workspaces is a view that is configured to ensure that any team member can 'get at' the required version of any given artifact they need to do their work. Project policies determine which artifacts are visible or modifiable by whom.
Role: Any Role
Frequency: On-going
Input Artifacts:	Resulting Artifacts: Workspace
Tool Mentors: Accessing Rational ClearCase from Rational Rose Creating a Development Workspace Using Rational ClearCase

Workflow Details:

Configuration & Change Management
- Change and Deliver Configuration Items

Being a member of a project team is knowing what you can work on, and where to deliver the work so that it can be integrated and tested with the work done by others in the team. A project will typically have one shared work area, and multiple private development areas. The private development workspace allows a developer to work on activities in isolation.

A developer joins a project, and in doing so has access to particular artifacts, and an integration workspace. The next step is for the developers to create a private development workspace and populate it with the contents of the project baseline as a basis from which to proceed. The project baseline is created by the Configuration Manager in setting up the project CM environment.

Within the development workspace, developers perform activities to work on artifacts. The work order provides a description for what a team member needs to do. They can share their work with others in the project team by delivering the changed set of artifacts into the project's shared work area.

In the shared work area individual work is integrated with that of other team members. Periodically, a new baseline is created in the shared work area that incorporates the delivered work.

Developers update their private development workspaces to include the set of versions represented by the new baseline. Periodically, as the quality and stability of baselines improve, the promotion level attribute of the baselines is changed to reflect the appropriate level of maturity. Example baseline attributes are built, tested or release; these are determined as part of the project CM policies.