Guideline: Structuring the Practice Framework Core

Structuring the Practice Framework core is where the core elements of the framework and their relationships are defined. The core structure must be developed within the guiding principles and constraints of the practice framework in which the core resides.

When structuring a practice, resist the temptation to enter detailed descriptions into the defined core elements. Instead, just name and briefly describe the elements and enter a few outline details, if they help to more clearly describe the element's basic definition. For more information, see Guideline: Method Element Naming Conventions and Guideline: Writing Brief Descriptions.

When structuring the core elements, be sure to look for opportunities to leverage existing information in other core elements (for example, core elements for a specific context may extend, customize and reuse elements from a more general core). If you find existing core elements in another context-specific core that you would like to share, work with the method architects to get the common information moved to a more general core where it can be shared. Likewise, core elements should be defined to maximize reuse. If while structuring the core elements for a specific context, you define an element that can be shared across contexts, it should be defined in in a more general core where it can be shared.

Core elements are physically packaged in Core plug-ins. For more information on Core plug-ins and what elements should be placed in what plug-ins, see Concept: Practice Library Plug-In Types. For more information on defining plug-ins, see Guideline: Defining Plugins.

Structuring the core elements involves:

Defining the Work Product Slots. For more information, see Guideline: Defining Work Product Slots.
Defining the common method content elements and their relationships (including shared roles, work products and guidance). For more information, see the "Defining the common method content elements" section of this guideline.
Defining the shared standard categories (e.g., domains and disciplines). For more information, see the "Defining shared standard categories" section of this guideline.
Defining the shared custom categories (including shared navigation views). For more information, see the "Defining shared custom categories" section of this guideline.

Additional information on defining these core elements is provided in the following sections.

Defining a work product slot

Work product slots are implemented as work products. However, they are "special" work products in that they are implementation/representation agnostic. Thus, for general information on defining work products, see Guideline: Defining Method Content Elements.

It is important to remember that work products slots are not “real” elements, in the method sense. Thus, there are some additional authoring guidelines:

Work product slots may appear as inputs to tasks
Work product slots may not appear as an output to tasks
Work product slots are filled by real work products in specific practices
Work product slots should not be categorized using standard categories
When naming separate work product slots, use a descriptive name that indicates explicitly that the element is a slot. Specifically, the slot's presentation name should be between brackets and it's internal name should end in (“_slot”). Such conventions make it easy to see what is a slot and what is an actual artifact that fills a slot.
For example:
- Presentation Name: [Specified System]
- Name: specified_system_slot

Defining the common method content elements

In a practice framework, the common method elements usually include common roles definitions, work product definitions and guidance. Tasks are not considered common elements (they defined in specific practices).

The following sections provide core-specific recommendations for defining the common method content elements. For general guidelines on defining method content elements, see Guideline: Defining Method Content Elements.

Defining common work products

Work product definitions are provided in core to allow practices to share the common definition, even though they may use the work product differently (e.g., provide different techniques for producing and consuming the work product).

Work products are not specified as fulfilling specific slots in the core. The fulfillment of slots is defined within the practice (not in common).
Note: Even though common work products are defined in Core, they do not really "exist" as part of the method being defined until they are placed in a slot by a practice. In that case, the work product is considered conceptually part of that practice. The only reason these work product definitions are physically placed in the core is so their definition can be shared.

Work products in the core are generally "state free". Specific work product states are considered practice-specific information.

Work products in the core do not have an associated responsible role. What role is responsible for what work product is a practice-specific decision.

Defining common roles

Practice frameworks generally implement a Delayed Assignment approach for roles and role assignments so the role definitions and/or assignments can be easily changed. Common role definitions are included in the core, but they are not assigned to work products or tasks. These assignments are defined as part of the practice.

Defining common guidance

Common guidance is guidance that can be shared across practices. Such guidance is not associated to any method content elements in the core. Such associations are done as part of defining the practice.
Note: Even though common guidance is defined in the core, such guidance is considered conceptually part of the practice where the guidance is associated to specific practice elements.

Defining shared standard categories

Standard category definitions (domains, disciplines, work product kinds, role sets, tools) are are generally shared across practices, so they are defined in the practice framework core. However, practice frameworks generally implement a Delayed Assignment approach for standard categories, except for tools (since what tool mentors are assigned to what tools usually does not change). Thus these categories are defined in the core, but elements are not categorized using these categories in the core. The categorization happens as part of the practice. For more information on categorizing method elements into standard categories, see Guideline: Categorizing Method Elements Using Standard Categories.

Defining shared custom categories

Custom categories may be defined in the core that can be shared across practices. A common example of a shared custom category is a navigation view, but other custom categories may be defined, as well.

Elements are added to the shared custom categories in the core and in practices, as desired. For more information on categorizing method elements into standard categories, see Guideline: Categorizing Method Elements Using Custom Categories.

These custom categories can then be included, as desired, as part of publishable method configurations. For more information on publishable configurations, see Concept: Practice Library Configuration Types.

Special instructions when authoring in the UMF: When structuring the core elements in the UMF, you must take the UMF constraints into consideration. Specifically, see the following: