About design parts

To represent how a project/stream is organized from both the management and technical perspectives, Dimensions CM models the system as a logical structure of design parts.

Design parts overview

Dimensions CM uses design parts to create a logical structure of the product.

From the management perspective, product organization focuses on team members, their areas of responsibility, and to whom they report. The technical perspective provides a logical view of how product components are organized and relate to each other.

Design part features:

A design part is an object that represents some conceptual component of the system. Each design part owns a set of items associated with that part of the product, such as a functional specification document, a test specification, or source code files.
Design parts are organized into a design part structure by defining hierarchical relationships between them. Such relationships can reflect the organization of your development project, providing a structure in which you can assign roles and responsibilities to specific users.
You can have as many design parts as necessary to represent the project/stream.
Grouping items within a meaningful design part structure makes it easier for people to understand how things fit together and what role they have to play in the success of the project/stream.

Example: This product, called Payroll, includes three design parts: Applications, Reports, and User Documentation. Each design part can have child design parts. For example, Algorithms, Bonus, and Holiday are children of the Applications design part.

Dimensions CM creates the top-level design part of the product when you define the product. For details about defining products, see Set up the process model.

Design part relationships

You organize design parts into a product by defining relationships between them.

Dimensions CM has the following predefined relationships between design parts:

Breakdown relationships

Describe ownership of a design part by another design part.

Each design part has a parent that is defined when you create the design part. Dimensions CM uses breakdown relationships to determine the inherited responsibilities for the items or requests associated with a particular design part segment.

For example, team members with roles on the parent design part inherit the roles on its child design parts, unless the same roles are assigned to other users on these lower-level design parts.

Usage relationships

Express dependencies between design parts, to show where design parts are reused in the design structure. To visually indicate that a design part is related by Usage, the design part icon displays a link.

A design part can have the following relationships with other Dimensions CM objects.

Object	Description
Items	Each design part owns a set of items associated with that part of the product, such as a functional specification document, a test specification, source code files, test data, and a class library.
Requests	A design part is related to the requests that affect the design part.
Baselines	A design part is related to the baselines that include the design part.

Variant design parts

A design part variant is an alternative implementation of a design part, with the same structure as its source part but different definition.

Variants are located at the same level as their source design parts.

Example: Suppose you have an Output Screens design part, and you need design parts for different languages. Then you could create a variant for each language, such as Output Screens Kanji and Output Screens Spanish.

A variant can represent a specific market requirement or demand. if your team develops a product for two different markets, American and European, you can create a set of design part variants specific to each market.

Design part variants help you define a logical structure and still support clearly defined variations for different applications, with each variation following the same basic structure. For example, if the source design part has child design parts in the tree, the variant design part also has the same child design parts. The following image provides an example:

All variants of one design part must be at an equivalent position in the tree structure. A variant design part uses the same part ID as the source design part.

You can perform the same operations on a variant design part as you can on the source design part.

Design parts and requests

All requests affect one or more design parts.

Note: External requests do not support relationships to design parts.

The scope of work for a request is determined by the design part that it affects. If the request affects a design part at the lowest level of the design structure, the scope of the request is narrowed to that part of the design structure.

Because roles are assigned to users with respect to the design part structure of a product, the design part governs which users have access to the request.

Ideally, requests are assigned to the correct design part when they are created. But this does not always happen because the person submitting the request may not know which design part the request affects. Normally, a few users are given roles at the top-level design part that permit them to change the relationship between the request and the design part.

Part change status (PCS)

The part change status (PCS) is an alphanumeric indicator used for version control. It indicates the modification level of the design part.

By default, a design part inherits the PCS from its parent design part. Design part operations can be performed only on the current version of a design part.

When you update the PCS, the original PCS changes to the Closed state and the new PCS is set to the Open state. Closed PCS versions are inaccessible except for certain baseline reports.

The PCS enables you to change the design part structure when you otherwise could not. When you create a release baseline, Dimensions CM freezes all the items in the baseline, and the design part structure used for the baseline. By changing the PCS of relevant design parts, you can modify the design part structure after a release baseline has been made from the existing design parts.

For details on how to update PCS, see the following topics:

Web client	Update the part change status (PCS)
Desktop client	Update the part change status (PCS)

Guidelines for creating design parts

Follow these recommendations when creating the design part structure of your product:

Design a rough sketch of the product's tree structure so that you know which part is the parent of each new design part.
Determine the purpose of each new design part, to provide a brief description of its function.

For each new design part, you need to know its part specification. The part specification is:

productID:partID.variant;pcs

where:

productID	Specifies the ID assigned to a product when the product is created in the Administration Console.
partID	Specifies the name you give the part. It is the most significant component of the specification.
variant	Indicates that this is a variant of another design part. The variant is inherited from the parent design part. For details, see Variant design parts. Unless directed by your administrator to change this value, leave it at its default value.
pcs	Indicates the modification level of the design part. The part change status (PCS) is inherited from the parent design part. Unless directed to change this value, leave it at its default value. For details, see About design parts.

You need to know which category to assign each design part. Categories are defined in the Administration Console. Work with your administrator to determine which categories to use.