| <?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-TPAUpjDlUfq2jYIEwi8dZw" name="categorizing,_kY8j4EH-Ed-bmYzvomIdMg" guid="-TPAUpjDlUfq2jYIEwi8dZw" changeDate="2011-10-10T12:17:24.693-0700" version="7.5.0"> |
| <mainDescription><h3>
 |
| Categorizing Method Elements Using Standard Categories
 |
| </h3>
 |
| <p>
 |
| Standard Categories provide a means to categorize core method content in line with the best practices for creating
 |
| structured methods. Standard Categories are linked to a specific method content type.&nbsp; The Standard Category types
 |
| are:
 |
| </p>
 |
| <ul dir="ltr">
 |
| <li>
 |
| <strong>Disciplines</strong>
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| A <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/discipline_7667F451.html"
 |
| guid="_yGUuidnmEdmO6L4XMImrsA">discipline</a>&nbsp;is a category of <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
 |
| guid="_x459ktnmEdmO6L4XMImrsA">task</a>s that are related to a major area of concern within the overall IT
 |
| environment. A task can belong to only one discipline.&nbsp; For example, on a software development project, it is
 |
| common to perform certain requirements tasks in close coordination with analysis and design tasks. Separating these
 |
| tasks into separate disciplines makes the tasks easier to comprehend. Disciplines can be organized using Discipline
 |
| Groupings.<br />
 |
| &nbsp;&nbsp;&nbsp; &nbsp;
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| Initial recommendations are to develop separate discipline groupings for each major context and standardize on the
 |
| set of disciplines within that context, allowing for overlap between contexts where appropriate. While disciplines
 |
| may have many similarities to domains for some areas, no formal relationship between the two has been defined.
 |
| Disciplines are currently intended to be independent of role sets.<br />
 |
| &nbsp;&nbsp;&nbsp;
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| In general, the following are some criteria that affect how you assign tasks to specific disciplines in your
 |
| method:
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| <ul>
 |
| <li>
 |
| Number of tasks: The more tasks you have, the more there is a need to organize them into disciplines
 |
| </li>
 |
| <li>
 |
| <div style="LIST-STYLE-TYPE: none">
 |
| Published representation of the method: How do consumers of the method want to see the tasks organized;
 |
| define disciplines for those organizational elements
 |
| </div>
 |
| </li>
 |
| <li>
 |
| <div style="LIST-STYLE-TYPE: none">
 |
| Governance: How the tasks are governed; define separate domains for tasks that are governed differently
 |
| </div>
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| </ul>
 |
| <blockquote style="MARGIN-RIGHT: 0px" dir="ltr">
 |
| <p style="LIST-STYLE-TYPE: none">
 |
| Processes can also be associated with disciplines as&nbsp;Reference&nbsp;Workflows.&nbsp;&nbsp;
 |
| </p>
 |
| <p style="LIST-STYLE-TYPE: none">
 |
| Note: In some cases, the&nbsp;disciplines and&nbsp;domains are&nbsp;the same (i.e., the same set of names is used
 |
| for&nbsp;both).&nbsp; This approach minimizes the number of different ways you categorize&nbsp;things, which some
 |
| see as an advantage.
 |
| </p>
 |
| </blockquote>
 |
| <ul dir="ltr">
 |
| <li>
 |
| <strong>Domains</strong>
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| A <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/domain_D8238B93.html"
 |
| guid="_yHEVYdnmEdmO6L4XMImrsA">domain</a>&nbsp;is a refineable, logical, categorization of related <a
 |
| class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
 |
| guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s grouped together based on timing, resources, or relationship.
 |
| While a Domain categorizes many work products, a work product belongs to only one Domain. Domains can be further
 |
| divided into sub-domains.<br />
 |
| &nbsp;&nbsp;
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| Domains are seen by some to be more context-neutral than disciplines (i.e., disciplines tend to be more
 |
| context-specific).
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| It is recommended that only parent work products be mapped to a domain, not child work products. This will yield a
 |
| more pleasing tree structure in the published web site because child work products will only show up under their
 |
| parent. If child work products are assigned to a domain, then they will also be displayed in the tree view at the
 |
| ‘top level' under the discipline, as well as under its parent.<br />
 |
| &nbsp;
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| In general, the following are some criteria that affect how you assign work products to specific domains in your
 |
| method:
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| <ul>
 |
| <li>
 |
| Number of work products: The more work products you have, the more there is a need to organize them into
 |
| domains
 |
