Cross-Product Baselines

A cross-product baseline is one which includes design parts and/or items which belong to two or more products, because within the baselined design-structure USAGE relationships have been created (using the Dimensions functions Relate Design Part Usage and/or using Relate Item to Part) and these have specified design parts and/or items in other products.

The product whose design structure (or a subtree of it) is being baselined, is referred to here as the baselining product, and all relevant items which do not belong to this product, are called foreign items belonging to foreign products.

To create a cross-product baseline successfully, the first requirement is that the item-types of all relevant items, including foreign items, must be defined in the process model for the baselining product.

The remaining requirements and limitations concern the lifecycles associated with these item types, in the various process models for all the products represented in the baseline. Obviously, the most straightforward case is where, for each item type concerned, taken in turn, that item type uses the same lifecycle in every process model. If this is indeed the case, then there are no further complications, and revisions of all relevant items, including foreign items, can be selected using the procedures already described.

However, it may be impracticable for different products to share identical lifecycles for the same item type. Therefore when the lifecycle used for an item type in a foreign product differs from that used for the same item type in the baselining product, the extent to which these two lifecycles need to be similar to each other needs to be examined in some detail.

First, suppose the normal lifecycles in the two lifecycles are identical: the same state names appear in the same order; and the lifecycles differ only in the number and/or arrangement of the lifecycle transitions which do not lie on the normal path. Then there is no further problem for relevant items of that type in either product: as far as a baseline-template is concerned, the two lifecycles function in an identical manner, because their normal lifecycles are equivalent.

We now look at the cases where the normal lifecycles for an item type differ in some respect between the baselining product and a foreign product. We need to consider individually the different alternatives for the template rule for that item type, starting with the simplest.

- *ALL rule

  This rule raises no problems, as it selects all revisions of a relevant item, regardless of their lifecycle states. This applies equally to foreign items.

- *BUILT and *MADE OF rules

  These rules also raise no particular problems, as they are processed in an entirely different way, and are not directly concerned with normal lifecycles. The *BUILT and *MADE OF procedures are applied equally to relevant items of both the baselining and foreign products.

- *LATEST rule

  This rule is handled in a special way, the effect of which is that the normal lifecycles for the baselining and foreign products do not need to correspond with each other at all. For a relevant item of the baselining product, the latest revision is selected from all at any of the states in the baselining product's normal lifecycle. And for a foreign item, the latest revision is selected from all at any of the states in that foreign product's own normal lifecycle.

- LFS rule with a specific state

  This is a more general version of *LATEST and is handled as follows. The specific state given is looked up in the normal lifecycle for the baselining product. Let us suppose the normal lifecycle has six states and that the specified state is number 3 (the first state is number 1, and the final normal state, in this case, number 6). For a relevant item of the baselining product, the latest revision would be selected from all those at any of the states whose numbers are 3, 4, 5 and 6. For a foreign item, we look up the foreign product's normal lifecycle for the names of the states which are number 3 (the same number as that of the specified state) or greater, and select the latest revision from those at any of these states.

  This would mean, if this normal lifecycle had nine states instead of six, that there would be seven states from which a selection could be made (numbers 3 to 9 inclusive) instead of four in the baselining product. In an extreme case, if the normal lifecycle for a foreign product had only two states (unlikely but possible), then there would be no states from which to select, and so no revision could be selected for a foreign item of this item type in that product.

  One example of this rule, which could be very useful, is to specify LFS along with the state which is number 2 in the baselining product's normal lifecycle. The effect of this rule would be that, for every relevant item of that item type in any product, the revision selected would be the latest at any normal state, excluding those which had initial status; i.e. it would guarantee that the selected revision had been actioned at least once after modification.

- All other codes and implicit states *FINAL and *HIGHEST

  A rule of this kind requires a significant degree of consistency between the normal lifecycles in the baselining product and a foreign product, in order to satisfactorily select a revision of a foreign item. What happens is that only the baselining product's normal lifecycle is consulted, and the search (in the appropriate order of preference) is performed on all relevant items of that type (for example, associated with that normal lifecycle), including foreign items, using the state names in the baselining product's normal lifecycle.

  To take one of the simpler cases, if the rule specified *FINAL, and the final normal state in the baselining product's lifecycle was DONE, then DONE would at least have to appear somewhere in the corresponding lifecycle for the foreign product, and the foreign item's revision selected would be the latest (if any) which had DONE status, regardless of what DONE actually meant in the foreign product's lifecycle.

  It is necessary, if any of these codes are going to be used, to have sufficient agreement among the normal lifecycles for all the products concerned, as to the meaning of most, if not all, of the state names used, in order to ensure that the selected revision of a foreign item is the one actually desired.

Related Topics

Rule Operation

Rules Using Implicit States