| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-WuAi2XsisktfzngHrIxJ0g" name="structuring_practice,_dxRsUEH-Ed-bmYzvomIdMg" guid="-WuAi2XsisktfzngHrIxJ0g" changeDate="2010-08-03T00:24:32.000-0700" version="7.5.0"> |
| <mainDescription><h3> |
| Structuring a&nbsp;Practice |
| </h3> |
| <p> |
| Structuring a&nbsp;<a class="elementLink" |
| href="./../../../core.default.uma_concept.base/guidances/concepts/practice_F5C8EAAB.html" |
| guid="_qhCTAFRREd2CWscN8Mx6rg">Practice</a>&nbsp;is where the elements of the practice and their relationships are |
| defined. Specifically, structuring a practice involves: |
| </p> |
| <ul> |
| <li> |
| Defining the practice -- where the practice fits in the overall Practice Framework&nbsp;and what are its external |
| dependencies |
| </li> |
| <li> |
| Defining the practice elements -- what elements are contained within the practice and what are their relationships |
| </li> |
| <li> |
| Categorizing the practice elements into standard and custom categories |
| </li> |
| </ul> |
| <p> |
| Each of these topics is described in the following sections. |
| </p> |
| <h4> |
| General practice structuring guidelines |
| </h4> |
| <p> |
| The practice structure must be developed within the guiding principles and constraints of the practice |
| framework&nbsp;in which the practice resides. |
| </p> |
| <p> |
| When structuring a practice, resist the temptation to enter detailed descriptions into the defined method |
| elements.&nbsp;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.&nbsp; |
| </p> |
| <p> |
| When structuring a practice, be sure to look for opportunities to leverage existing information in core elements and/or |
| in other practices.&nbsp;If you find existing method elements in another practice that you would like to share, work |
| with the method architects to get the common information moved to&nbsp;the core where it can be shared. Likewise, |
| method elements should be defined to maximize reuse.&nbsp;If while structuring a practice you define an element that |
| can be shared across practices, it should be defined in&nbsp;in the core where it can be shared, instead of in the |
| practice.&nbsp; |
| </p> |
| <h4> |
| Defining&nbsp;the practice |
| </h4> |
| <p> |
| Defining the practice involves&nbsp;identifying,&nbsp;naming and briefly describing the practice, as well as defining |
| the practice's position in the practice framework (i.e., defining the practice's external dependencies; what are the |
| practice's relationships with other elements in the framework, including core elements as well as other practices). |
| </p> |
| <p> |
| When defining a practice, it is important to explicitly define its inputs (Work Product Slots) and outputs (work |
| products that fill slots), as well as any information (e.g., guidance, work product definitions, etc.) that is shared |
| between practices. It is also a good idea to&nbsp;identify a candidate list of method elements the practice should |
| contain. This provides more detail around the practice's definition. The practice contents will be further refined when |
| the practice is designed. |
| </p> |
| <p> |
| A practice&nbsp;name should be able to be used as a verb phrase – as in "we practice internal medicine", "we practice |
| iterative development", "we practice component-based design", "we practice use-case driven requirements". Be sure to |
| following the naming conventions for the practices. For more information, see the topic Method Element&nbsp;Naming |
| Conventions in <a class="elementLinkWithType" |
| href="./../../../practice.bus.mdev.base/guidances/guidelines/general_naming_conventions_5651B0CC.html" |
| guid="__I8S0D2kEd-lU6YVR9_PJQ">Guideline: General Naming Conventions</a>. |
| </p> |
| <p> |
| When defining practices, strive to minimize dependencies between practices (unless a practice is intended to |
| enhance/refine an existing practice). To reduce the dependencies between practices, information that is shared between |
| practices should be defined as an Work Product Slots and common guidance. Where necessary, practice elements may depend |
| on elements in Core plug-ins (e.g., work product slots, common work products, common guidance, etc.), but ideally |
| should not depend on elements in other practices (unless the purpose of&nbsp;the practice is to extend another specific |
| practice). Remember, practices are intended to be independently adoptable and interchangeable, so limiting external |
| dependencies is important. |
| </p> |
| <p> |
| Any practice that is intended to be an alternative of another practice is not considered an extension/customization of |
| the other practice.&nbsp;It is a practice in its own right. |
| </p> |
| <p> |
| Practices are physically packaged in Practice plug-ins. Practice dependencies are represented as plug-in |
| dependencies.&nbsp;For more information, see the topic Defining Plugins in <a class="elementLinkWithType" |
| href="./../../../practice.bus.mdev.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html" |
| guid="_EXvLwD3NEd-realK_We5vA">Guideline: Creating Plug-ins, Practices and Configurations</a>.&nbsp; |
| </p> |
| <h4> |
| Defining the practice elements |
| </h4> |
| <p> |
| Base definitions of practice elements are defined in Practice Base plug-ins.&nbsp;If you are customizing/extending an |
| existing practice, then the definition of the elements that extend/customize the existing elements should be defined in |
| Extend plug-ins.&nbsp; |
| </p> |
| <p> |
| Defining the practice elements involves: |
| </p> |
| <ul> |
| <li> |
| Defining the practice <a class="elementLink" |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_content_6972AE81.html" |
| guid="_Ts2joB_MEdq6CKKKq4D7YA">method content</a>&nbsp;elements and their relationships |
| </li> |
| <li> |
| Defining the practice&nbsp;<a class="elementLink" |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/process_68E308B4.html" |
| guid="_yQ5m2NnmEdmO6L4XMImrsA">process</a>es and what tasks they are assembled from |
| </li> |
| <li> |
| Defining the practice <a class="elementLink" |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html" |
| guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;and associating the guidance with the appropriate method elements |
| </li> |
| </ul> |
| <p> |
| Each of these is described in the following sections. |
| </p> |
| <h5> |
| Defining the practice method content elements |
| </h5> |
| <p> |
| A practice&nbsp;may contain any number of practice-specific method content elements.&nbsp;In most cases, however, the |
| key elements of a practice are the work products it produces and the tasks that are performed to produce the work |
| products.&nbsp; |
| </p> |
| <p> |
| The following sections provide practice-specific recommendations for defining the method content elements for |
| practices.&nbsp; |
| </p> |
| <p> |
| If the elements to be included in the practice are extensions/customizations of existing elements (or are reusing |
| existing elements in some way), be sure to note the use of variability and the dependence on the element being |
| reused/extended/customized.&nbsp; |
| </p> |
| <h5> |
| Defining practice work products |
| </h5> |
| <p> |
| <a class="elementLinkWithUserText" |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html" |
| guid="_H4JXwB_SEdq6CKKKq4D7YA">Work products</a> in practices may be defined to be used outside the practice, as an |
| input to another practice, for example (externally-available work product), or may be defined to only be used within |
| the practice ("local" work product).&nbsp; |
| </p> |
| <p> |
| Local work products are defined within the practice and may be&nbsp;used as both input and output work products of |
| practice tasks.<br /> |
| Note: Tasks may produce the local work product, but another task must consume the local work product and produce an |
| externally-available work product. |
| </p> |
| <p> |
| Externally-available work products may be defined in either the practice or in a Core plug-in (of their definition is |
| to be shared).&nbsp;No matter where they are defined, externally-available work products must fulfill a Work Product |
| Slot.&nbsp; The fulfillment of the slot is defined within the practice (not in common).&nbsp;Externally-available work |
| products may be used as inputs and/or outputs to tasks in the practice.<br /> |
| Note: Even if they are defined in&nbsp;Core, these work products are still considered conceptually part of the |
| practice.&nbsp;The only reason they are physically placed in a Core plug-in&nbsp;is so their definition can be |
| shared.&nbsp; |
| </p> |
| <p> |
| If the practice work products have significant states that must be recognized in the method (e.g., outlined, detailed, |
| etc.), be sure to include the definition of those states in the work product description. |
| </p> |
| <p> |
| You will also need to define a default <a class="elementLink" |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html" |
| guid="_yUefQNnmEdmO6L4XMImrsA">role</a>&nbsp;assignment for the work product (i.e., what role is responsible for the |
| work product).&nbsp;For more information on roles, see the "Defining Practice Roles" section.&nbsp; |
| </p> |
| <h5> |
| Defining practice roles |
| </h5> |
| <p> |
| <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/concepts/practice_F5C8EAAB.html" |
| guid="_qhCTAFRREd2CWscN8Mx6rg">Practice</a>s generally implement a&nbsp;Delayed Assignment&nbsp;approach for role |
| assignments so that the practices can be reused in different contexts where the roles are different.&nbsp;Thus, in most |
| cases, roles and role assignments (e.g., <a class="elementLink" |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html" |
| guid="_x459ktnmEdmO6L4XMImrsA">task</a>s to performing <a class="elementLink" |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html" |
| guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s, roles responsible for <a class="elementLink" |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html" |
| guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s) are not defined in the same <a class="elementLink" |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/method_plugin_190B9F5E.html" |
| guid="_D4TLgMaGEduMlb2cQZNTYw">method plug-in</a> as the plug-in where the base practice elements are defined, unless a |
| role is truly practice-specific. Role assignments for practices are usually&nbsp;defined in Practice Assign plug-ins. |
| </p> |
| <h5> |
| Defining practice tasks |
| </h5> |
| <p> |
| All <a class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html" |
| guid="_x459ktnmEdmO6L4XMImrsA">task</a>s are usually defined in practices.&nbsp;Very rarely are tasks themselves |
| reusable enough to be in a Core plug-in.&nbsp; |
| </p> |
| <p> |
| A recommended way to identify practice tasks is to identify the key states of the practice work products and then |
| define the tasks so that each task takes a specific work product (e.g., artifact: Practice) to a specific state (e.g., |
| designed, detailed). Tasks should also be named to reflect their purpose, so you may want to consider including the |
| work product name and the intended state in the task name (e.g.,&nbsp;design the practice, detail the |
| practice).&nbsp;Using such a convention results in tasks with a good separation of concerns and with consistent |
| granularity&nbsp;and scope across practices.&nbsp; |
| </p> |
| <p> |
| Practice tasks that need information external to the practice should use Work Product Slots as input work products. |
| They may also use practice work products as input work products. Practice tasks should only output practice tasks, not |
| work product slots. |
| </p> |
| <p> |
| Again, practices general implement a delayed assignment approach for roles, so the performing role for a task is |
| generally not defined in the task definition itself.&nbsp; |
| </p> |
| <h5> |
| Defining Practice Guidance |
| </h5> |
| <p> |
| A practice&nbsp;may contain any number of practice-specific guidance elements.&nbsp;However the following is the type |
| of information that all practices should include: |
| </p> |
| <ul> |
| <li> |
| Goals of the practice |
| </li> |
| <li> |
| Why anyone would want to adopt it (it's business value).&nbsp; What do you get when you adopt it?&nbsp;What |
| problems does it solve? |
| </li> |
| <li> |
| What is provided as part of the practice (i.e., the practice's bill-of-materials) |
| </li> |
| <li> |
| What is the best way to read/navigate the practice (which elements and an what order). |
| </li> |
| <li> |
| How to apply/adopt/implement the practice, including information on different levels of adoption, if applicable |
| </li> |
| <li> |
| Additional information/references related to the practice (e.g., white papers, web sites, etc.) |
| </li> |
| </ul> |
| <p> |
| Practices tend to describe a specific technique for accomplishing a goal.&nbsp;Thus, <a class="elementLink" |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html" |
| guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>&nbsp;elements are a key part of a practice.&nbsp;However, some guidance can |
| be reused across practices.&nbsp;Reusable guidance is packaged in Core plug-ins where it can be shared.&nbsp; A |
| practice may reference such guidance (i.e., associate common guidance with the practice elements) and use it as if it |
| was defined directly within the practice.&nbsp;In fact, such guidance can be considered conceptually part of the |
| practice. |
| </p> |
| <p> |
| Practice-specific guidance should be defined within the practice and associated with the method elements in the |
| practice.&nbsp;&nbsp; |
| </p> |
| <h5> |
| Defining practice processes |
| </h5> |
| <p> |
| Defining practice process is where you turn your attention to the process side of things.&nbsp;How should the tasks |
| "flow" together? What tasks always appear together and in what order do they appear?&nbsp;Are there specific sets of |
| tasks that can be reused together in more course-grained flows?&nbsp; |
| </p> |
| <p> |
| It is a good idea for every practice to provide some <a class="elementLink" |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/capability_pattern_F5DDC5F.html" |
| guid="_2RUJACO4EdqaNq6Ptg8uyA">capability pattern</a>s that describe how the practice elements can be used in a |
| process. Practice-specific capability patterns represent the key things you can do (the capabilities you gain) when you |
| choose the process.&nbsp;Defining practice processes&nbsp;defines an overall flow through the practice's content and |
| validates that you have the right content with the right separation of concerns. |
| </p> |
| <p> |
| In order to define a practice-specific process, you will need to define a process construction configuration that will |
| serve as the default configuration for the process (all processes must have a default configuration).&nbsp;Name the |
| process construction configuration to reflect its association with the practice.&nbsp;Practice processes should be |
| role-agnostic, which means that the construction configuration should not include the default role assignments for the |
| practice tasks. Specifically, the default construction configuration for practice processes should not include the |
| Practice Assign plug-in. |
| </p> |
| <p> |
| Assemble the practice tasks (and tasks in practices that the practice depends on, if any) into capability patterns. If |
| appropriate, create additional capability patterns that leverage capability patterns defined in the practice and in |
| other practices this practice depends on, if necessary.&nbsp;For example, an architecture practice adds a new work |
| product and a new task to a basic development practice (thus the architecture practice depends on the basic development |
| practice).&nbsp;Within the architecture practice you would define architecture-specific capability patterns using the |
| practice tasks, but you may also define a few additional capability patterns that show how the architecture capability |
| patterns could be combined with the basic development capability patterns.&nbsp;Such informational-like capability |
| patterns have been referred to as "reference workflows" as they are not intended to be reused as-is in other processes; |
| instead, they are to be used as an educational tool and may be mimicked in other processes. It is the practice-specific |
| capability patterns (the practice's "key activities") that are intended to be reused in other processes. |
| </p> |
| <p> |
| These guidelines provide practice-specific recommendations for defining processes.&nbsp;<br /> |
| &nbsp; |
| </p> |
| <h4> |
| Categorizing practice elements |
| </h4> |
| <p> |
| Practice elements can be categorized into standard and/or custom categories. Each of these is described in the |
| following sections. |
| </p> |
| <h5> |
| Categorizing the practice method content into standard categories&nbsp; |
| </h5> |
| <p> |
| Practice method content elements should be categorized according to the standard categorization scheme defined in the |
| practice library architecture.&nbsp;However, since practices usually implement a Delayed Assignment&nbsp;approach for |
| standard categories, the assignment of the elements to a standard category should be done separately from the base |
| definition of the practice element (i.e., in Practice Assign plug-ins).&nbsp; |
| </p> |
| <h5> |
| Categorizing the practice elements into custom categories&nbsp; |
| </h5> |
| <p> |
| Practices may define their own custom categories (e.g., a practice-specific way to conceptually organize the practice |
| content, etc.) or add their elements to an existing custom category (e.g., adding content to a custom category of a |
| practice that this practice is extending, etc.) |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