| </li>
 |
| <li>
 |
| <div style="LIST-STYLE-TYPE: none">
 |
| Published representation of the method: How do consumers of the method want to see the work products
 |
| organized; define domains for those organizational elements
 |
| </div>
 |
| </li>
 |
| <li>
 |
| <div style="LIST-STYLE-TYPE: none">
 |
| Governance: How the work products are governed; define separate domains for work products that are
 |
| governed differently
 |
| </div>
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| </ul>
 |
| <blockquote style="MARGIN-RIGHT: 0px" dir="ltr">
 |
| <p style="LIST-STYLE-TYPE: none">
 |
| Note: In some cases, the&nbsp;domains and&nbsp;disciplines are&nbsp;the same (i.e., the same set of names is used
 |
| for&nbsp;both).&nbsp; This approach minimizes the number of different ways you categorize&nbsp;things, which some
 |
| see as an advantage.
 |
| </p>
 |
| </blockquote>
 |
| <ul dir="ltr">
 |
| <li>
 |
| <strong>Work Product Kinds</strong>
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| A <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_kind_F04A382B.html"
 |
| guid="_QWhfYMaJEduMlb2cQZNTYw">work product kind</a>&nbsp;is another category for grouping <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
 |
| guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s.&nbsp; A work product can have many work product kinds. As an
 |
| example, you might want to have a series of work product kinds that correspond to the overall intent of work
 |
| products, such as specification, plan, or model.&nbsp; The use of work product kinds is optional.<br />
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| In general, the following are some criteria that affect how you assign work products to specific work product kinds
 |
| in your method: 
 |
| <ul>
 |
| <li>
 |
| <div style="LIST-STYLE-TYPE: none">
 |
| Type of work product: Different work product kinds can be defined for artifacts vs outcomes
 |
| </div>
 |
| </li>
 |
| <li>
 |
| <div style="LIST-STYLE-TYPE: none">
 |
| Number of work products: The more work products you have, the more there is a need to organize them
 |
| into work product kinds
 |
| </div>
 |
| </li>
 |
| <li>
 |
| <div style="LIST-STYLE-TYPE: none">
 |
| <div style="LIST-STYLE-TYPE: none">
 |
| Published representation of the method: How do consumers of the method want to see the work
 |
| products organized; do they want to see an alternate organization for the work products, in
 |
| addition to the domain organization.&nbsp; Define role sets for those organizational elements..
 |
| </div>
 |
| </div>
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| </ul>
 |
| <blockquote style="MARGIN-RIGHT: 0px" dir="ltr">
 |
| <p style="LIST-STYLE-TYPE: none">
 |
| Work product kinds are usually more general than domains and usable across contexts.
 |
| </p>
 |
| </blockquote>
 |
| <ul dir="ltr">
 |
| <li>
 |
| <strong>Role Sets</strong>
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| A <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_set_396DC9DB.html"
 |
| guid="_Fs8HAMaIEduMlb2cQZNTYw">role set</a>&nbsp;is used to categorize <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
 |
| guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s with certain commonalities together. For example, in a software
 |
| development environment, an Analyst role set could be used to group together roles such as Business Process
 |
| Analyst, System Analyst and Requirements Specifier. Each of these roles work with similar techniques and have
 |
| overlapping skills, but may be responsible for performing certain tasks and creating certain work products. Role
 |
| sets can be organized using <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_set_grouping_1BF92F71.html"
 |
| guid="_D8F28KNfEdyMFYhoCpD11Q">role set grouping</a>s.<br />
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| In general, the following are some criteria that affect how you define role sets and how you assign roles to
 |
| specific role sets: 
 |
| <ul>
 |
| <li>
 |
| <div style="LIST-STYLE-TYPE: none">
 |
| Number of roles: The more roles you have, the more there is a need to organize them into role sets
 |
| </div>
 |
| </li>
 |
| <li>
 |
| <div style="LIST-STYLE-TYPE: none">
 |
| Published representation of the method: How do consumers of the method want to see the roles organized;
 |
| define role sets for those organizational elements
 |
| </div>
 |
| </li>
 |
| <li>
 |
| <div style="LIST-STYLE-TYPE: none">
 |
| Governance: How the roles and role sets are governed; define separate role sets for roles that are
 |
| governed differently<br />
 |
| </div>
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| <li>
 |
| <strong>Tools</strong>
 |
| </li>
 |
| <li style="LIST-STYLE-TYPE: none">
 |
