In order to ensure that the plug-ins within the Practice Framework library fit together nicely and to maximize reuse
across elements, specific plug-in types are defined. Such a consistent approach for how plug-ins are structured allows
true plug-and-play between content authored by different groups and ensures that remotely authored content integrates
seamlessly into the overall library. To support this, individual plug-in types can be defined to define each the
important separate areas of concern. Plug-ins can then follow a consistent packaging structure for the actual
content based on the plug-in's type.
Figure 1 summarizes the types of plug-ins that should be defined when defining a practice framework library, as
well as the allowable dependencies between these plug-in types.
Figure 1. Practice Framework Library Plug-In Types and their Relationships
The plug-ins shown in Figure 1 and described below are "logical" plug-ins. As described in the "Plug-in
parts" section below, each logical plug-in may be represented by a number of individual "plug-in parts". In other
works, for every logical plug-in, there may be more than one physical plug-in.
Core plug-ins contain the elements intended to be shared between other plug-ins in the
framework. They provide the foundation of the framework and enable reuse across the elements in the framework
(e.g., Practices and processes). The core elements serve used as a foundation for defining how the
various different types of content will fit together. Specifically, include elements that serve as the interface
between practices (Work Product Slots), as well as key reusable elements such as work products or
guidance that are intended to be used in a variety of different practices (i.e., shared across practice plug-ins).
Practice plug-ins contain the practice elements. There is a Practice plug-in per
practice. Practice plug-ins only depend on Core plug-ins (thus enabling them to be plugged and played).
Exception: Some practices are defined by reusing content from other practices (e.g., booster practices). For example, a
practice may be defined to pre-configure a set of practices into one and then provide some value-added extensions to
Process plug-ins contain the elements that define cross-practice processes that are intended to be shared across configurations
(practice-specific processes are contained in Practice plug-ins and configuration-specific processes are contained in
Publish plug-ins). Cross-practice processes are assembled from elements (tasks and/or processes) contained in Practice plug-ins and possibly other Process
plug-ins. Process plug-ins include the processes themselves, as well as any process-specific extensions to
existing elements that are needed to make the various parts of the process work and fit together. There can by any
number of process plug-ins; however, an attempt should be made to group similar processes that always appear together
in the same process plug-in. For example, you may define a Process plug-in for a particular process family, for a
set of processes that share a common lifecycle approach/style and/or for all of the processes included in a specific
method asset.Process plug-ins can depend on Core plug-ins (for shared elements), Practice plug-ins (for
practice-specific elements to included in the process) and Process plug-ins (for shared processes).
Publish plug-ins contain method elements that are unique to a specific configuration that is being
published. For example, a Publish plug-in might contain some configuration-specific navigation views, roadmaps, a
welcome page, an so on. A Publish plug-in may even include process, if that process is configuration-specific.
In summary, the practice framework plug-in types represent how the key concepts are implemented physically (i.e., how
the practice framework library is organized around practices):
The practices themselves (Practice plug-ins)
The elements that are shared across practices (Core plug-ins)
The processes that are assembled from the practices and that are shared across
configurations (Process plug-ins)
The elements that support a specific Publishable configuration (Publish plug-ins). For more
information on Publishable configurations, see Concept: Practice Library Configuration Types.
The separation of shared elements (Core plug-ins), practice-specific elements (Practice plug-ins) and cross-practice
elements (Process and Publish plug-ins) maximizes reuse between the elements in the framework (practices share core
elements and cross-practice processes share practice and core elements)
In order to improve the configurability and navigability of the practice framework library (as well as to implement Delayed Assignment), the concept of plug-in parts was introduced. For more
information on this, see Concept: Practice Library Plug-In Parts.
Core plug-in subtypes
There are a number of different types of elements that are intended to be shared across the framework (i.e.,
are contained in core plug-ins). However, several of these items need to be reused independently (i.e., I
want to share tool definitions, but I want to define my own domains). Thus, in addition to the above primary
plug-in types, the Unified Method Framework (UMF) also defines a number of Core
Slot plug-ins contain the Work Product Slot definitions, as well as any associated guidance.
Common plug-ins contain common reusable elements such as work products or guidance that are intended to be shared across plug-ins. It is possible
for different practices to utilize the same underlying work products and basic guidance even though they have alternate
approaches with different techniques to produce the same work products. Instead of creating unnecessary
dependencies between practices that are peers, shared elements are defined as common. Common elements, by their very
nature, as defined in a practice-independent way so that multiple practices can share the common content. They are
written at a generic level with the expectation that they will be further specialized as needed for a particular
practice and/or process. Work products should be with the content that supports them. Only truly common work
product definitions should be in common. A litmus test for deciding whether a method element should be placed in a
common plug-in or not is whether the content is applicable across all contexts for which it applies.
The following are some examples of the use of common elements:
A light weight architecture practice and a heavy weight architecture practice can share a common definition of
an architecture work product, but not share tasks (the tasks are defined in the practice).
Two different types of development (e.g., Greenfield vs. reverse engineering approaches) produce the same work
products, but they go through different state changes, have different tasks, etc.
Role Definition plug-ins contain the roles (and optionally role set definitions) that are intended to be shared across
practices. Since practice frameworks usually implements a Delayed Assignment approach for roles, the Role Definition plug-ins do not
contain the assignment of roles to work products or tasks.
Category Definition plug-ins contain category definitions that are intended to be shared across
practices. In the UMF, this includes discipline, domain, work product kind and possibly role set definitions (if they are not in the Role Definition
plug-in). Since practice frameworks usually implement a Delayed Assignment approach for standard categories, the Category Definition
plug-ins do not contain the assignment of elements to these categories. Tools are defined in separate Tool Definition plug-ins, as these were envisioned to
be separately reusable from the other standard categories.
Tool Definition plug-ins contain tool and tool mentor definitions that are intended to be shared across practices. The
assignment of tools to tool mentors not generally delayed assigned, so the Tool Definition plug-ins contain the
assignment of the included tool mentors to the tools. Practice-specific tool mentors and assignment of the practice-specific tool mentors to the tools are defined in
Navigation View Definition plug-ins contain navigation view definitions that are intended to be shared
across plug-ins (e.g., generic navigation views and navigation view building blocks).
Release Copyright plug-ins contain the release copyrights that should be used for the plug-ins in the
framework. There may be any number of Release Copyright plug-ins. Every plug-in should have the appropriate
copyright plug-in associated to it.