Process model components

This topic describes the main components of the Dimensions CM process model.

Base databases

The basic instance of a Dimensions CM process model is a base database. A single Dimensions CM server can connect to multiple RDBMS instances, and these database instances can also be hosted on machines distinct from the Dimensions CM server.

Within a single database instance, you can divide up your applications into what Dimensions CM calls base databases.

In implementation terms, a base database is a schema. For example, in Oracle each base database is an Oracle user with their own copy of the Dimensions CM schema.

You may decide to create different base databases to separate out different applications due to security concerns or simply because the applications are following very different processes.

Back to top


You can have one or more products within a base database.

A product is a high-level container for related development projects. Some aspects of the development process can then be customized on a per-product basis (for example, Dimensions CM object types, rules, attributes, and functional component breakdown).

For an overview of a product structure in a base database, see Manage applications.

Within a product, many development efforts may be in progress, sometimes in parallel. Dimensions CM calls these containers projects or streams. With respect to projects/streams, you can perform Dimensions CM operations such as:

  • Updating your work area with changes and delivering changes back to the repository.

  • Raising defects.

  • Implementing requirements.

  • Building and deploying software.

Back to top

Dimensions CM objects

Each product has a set of Dimensions CM object classes that can be configured with their own properties, such as lifecycles, attributes, or relationships with other objects.

The following diagram shows these objects and the part they play in the process model.

Object Description
Product A major subdivision of the process model. The objects that you configure belong to the product in which they are defined.
Design part

A logical part of a product's functional breakdown. Design parts are related to one another in a hierarchy. A newly created product automatically has a top-level design part of the same name as the product.

For details, see About design parts.


Represents an asset, for example a source file, that forms a part of the implementation of your product. It belongs to, or is owned by, a particular design part, although it could be reused by other design parts. The item itself is a logical representation of the asset.

For details, see Version management.

Item revision

A specific version of an item. Item revisions are identified by having a version appended to the name of the item.

For details, see Version management.


Represents a collection of item revisions that form a strand of development of part of the product. The item revisions are related in a folder structure which reflects the organized structure in which the files belong.

See About projects and About streams.


A snapshot of a collection of item revisions that is used to capture a particular milestone in the development of the project or stream.

For details, see Baseline management.


A release is created by applying a release template to a baseline to copy the item files for some or all of the items in the baseline to a particular location.

For details, see Release management.


A logical record of a company or organization to whom a release has been supplied, or forwarded to.

For details, see Release management.

Dimensions CM request

Represents an enhancement or fault that has been recorded against the product. It affects one or more design parts, and can affect one or more item revisions.

For details, see Change management.


A requirement is created in Dimensions RM and is associated with a Dimensions CM project. It is visible in Dimensions CM, and you can relate Dimensions CM requests to requirements.

For details, see Dimensions RM integration.

Back to top

Object relationships

Dimensions CM objects can have various types of relationships that help you group, search, and control objects.

For example, a Dimensions CM request can have other requests related to it. It can affect a design part, which is the functional area where the required change needs to be made. A request can also be related to the item revisions which need to be changed (are affected by it) and to the new item revisions created (in response to the request). For details, see Link version management and change management.

Some relationships are formed automatically as a result of your operations. For example, when you create a baseline, you have to specify a design part to which the baseline has an owned by relationship.

Other relationships may be optional or user-defined.

Back to top