| A <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/tool_D0FBC781.html"
 |
| guid="_BangwMaJEduMlb2cQZNTYw">tool</a>&nbsp;is a category for <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/tool_mentor_264766F3.html"
 |
| guid="_yYy-mdnmEdmO6L4XMImrsA">tool mentor</a>s. Tools can also provide general descriptions of a tool and it's
 |
| general capabilities.&nbsp;
 |
| </li>
 |
| </ul>
 |
| <p style="LIST-STYLE-TYPE: none" dir="ltr">
 |
| You should define a standard category any time you have a need to categorize method elements.&nbsp; Multiple levels of
 |
| categories are possible, but you should only define what you need to manage your method content.&nbsp; For example, if
 |
| your method only contains&nbsp;two tasks, do you really need a discipline?
 |
| </p>
 |
| <p>
 |
| An important part of defining an element is naming it.&nbsp; For recommendations on naming standard categories, see
 |
| topic Method Element Naming Conventions in the <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>
 |
| You may also want to capture guidance on how to decide what tasks belong in the discipline in the <strong>Key
 |
| considerations</strong> property of the category.
 |
| </p>
 |
| <p>
 |
| Once the categories are defined, method elements can be assigned to them and the resulting categories can be used to
 |
| access the information in the method, as well as in custom categories as part of navigation views.&nbsp;
 |
| </p>
 |
| <p>
 |
| Standard categories cannot be packaged in separate packages in plug-ins, thus alternative categorization schemes must
 |
| be defined in separate plug-ins.
 |
| </p>
 |
| <p>
 |
| Guidance can also be associated with standard categories. Such guidance should be applicable to the category as a
 |
| whole,&nbsp;and should not be all guidance that is associated with each of the elements categorized to that category.
 |
| </p>
 |
| <h3>
 |
| Customizing a Standard Categories&nbsp;
 |
| </h3>
 |
| <p>
 |
| It is assumed that the&nbsp;standard category&nbsp;(e.g., <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/domain_D8238B93.html"
 |
| guid="_yHEVYdnmEdmO6L4XMImrsA">domain</a>&nbsp;or <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/discipline_7667F451.html"
 |
| guid="_yGUuidnmEdmO6L4XMImrsA">discipline</a>) being customized cannot be modified directly. Thus, all changes must be
 |
| stored in a separate plug-in from the&nbsp;standard category being customized. To see the resulting changes, you need
 |
| to browse or publish a configuration that includes the original standard category plus the customizations. If&nbsp;you
 |
| can modify the standard category directly, you should follow the guidelines described in the topic Categorizing Method
 |
| Elements Using Standard Categories below.
 |
| </p>
 |
| <p>
 |
| There are a number of different ways that you can customize an existing standard category.&nbsp;You can:&nbsp;
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Assign elements to the category
 |
| </li>
 |
| <li>
 |
| Remove elements from the category
 |
| </li>
 |
| <li>
 |
| Replace an existing standard category with a new standard category
 |
| </li>
 |
| <li>
 |
| Rename the standard category
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Specific standard category customization scenarios are described in the remaining sections of this guideline.
 |
| </p>
 |
| <h4>
 |
| Assign elements to the category
 |
| </h4>
 |
| <p>
 |
| Perform the following steps to add a method element to an existing standard category:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| If it does not already exist, create a plug-in to contain the standard category customizations.
 |
| </li>
 |
| <li>
 |
| In the new plug-in, define a standard category that contributes to the existing standard category and assign the
 |
| new elements. For more information on contribution, see the topic Using Method Content Variability in the <a
 |
| class="elementLinkWithType"
 |
| href="./../../../practice.bus.mdev.base/guidances/guidelines/defining_method_elements_CADE4FF6.html"
 |
| guid="_fx7TMD3REd-realK_We5vA">Guideline: Defining Method Elements</a>.&nbsp;
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Remove elements from the category
 |
| </h4>
 |
| <p>
 |
| Perform the following steps to remove a method element from an existing standard category:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| If it does not already exist, create a plug-in to contain the standard category customizations.
 |
| </li>
 |
| <li>
 |
| In the new plug-in, define a standard category and assign the same elements as in the original standard category,
 |
| except for the element you want to remove.
 |
| </li>
 |
| <li>
 |
| Change the definition of the new standard category to extends-replace the original standard category.
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Replace an existing standard category with a new&nbsp;standard category
 |
| </h4>
 |
| <p>
 |
