| <?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="-rkXYoYQpmc2gj81K_J6wbw" |
| name="new_guideline,_thsRIMjnEdyoXMhaXAJ-6g" guid="-rkXYoYQpmc2gj81K_J6wbw" changeDate="2008-09-11T10:20:45.437-0700" |
| version="7.2.0"> |
| <mainDescription><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 dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <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 dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <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 />
 |
| <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 dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <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 dir="ltr" style="LIST-STYLE-TYPE: none">
 |
| 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 <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>
 |
| 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; For more
 |
| information on 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>
 |
| <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></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
