The progress hierarchy is used to provide the project structure for which deliverables are grouped (workpacks) and the levels to which progress is calculated, rolled up, and viewed. Projects may require differing reporting structures and hence a system-wide structure may be inappropriate.
For example, the delivered model hierarchy is based on the contract, area, and unit to which the deliverable is related.
Each progress hierarchy is defined on a hierarchy interface and these are optionally realized by the configuration classes such as Plant and Project. When a plant or project is created, one of these optional hierarchy interfaces is selected and instantiated and this identifies the hierarchy for that configuration.
When creating a workpack or template, the hierarchy interface that is relevant to the current create configuration (for example, project) will be instantiated on the workpack and will include a value for each of the interface’s properties.
There are two ways to set the values to each property definition on the hierarchy interface:
-
Scope the property as an enumerated list type.
-
Cater for property definitions that must present a list of values that correspond to instantiated objects (for example, area and unit). To do this, a view definition must be created with the same UID as the property definition with a suffix of ‘Values’. The first property in the view definition will be used to provide the list of values.
When an item is registered for progress, it is necessary to extract the values for the item that match each of the properties in the progress hierarchy for the current create configuration. Each value may represent one of the item’s properties or a property on a related object. To retrieve this data, the system needs to expand a pre-defined view definition for the item. To allow for the possibility that a workpack may contain different progressable classes, it is necessary to resolve a relevant view definition for each class to navigate to the appropriate object(s) to obtain the values for each hierarchy property.
To do this, the system will search for all view definitions whose name is prefixed with the name as selected hierarchy interface. The starting interface of each graph definition that comprise the resultant view definitions is compared against the realized interfaces of the item to be registered. The view definition that has a matching starting interface is selected and expanded for the progress item to extract hierarchy values. Once the hierarchy values for the deliverable have been extracted, they can be matched against the available ‘active’ workpacks to find a match.
For example:
If three objects (a document, a tag and a purchase order) are registered for progress and each item's properties are stored in different ways, then each would require a different view definition to be expanded to obtain the properties. Then:
-
If the document properties are stored on the object itself - then ISPFPrgHierarchyH1_DesignDoc would be a view definition to the properties.
-
If the tag has a relationship to its properties- then ISPFPrgHierarchyH1_Tag would be a view definition to get the names of the related properties.
-
If the purchase order has a relationship to an object where the properties are stored - then ISPFPrgHierarchyH1_Purchase would be a view definition to the object where the properties are stored.
A special command is available to instantiate the required hierarchy interfaces on the plants and projects. This is the 'Set Hierarchy' pull down menu option.
When instantiating these optional interfaces, the following rules must be applied:
-
Only one workpack and one workpack template hierarchy interface to be instantiated for each configuration item.
-
If at least one workpack has been created at a particular configuration, then the hierarchy interface cannot be deleted, amended, or added for the corresponding configuration item.
-
The configuration item must have workpack hierarchy interface instantiated before a workpack can be created for that configuration. Similarly, the configuration item must have workpack template hierarchy interface instantiated before a workpack template can be created for that configuration.
Any class definition that represents a configuration item must realize any workpack or workpack template hierarchy interface definitions that are required for selection.