| Perform the following steps to replace an existing standard category with a new standard category:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| If it does not already exist, create a plug-in to contain the standard category customizations.
 |
| </li>
 |
| <li>
 |
| In the new plug-in, define the standard category and assign the desired elements.
 |
| </li>
 |
| <li>
 |
| Change the definition of the new standard category to replace the original standard category.
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Rename an existing standard category
 |
| </h4>
 |
| <p>
 |
| Perform the following steps to rename an existing standard category:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| If it does not already exist, create a plug-in to contain the standard category customizations.
 |
| </li>
 |
| <li>
 |
| In the new plug-in, define a standard category and give it the desired presentation name. Specify that the new
 |
| standard category is to extend-replace the existing standard category.
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Standard Categories in the UMF
 |
| </h3>
 |
| <p>
 |
| The Unified Method Framework (UMF)&nbsp;defines some constraints with regards to the definition and use of standard
 |
| categories.&nbsp;Those constraints vary for the different standard category types.
 |
| </p>
 |
| <p>
 |
| The UMF implements a Delayed Assignment&nbsp;approach for <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/discipline_7667F451.html"
 |
| guid="_yGUuidnmEdmO6L4XMImrsA">discipline</a>s, <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/domain_D8238B93.html"
 |
| guid="_yHEVYdnmEdmO6L4XMImrsA">domain</a>s and <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_kind_F04A382B.html"
 |
| guid="_QWhfYMaJEduMlb2cQZNTYw">work product kind</a>s.&nbsp;It does not implement&nbsp;a delayed category assignment
 |
| for <strong>role sets</strong> because the definition of roles and role sets are strongly linked.&nbsp;Roles are
 |
| assigned to role sets in the same plug-in as where the roles are defined, the Role Definition plug-in (their
 |
| definitions are shared).&nbsp;For more information on roles in the UMF, see the topic Roles in the UMF in the <a
 |
| class="elementLinkWithType"
 |
| href="./../../../practice.bus.mdev.base/guidances/guidelines/defining_method_elements_CADE4FF6.html"
 |
| guid="_fx7TMD3REd-realK_We5vA">Guideline: Defining Method Elements</a>. The UMF also does not implement&nbsp;a delayed
 |
| category assignment for <strong>tools</strong> because the assignment of tool mentors to tools does not change (tool
 |
| mentors are written for&nbsp;a specific tool).&nbsp;For more information on tools in the UMF, see the
 |
| topic&nbsp;Tool&nbsp;Information in the UMF in the <a class="elementLinkWithType"
 |
| href="./../../../practice.bus.mdev.base/guidances/guidelines/defining_method_elements_CADE4FF6.html"
 |
| guid="_fx7TMD3REd-realK_We5vA">Guideline: Defining Method Elements</a>.
 |
| </p>
 |
| <p>
 |
| <br />
 |
| The "delayed standard categories" (disciplines, domains and work product kinds) are <strong><em>defined</em></strong>
 |
| in a Category Definition Base plug-in.&nbsp;Elements are <em><strong>assigned</strong></em> to these categories in the
 |
| Assign plug-ins associated with the Base plug-in that contains the elements to be assigned (tasks and work
 |
| products).&nbsp;For information on how these assignments are defined, see the topic Delayed Assignment in the UMF in
 |
| the <a class="elementLinkWithType"
 |
| href="./../../../practice.bus.mdev.base/guidances/guidelines/defining_method_elements_CADE4FF6.html"
 |
| guid="_fx7TMD3REd-realK_We5vA">Guideline: Defining Method Elements</a>.&nbsp;
 |
| </p>
 |
| <p>
 |
| The benefits to the UMF approach to standard categories are:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| The same categories can be used with different element assignments (shared Category Definition plug-ins)
 |
| </li>
 |
| <li>
 |
| Alternate category definitions and element assignments can be defined (provide alternate Category Definition and
 |
| Assign plug-ins)
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Defining Navigation Views
 |
| </h3>
 |
| <p>
 |
| This guideline provides recommendations on how to use custom categories to define navigation views. For general
 |
| information on custom categories, see the topic Categorizing Method Elements Using Custom Categories below.
 |
| </p>
 |
| <p>
 |
| Navigation views are defined as custom categories that define the structure and content of the published method. In
 |
| general, the following are some criteria that affect how you define navigation views for your method:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Number of elements: The more elements you have, the more there is a need to organize them for easy navigation
 |
| </li>
 |
| <li>
 |
| Published representation of the method: How do consumers of the method want to navigate the published
 |
