Process model components

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

In this topic:

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 different applications due to security concerns or different processes.

Back to top

Products

A product is a high-level container for related development projects. You can have multiple products in a single base database.

For each product, you can customize parts of its process model. For example, object types, rules, attributes, or functional component breakdown. This way, you can have products that follow different development lifecycles or have different item types.

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. Each strand of development is contained in a project or stream. You can perform the following operations in projects/streams:

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

• Raise defects.

• Implement requirements.

• Build and deploy software.

Back to top

Dimensions CM objects

Dimensions CM functionality includes a comprehensive set of well-defined object classes. These classes enable you to place diverse objects, such as files, projects, deployment areas, or bug reports, under configuration control.

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

The following diagram displays the Dimensions CM objects and their part in the process model.

The following table describes the Dimensions CM object classes.

Object	Description
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.
Item	Represents an asset that forms a part of the implementation of your product. Typical items are source code files, executables, program resources such as graphics, and specification documents. Entire folders of files can also be items. Items are versioned objects with full lifecycle support. Each item is owned by a particular design part and may be used by one or more 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.
Project/Stream	Represents a dynamic collection of item revisions that form a strand of development for a part of the product. The item revisions are related in a folder structure that reflects the organized structure in which the files belong. Projects and streams differ in the working practices they are designed to support. For details, see Projects and streams.
Baseline	A snapshot of a design part segment at a given point in time. This snapshot is comprised of related design parts and item revisions selected from the current project/stream. For details, see Baseline management.
Release	A set of items for the product to be issued to customers. When a baseline passes testing, it may be considered ready for release to customers. A release is created by applying a release template to a baseline to copy the baseline's item files to a particular location. For details, see Release management.
Customer	A logical record of a company or organization to whom a release has been supplied. Dimensions CM can record information about customers who have received releases and what releases have been issued to them. For details, see Release management.
Dimensions CM request	Represents an enhancement, bug, or issue that has been recorded against the product. It affects one or more design parts, and can affect one or more item revisions. Requests help in the development lifecycle by automating the change process and reducing corrective cycles. Requests also have lifecycles. A Dimensions CM request has relationships with other objects such as items and design parts for the purposes of change authorization, change tracking, and impact analysis. For details, see Change management. Note: Along with native Dimensions CM requests, you can use requests from other request providers. For details, see Configure request providers.
Requirement	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.

The workflow of Dimensions CM objects is determined by a lifecycle. For details, see Manage the workflow.

User-defined object types

For some Dimensions CM object classes, you can create user-defined object types. Such object types define certain object properties that can be configured differently for different purposes.

You can define object types for these Dimensions CM object classes: design parts, items, requests, projects/streams, and baselines.

Back to top

Object relationships

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. For details, see Link version and change management.

Some relationships are formed automatically as a result of your operations. For example, when you create a baseline, you specify a design part to own the baseline. Other relationships may be optional or user-defined.

For details, see Relationships between objects.

Back to top