An Engineering item is “configured” as soon as it is associated with a Model as “Configuration Context”:

These Engineering items are, by definition, managed through a configuration, and NOT through lifecycle maturity. As such, they should not be:

• Revised
• Promoted/demoted to another maturity state

Two modification types can be applied to configured items:

1. Evolution of the configured item (from one model version to another)

To define this evolution, you should use the “Model version” associated with the engineering item as a way to describe how the item evolves. The model version has a full lifecycle process and can be:

• Promoted/demoted
• Revised

If the model version is revised, it can then be applied to the configured engineering item (150% definition) to define its evolution

2. Modification of the configured item (on the level of the associated model version)

For a given model version, configured engineering item definition can be updated by:

• Removing/replacing an existing child item
• Adding a new child
• Updating the effectivity of an existing child (effectivity of type “Evolution”)

Modifications can be performed without any change process, such as in the early phase of the configuration definition. When a controlled process is required to track these modifications, we recommend using a change action (CA), which will govern and trace these modifications.

The following process is recommended:

• Create a change action:
  • If the required change is to modify the “evolution effectivity” of one or more children, define the “applicability” in the change action itself (through a dedicated tab).
  • Use this change action to work under (in “Engineering release” or “Product Structure Editor” widgets) when modifying the structure of the configured engineering item.

Regardless of the work under type applied (Work under Change, Work Under Evolution), you will notice that after the change is completed, the child item and the parent “Configured Item” will both have the attribute “Change Required” turned ON.

For the parent-configured item, it will not be possible to deactivate this attribute, and it will remain turned ON. (Note: currently, there is UI issue visible in the widget. Modifying this attribute is possible, however it is not persistent.)

Therefore,  any subsequent modification of any child of the configured parent item will force this item to be added to a change process. This is required because, as mentioned earlier and unlike non-configured engineering items, the configured items should not be released. Therefore, the only way to trace any related modification of these items would be by governing these changes through a change process. This process will enforce tractability, even though the item is not “Released.”

Here is a summary of these recommendations: