About design parts
To represent how a project/stream is organized, both from a management and technical perspective, Dimensions CM models the system as logical structure of design parts.
Design parts overview
Design parts are logical groupings of objects, such as modules of code, specifications, and documents. Each design part represents a conceptual component of the system. You can have as many design parts as are 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.
For example, the Payroll product can be divided into the following design part structure:
Each of these design parts can have smaller parts, as displayed for Applications:
Dimensions CM creates the top-level design part of the product when you define the product. For more details about defining products, see the Administration Console online help.
Design part relationships
You organize design parts into a product by defining relationships between them.
Dimensions CM has the following predefined types of relationship between design parts:
|Breakdown relationships||Describe design parts that have a component relationship. The component design part can be thought of as a child, while the design part that includes it is the parent.|
|Usage relationships||Express dependencies between design parts, to show where design parts are re-used. To visually indicate that a design part is related by Usage, the design part icon shows a link.|
A design part can have the following relationships with other Dimensions CM objects.
|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.|
Design part and requests
Note: External requests do not support relationships to design parts.
All requests affect one or more 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)|