| <?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.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="-9oNtk9wFgJxGzEpG-AvUNg" |
| name="main.designing_a_practice,_F2l88JSGEdyCzN0eHC4CLA" guid="-9oNtk9wFgJxGzEpG-AvUNg" |
| changeDate="2008-11-10T18:32:50.464-0800" version="7.2.0"> |
| <mainDescription><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 <a class="elementLink"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/practice_fw_6DA4D54D.html"
 |
| guid="__LjaEFQsEd2uvIuuFjd1Fg">Practice Framework</a>&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>
 |
| <h3>
 |
| General practice structuring guidelines
 |
| </h3>
 |
| <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;For more information, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/method_element_naming_conventions_4A4F743B.html"
 |
| guid="_lAphAF5-EduT-Px7fh0LSg">Guideline: Method Element Naming Conventions</a>&nbsp;and <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/writing_brief_descriptions_D01D2F53.html"
 |
| guid="_cJbBkCAhEdy1y5bWsXfCCg">Guideline: Writing Brief Descriptions</a>.
 |
| </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>
 |
| <h3>
 |
| Defining&nbsp;the practice
 |
| </h3>
 |
| <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 (<a class="elementLink"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/work_product_slot_D5B44CE7.html"
 |
| guid="_Er1OcJIfEdybeduord13cg">Work Product Slot</a>s) and outputs (<a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
 |
| guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s 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 <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/method_element_naming_conventions_4A4F743B.html"
 |
| guid="_lAphAF5-EduT-Px7fh0LSg">Guideline: Method Element 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 <a class="elementLink"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/work_product_slot_D5B44CE7.html"
 |
| guid="_Er1OcJIfEdybeduord13cg">Work Product Slot</a>s 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 <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/defining_plugins_CF19789C.html"
 |
| guid="_OIOSQF_zEduYvI5nsNyVYA">Guideline: Defining Plugins</a>.&nbsp;For more information on plug-in types, see <a
 |
| class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/practice_lib_plugin_types_3EA8002F.html"
 |
| guid="__428YO6cEdygKbJMUVNEtg">Concept: Practice Library Plug-In Types</a>.
 |
| </p>
 |
| <h3>
 |
| Defining the practice elements
 |
| </h3>
 |
| <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>
 |
| <h4>
 |
| Defining the practice method content elements
 |
| </h4>
 |
| <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;For general guidelines on defining method content elements, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/defining_method_content_elements_21A491E3.html"
 |
| guid="_XQqJkCAmEdy1y5bWsXfCCg">Guideline: Defining Method Content Elements</a>. For general guidelines on customizing
 |
| existing method content elements, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/customizing_method_content_element_87D73FFF.html"
 |
| guid="_5cHsoFJsEd2SzrMjC_svdw">Guideline: Customizing a Method Content Element</a>.
 |
| </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;For more information on variability, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/using_method_content_variability_DCE37365.html"
 |
| guid="_8YIMYCNQEdycLddDalDmbA">Guideline: Using Method Content Variability</a>. For general guidelines on customizing
 |
| existing method content elements, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/customizing_method_content_element_87D73FFF.html"
 |
| guid="_5cHsoFJsEd2SzrMjC_svdw">Guideline: Customizing a Method Content Element</a>.
 |
| </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 <a
 |
| class="elementLink" href="./../../../core.mdev.common.base/guidances/concepts/work_product_slot_D5B44CE7.html"
 |
| guid="_Er1OcJIfEdybeduord13cg">Work Product Slot</a>.&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;<a class="elementLink"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/delayed_assignment_24142865.html"
 |
| guid="_rlrykJcbEd2sTqxclDgvog">Delayed Assignment</a>&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.
 |
| For more information on Practice Assign plug-ins, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/practice_lib_plugin_types_3EA8002F.html"
 |
| guid="__428YO6cEdygKbJMUVNEtg">Concept: Practice Library Plug-In Types</a>.&nbsp;
 |
| </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;For more information on practice library plug-in types, see <a
 |
| class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/practice_lib_plugin_types_3EA8002F.html"
 |
| guid="__428YO6cEdygKbJMUVNEtg">Concept: Practice Library Plug-In Types</a>.
 |
| </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 <a class="elementLink"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/work_product_slot_D5B44CE7.html"
 |
| guid="_Er1OcJIfEdybeduord13cg">Work Product Slot</a>s 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>
 |
| <h4>
 |
| Defining practice processes
 |
| </h4>
 |
| <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;Definining 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. For more information on the construction configurations, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/practice_lib_config_types_B96A959A.html"
 |
| guid="_1gchoO6dEdygKbJMUVNEtg">Concept: Practice Library Configuration Types</a>.&nbsp;For more information on defining
 |
| configurations, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/defining_method_configurations_2B25CEA5.html"
 |
| guid="_l77zcIB-EduaS6LQ8n6xUQ">Guideline: Defining Method Configurations</a>. For more information on&nbsp;Assign
 |
| plug-ins, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/practice_lib_plugin_parts_538A81D.html"
 |
| guid="_vgjh4PG1EdyO9sYxKNWf8A">Concept: Practice Library Plug-In Parts</a>.&nbsp;
 |
| </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;For general guidelines on
 |
| defining processes, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/defining_processes_756EDFA.html"
 |
| guid="_Y_JroEyDEdu4NY1n_hCY0w">Guideline: Defining Processes</a>. For general guidelines on customizing existing
 |
| processes, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/customizing_process_E26AC308.html"
 |
| guid="_5e_qMFTMEd2N4vZAlUIPvw">Guideline: Customizing a Process</a>.
 |
| </p><br />
 |
| <h3>
 |
| Categorizing practice elements
 |
| </h3>
 |
| <p>
 |
| Practice elements can be categorized into standard and/or custom categories. Each of these is described in the
 |
| following sections.
 |
| </p>
 |
| <h4>
 |
| Categorizing the practice method content into standard categories&nbsp;
 |
| </h4>
 |
| <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 <a class="elementLink"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/delayed_assignment_24142865.html"
 |
| guid="_rlrykJcbEd2sTqxclDgvog">Delayed Assignment</a>&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;For more information on categorizing method elements into standard categories, see <a
 |
| class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/categorizing_method_elements_using_std_cats_854BD33A.html"
 |
| guid="_thsRIMjnEdyoXMhaXAJ-6g">Guideline: Categorizing Method Elements Using Standard Categories</a>. For more
 |
| information on Practice Assign plug-ins, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/concepts/practice_lib_plugin_types_3EA8002F.html"
 |
| guid="__428YO6cEdygKbJMUVNEtg">Concept: Practice Library Plug-In Types</a>.
 |
| </p>
 |
| <h4>
 |
| Categorizing the practice elements into custom categories&nbsp;
 |
| </h4>
 |
| <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.).&nbsp;For general information on categorizing method elements into
 |
| custom categories, see <a class="elementLinkWithType"
 |
| href="./../../../core.mdev.common.base/guidances/guidelines/categorizing_method_elements_using_custom_cats_F66C3F90.html"
 |
| guid="_V7qwIMjpEdyoXMhaXAJ-6g">Guideline: Categorizing Method Elements Using Custom Categories</a>.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