| method.&nbsp;Define navigation views to support the desired navigation paths.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| When defining navigation views, it is important to consider the intended audience and usage model of the
 |
| view,&nbsp;since this will drive the overall organization/hierarchy of the view. For example, will the view be
 |
| organized by element type or by process area?&nbsp;This information can be captured in the description of the custom
 |
| category itself.&nbsp;Such information will be helpful to the person who may may want to consider including the
 |
| navigation view in their configuration for publication.
 |
| </p>
 |
| <p>
 |
| When defining the navigation views, it is a good idea to create a navigation views that represents a natural reading
 |
| sequence.&nbsp;The guideline to the user would be: "Yes, you CAN click on the links within pages, but that's only if
 |
| you want to jump to another location in the website, or do some free exploration. If you want to read the material in
 |
| the recommended order, and make sure you didn't miss anything, then use this navigation view".&nbsp;In such a "natural
 |
| reading sequence" navigation view,&nbsp;&nbsp;each topic should appear only once.&nbsp;The benefits of this approach
 |
| are:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| You can print the configuration
 |
| </li>
 |
| <li>
 |
| You can browse the expanded tree to find a topic (rather than use the "search" feature)
 |
| </li>
 |
| <li>
 |
| You can look for information by logically figuring out what category it logically belongs to.&nbsp;That way even
 |
| if&nbsp;you&nbsp;don't know the name of a page,&nbsp;you can find it by expanding the appropriate nodes in the
 |
| navigation view.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| The following are some navigation views that you my want to consider defining for your method:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>Welcome</strong> view: Includes a Welcome page, as well as About and What's New pages.&nbsp;Provides a
 |
| starting point for first time users, no matter what their role.
 |
| </li>
 |
| <li>
 |
| <strong>Getting Started</strong> view: Provides quick access to key concepts, Web site structure&nbsp;and usage
 |
| information for the new user.&nbsp;&nbsp;
 |
| </li>
 |
| <li>
 |
| <strong>Key Elements</strong> view: Provides quick access to the key elements of the method -- processes, roles,
 |
| tasks, work products and processes (it is assumed that guidance is accessible from those
 |
| elements).&nbsp;&nbsp;&nbsp;
 |
| </li>
 |
| <li>
 |
| <strong>Team</strong> view: Provides access to all elements in the configuration, organized by method element type
 |
| and then by category.&nbsp;This views serves as a type of index to all elements in the method.
 |
| </li>
 |
| <li>
 |
| <strong>Role-based</strong> views: Provides access to the elements of most interest to the role .&nbsp;
 |
| </li>
 |
| <li>
 |
| <strong>Process-based</strong> views: Provides access to the elements that support the process.&nbsp;
 |
| </li>
 |
| <li>
 |
| <strong>Organization/Project-based</strong> views: Provides access the the elements of most interest to the
 |
| organization/project.&nbsp;This view&nbsp;connects the abstractness of the method (content elements and guidance)
 |
| with the concreteness of project life (physical work products) and encourages the team to live the process. It is
 |
| minimalist and thus largely artifact-based, but may also include: 
 |
| <ul>
 |
| <li>
 |
| Links to the current version of artifacts
 |
| </li>
 |
| <li>
 |
| Elements of the development case,
 |
| </li>
 |
| <li>
 |
| Selected guidance
 |
| </li>
 |
| <li>
 |
| Project team information
 |
| </li>
 |
| <li>
 |
| Change Request information
 |
| </li>
 |
| <li>
 |
| Discussion forums
 |
| </li>
 |
| </ul>
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Navigation views in the UMF
 |
| </h3>
 |
| <p>
 |
| The Unified Method Framework (UMF)&nbsp;defines two types of navigation view elements:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>Configuration-specific</strong>, meaning they are intended to be published as part of a specific
 |
| configuration
 |
| </li>
 |
| <li>
 |
| <strong>Common</strong>, meaning they are intended to be shared across plug-ins and configurations. The UMF defines
 |
| <em>navigation view building blocks</em>, which are intended to be used across navigation views, as well as generic
 |
| navigation views that can be used as-is or in parts in other navigation views.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Where the navigation view elements are defined and how elements are assigned to them is different for each.
 |
| </p>
 |
| <p>
 |
| <strong>Navigation view building blocks</strong> are elements that may be used across a number of navigation
 |
| views.&nbsp;The UMF navigation view building blocks categorize method elements by "types" as defined in the meta model
 |
