Task: Set Up Configuration Management (CM) Environment
This task describes how to create an environment where the product can be developed and built.
Purpose
The purpose of this task is to establish an environment where the product can be developed and built. This is done in
two parts, firstly by setting up the hardware environment, and then by establishing the development environment.
Relationships
RolesMain:
Configuration Manager
Additional: Assisting:
InputsMandatory:
Software Development Plan
Optional:
Development Infrastructure
Development Process
Implementation Model
Iteration Plan
External:
None
Outputs
Project Repository
Main Description
Setting up the CM environment involves allocating machine resources (servers and disk space) and installing the
configuration management tools.
Setting up the development environment involves creating repositories, setting up the product directory structure, and
importing any existing files. The initial environment serves as a baseline for further development work.
Steps
Set up the CM Hardware Environment
Purpose:
To allocate the hardware resources required to install and configure the CM Tool.
The Configuration Manager works with the System Administrator to allocate machine resources, and install the necessary
software tools.
The key considerations (in order of priority) for the machine dedicated to running the server that mediates access to
actual data in the project repository are the following:
Memory Requirements
Disk Input / Output Requirements
Network Bandwidth
Project Repository Disk Space
Information on each of these items is provided under the Artifact: Project Repository
Map the Architecture to the Repository
Purpose:
The Product Directory Structure is logically organized to ensure that there is a placeholder for all
project related work products.
The product directory structure serves a logically nested placeholder for all product-related work products. The shape
of the directory (which serves as the project repository) depends on the number of subsystems in the overall system,
and the number of elements in each subsystem.
The logical structure of the product does not emerge until these tasks are underway: Analysis
& Design. An initial project repository needs to be created for the management and planning work products.
Guidance for the initial structure is provided under Concept: Product Directory Structure.
The rest of the structure can be elaborated once design decisions have been made, and the nature of the Implementation
View becomes clearer on how various design elements are to be packaged for implementation.
Create a placeholder for each subsystem that needs to be implemented in the directory structure. Estimate the storage
requirements for the work products that will be developed, and ensure that there will be sufficient physical storage.
For CM purposes, there must be a high degree of cohesion between internal elements in the product directory structure.
The subsystems should have clearly defined interfaces with the other parts of the system, and be independently
buildable and testable. The key reason here is to allow for independent and parallel development of the systems by
separate teams. The idea is to significantly speed up development and promote reuse and ease of system
maintenance.
Create Initial Set of Versioned Elements
Purpose:
To create an initial baseline of project work products.
Even on projects with no configuration management there is a notion of a directory structure and an existing body of
material that is used by the project on an on-going basis. The idea is to export/import the existing material into the
structure created for product development.
Define Baseline Promotion Levels
Purpose:
To ensure all elements stored in the project repository share a common set of "legal" promotion
levels.
A baseline is a single version of the project repository. The quality or status of that baseline is indicated by a
baseline promotion level. All elements stored in the project repository share a common set of "legal" promotion levels,
preferably with consistent definitions across multiple projects. Reference Configuration Management Concept: Baselining for more details.
Properties
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable
More Information
Tool Mentors
Archiving Requirements Using Rational RequisitePro
Checking Out and Checking In Configuration Items Using Rational ClearCase
Creating a Baseline of a Rational RequisitePro Project
Creating Multiple Sites Using Rational ClearCase
Creating Multiple Sites Using Rational ClearQuest
Linking Configuration Management and Change Request Management Using Rational ClearQuest and Rational ClearCase
Setting Up the Implementation Model Using Rational ClearCase
Setting Up the Implementation Model with UCM Using Rational ClearCase