| (i.e., <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
 |
| guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s, <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
 |
| guid="_x459ktnmEdmO6L4XMImrsA">task</a>s, <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html"
 |
| guid="_x7cUM9nmEdmO6L4XMImrsA">artifact</a>s, <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html"
 |
| guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a>s, <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html"
 |
| guid="_LNAAcB_iEdqAHrsQ7-jSbw">outcome</a>s, <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/checklist_D780FDF.html"
 |
| guid="_7vpJsMaCEduMlb2cQZNTYw">checklist</a>s, <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guideline_1D590B95.html"
 |
| guid="_uK8HMMaFEduMlb2cQZNTYw">guideline</a>s, <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/capability_pattern_F5DDC5F.html"
 |
| guid="_2RUJACO4EdqaNq6Ptg8uyA">capability pattern</a>s, <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/delivery_process_BCDF50B7.html"
 |
| guid="_ZufeMCO3EdqaNq6Ptg8uyA">delivery process</a>es, etc), as well as some other key ones (e.g., release
 |
| information).&nbsp;The navigation view building blocks are defined as <a class="elementLinkWithUserText"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/custom_category_554AC4D6.html"
 |
| guid="_eqw94MaFEduMlb2cQZNTYw">custom categories</a>&nbsp;in Navigation View Definition plug-ins, where they can be
 |
| shared across plug-ins. If you want to define additional navigation view building blocks, define an Extends plug-in
 |
| that includes the new building blocks and include the new building blocks in a custom category that contributes to the
 |
| base navigation view building blocks custom category.&nbsp;Using such "super custom categories" will keep the list of
 |
| top-level custom categories from getting too long.
 |
| </p>
 |
| <p>
 |
| <strong>Generic navigation views</strong> are navigation views that may be applicable in multiple
 |
| configurations.&nbsp;They are also defined as custom categories in Navigation View Definition plug-ins, where they can
 |
| be shared across plug-ins.&nbsp;Generic navigation views assemble navigation view building blocks into something that
 |
| can be used as a whole or in parts as a publishable navigation view.&nbsp;For example, a generic navigation view can be
 |
| used to provide a view of everything in the configuration. These navigation views can be used for specific method
 |
| configurations as-is, or tweaked to address the specific needs of the configuration (e.g., extend/replace it or ignore
 |
| and build their own).&nbsp;The benefits of sharing navigation view elements is that you automatically get consistent
 |
| navigation views.
 |
| </p>
 |
| <p>
 |
| <strong>Configuration-specific navigation views</strong> are defined as custom categories in the Publish plug-in for
 |
| the configuration that is to be published.&nbsp;The configuration-specific navigation views indicate what elements
 |
| elements (or navigation view building blocks) are to be included.&nbsp;When defining a configuration-specific
 |
| navigation view, you can:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Create a new view using existing navigation view elements
 |
| </li>
 |
| <li>
 |
| Reuse the common generic navigation view, replacing and/or adding to selected elements, as needed.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Custom categories that are designed to be navigation views should include "view" in the name.&nbsp;Also, the custom
 |
| categories that represent the navigation view tabs for the configuration should be "packaged" in a parent custom
 |
| category with "view tabs" in the name.&nbsp;This makes it easy to identify the custom categories that have been
 |
| designed to serve as the navigation views for the configuration.
 |
| </p>
 |
| <p>
 |
| <br />
 |
| </p>
 |
| <p>
 |
| The UMF also defines a <strong>"Do Not Publish" category</strong>. It is also defined as a custom category in
 |
| Navigation View Definition Base plug-ins, where it can be shared across plug-ins.&nbsp;Plug-ins can map specific method
 |
| elements to this custom category to keep the elements from being published. This category is especially useful for
 |
| publish plug-ins that are constructing custom views for publishing.&nbsp;The elements in&nbsp;this category should be
 |
| removed from all publishable configurations.&nbsp;For more information on publishable configurations, see [Concept:
 |
| Practice Library Configuration Types].
 |
| </p>
 |
| <p>
 |
| For more information on the UMF plug-in types (e.g., Navigation View Definition plug-ins, Publish plug-ins, etc.), see
 |
| [Concept: Practice Library Plug-In Types].
 |
| </p>
 |
| <h3>
 |
| Navigation Views in the IBM UMF
 |
| </h3>
 |
| <p>
 |
| RMC 7.5 (not EPF Composer) has a feature for "tag-based queries" that provides some additional improvements to the
 |
| common navigation view elements.&nbsp; Using that feature, specific method elements can be tagged with a special key
 |
| word which is then included as part of a query in a custom category, where the results of the query populate the custom
 |
| category.
 |
| </p>
 |
| <p>
 |
| The following are some specific ways in which that feature has been leveraged in the UMF content:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <strong>Release information</strong>: "Release information" is not a type, so we can't use the "Include elements of
 |
| type" feature in the base common navigation view element. So instead, we tag all release information method
 |
| elements with a "release_info" tag and then replace the placeholder common navigation view element with a custom
 |
| category that does a tag-based query.&nbsp;<u><em>[*** I checked and none of the practice release information is
 |
| tagged.&nbsp; ***]</em></u>
 |
| </li>
 |
| <li>
 |
| <strong>Structured practice list</strong>.&nbsp; We tagged all technical practices with&nbsp;a "technical" tag and
 |
| defined a "technical practice list" custom category that does a tag-based query on "technical".&nbsp; We tagged all
 |
| management practices with&nbsp;a "management" tag and defined a "management practice list" custom category that
 |
| does a tag-based query on "management".&nbsp; We then replaced the "structured practice list" placeholder in the
 |
| common navigation view elements with a custom category that contains the "technical" and "management"
 |
| tag-based-query custom&nbsp;categories. This way, if you add a new technical practice, you just have to tag the
 |
| practice element with "technical" and it will appear correctly in the view.&nbsp; <em><u>[*** I checked and none of
 |
| the practice release information is tagged.&nbsp; ***]</u></em>
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| These tag-based-query custom categories are defined in the commercial-level extensions to the base navigation view
 |
| definition plug-in.&nbsp; These new custom categories are defined to replace the non-query-based custom categories in
 |
| the base navigation view definition plug-in.&nbsp;&nbsp;
 |
| </p>
 |
| <h3>
 |
| Categorizing Method Elements Using Custom Categories
 |
| </h3>
 |
| <p>
 |
| Custom categories can be used to categorize method elements so that the practitioners can find them easily and quickly.
 |
| They also form the basis of a published configuration by defining the navigation view&nbsp;structure for the
 |
| configuration.&nbsp;
 |
| </p>
 |
| <p>
 |
| Custom categories are highly customizable and can contain any type of element. Custom categories allow you to
 |
| categorize content according to any hierarchical scheme you want and can then be used to compose publishable views, as
 |
| well as providing a means to organize the method content prior to publishing. For example, you could create a <a
 |
| class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/custom_category_554AC4D6.html"
 |
| guid="_eqw94MaFEduMlb2cQZNTYw">custom category</a>&nbsp;that logically organizes content relevant to your development
 |
| organization department, such as a Testing category that groups together all roles, work products, tasks, and guidance
 |
| elements relevant to testing.
 |
| </p>
 |
| <p>
 |
| When defining custom categories, consider the different ways you may want to access the elements, as well as the ways
 |
| in which the end-user of the method may want to access the method elements.&nbsp; The former may result in ideas for
 |
| "method management-focused" custom categories, while the latter may result in ideas for navigation view focused custom
 |
| categories. What information is needed? How does one find that information? Well crafted custom categories will help
 |
| enormously.
 |
| </p>
 |
| <p>
 |
| Custom categories can be nested to create a categorization hierarchy. For example, if you want to define a navigation
 |
| view that includes "sub-folders", you can do that by defining a sub-custom category in a navigation view custom
 |
| category for each folder you would like to be included.
 |
| </p>
 |
| <p>
 |
| Custom categories can also be nested to organize the custom categories.&nbsp;For example, if you define a set of custom
 |
| categories that are intended to represent navigation views and another set that are not.&nbsp;You may want to package
 |
| all the navigation view custom categories in a single custom category.&nbsp;In this case, the topmost custom category
 |
| is more like a package than a custom category.
 |
| </p>
 |
| <p>
 |
| You can add elements to existing categories by defining a custom category that contributes to the original custom
 |
| category and adds the desired elements.&nbsp;
 |
| </p>
 |
| <p>
 |
| For methods containing a lot of elements and plug-ins, defining a shared set of custom categories can be beneficial for
 |
| the following reasons:<br />
 |
| <br />
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Method authors have a consistent way of categorizing content
 |
| </li>
 |
| <li>
 |
| Method authors and delivery practitioners can find related content more easily and reference it
 |
| </li>
 |
| <li>
 |
| Published configurations will have the same look and feel to the delivery practitioner making the web site easier
 |
| to navigate and information easier to find
 |
| </li>
 |
| <li>
 |
| Delivery practitioners will require less education and training on the set of configurations with which they work
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| For recommendations on naming custom categories, see the topic Method Element Naming Conventions in the <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>
 |
| Be sure to capture the purpose of the custom category in its description, so that the reason the custom category was
 |
| created and what it contains is maintained.&nbsp;This will make it easy for other method authors to understand when the
 |
| category should be used.
 |
| </p>
 |
| <p>
 |
| Custom categories cannot be packaged in separate packages in plug-ins.&nbsp;Thus alternative categorization schemes
 |
| must be defined in separate plug-ins.
 |
| </p>
 |
| <h3>
 |
| Customizing a Custom Category
 |
| </h3>
 |
| <p>
 |
| It is assumed that the <a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/custom_category_554AC4D6.html"
 |
| guid="_eqw94MaFEduMlb2cQZNTYw">custom category</a>&nbsp;being customized cannot be modified directly. Thus, all changes
 |
| must be stored in a separate plug-in from the&nbsp;custom category being customized. To see the resulting changes, you
 |
| need to browse or publish a configuration that includes the original custom category plus the customizations.
 |
| If&nbsp;you can modify the custom category directly, you should follow the guidelines described&nbsp; above in
 |
| Categorizing Method Elements Using Custom Categories.
 |
| </p>
 |
| <p>
 |
| There are a number of different ways that you can customize an existing custom category.&nbsp;You can:&nbsp;
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Add elements to an existing custom category
 |
| </li>
 |
| <li>
 |
| Re-order the elements in an existing custom category
 |
| </li>
 |
| <li>
 |
| Replace an existing custom category
 |
| </li>
 |
| <li>
 |
| Rename an existing custom category
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Specific custom category view customization scenarios are described in the remaining sections of this guideline.
 |
| </p>
 |
| <h4>
 |
| Add elements to an existing custom category
 |
| </h4>
 |
| <p>
 |
| Perform the following steps to add a method element to an existing custom category:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| If it does not already exist, create a plug-in to contain the custom category customizations.
 |
| </li>
 |
| <li>
 |
| In the new plug-in, define a custom category that contributes to the existing custom category. For more information
 |
| on contribution, see the topic Using Method Content Variability in the <a class="elementLinkWithType"
 |
| href="./../../../practice.bus.mdev.base/guidances/guidelines/defining_method_elements_CADE4FF6.html"
 |
| guid="_fx7TMD3REd-realK_We5vA">Guideline: Defining Method Elements</a>.
 |
| </li>
 |
| <li>
 |
| In the contributor, assign the elements you would like to see added to the category. If you want to add a
 |
| sub-custom category to the category, define a sub-custom category. You can even control the order in which the
 |
| elements appear in the category, relative to the existing elements.
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Re-order the elements in an existing custom category
 |
| </h4>
 |
| <p>
 |
| Perform the following steps to reorder the elements in an existing custom category:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| If it does not already exist, create a plug-in to contain the custom category&nbsp;customizations.
 |
| </li>
 |
| <li>
 |
| In the new plug-in, define a custom category and assign all the same elements as the original custom category.
 |
| Re-order the elements in the custom category, as desired.&nbsp;
 |
| </li>
 |
| <li>
 |
| Change the definition of the new custom category to replace the original&nbsp;custom category&nbsp;using method
 |
| content variability.&nbsp;
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Replace an existing custom category
 |
| </h4>
 |
| <p>
 |
| Perform the following steps to replace an existing custom category&nbsp;with a new custom category:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| If it does not already exist, create a plug-in to contain the custom category&nbsp;customizations.
 |
| </li>
 |
| <li>
 |
| In the new plug-in, define a custom category and assign all desired elements to the custom category. Re-order the
 |
| elements in the custom category, as desired.&nbsp;
 |
| </li>
 |
| <li>
 |
| Change the definition of the new custom category to replace the original custom category using method content
 |
| variability.&nbsp;
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Rename an existing custom category
 |
| </h4>
 |
| <p>
 |
| Perform the following steps to rename an existing custom category:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| If it does not already exist, create a plug-in to contain the custom category customizations.
 |
| </li>
 |
| <li>
 |
| In the new plug-in, define a custom category that extends and replaces the existing custom category using method
 |
| content variability.&nbsp;
 |
| </li>
 |
| <li>
 |
| Give the new custom category the desired presentation name.
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
