Fix grammaer issues identified by translators
diff --git a/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/categorizing.xmi b/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/categorizing.xmi
index caad3bb..4bb8d14 100644
--- a/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/categorizing.xmi
+++ b/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/categorizing.xmi
@@ -1,5 +1,5 @@
<?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="-TPAUpjDlUfq2jYIEwi8dZw" name="categorizing,_kY8j4EH-Ed-bmYzvomIdMg" guid="-TPAUpjDlUfq2jYIEwi8dZw" changeDate="2011-06-23T15:40:33.280-0700" version="7.5.0">
+<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>
@@ -437,7 +437,7 @@
You can print the configuration
</li>
<li>
- You can can the expanded tree visually for a topic (rather than use the "search")
+ 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
diff --git a/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/defining_method_elements.xmi b/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/defining_method_elements.xmi
index d79106b..f5e9ec2 100644
--- a/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/defining_method_elements.xmi
+++ b/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/defining_method_elements.xmi
@@ -1,1280 +1,1294 @@
<?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="-isqsIiw9-4dR3ProL-I-vg" name="new_guideline,_fx7TMD3REd-realK_We5vA" guid="-isqsIiw9-4dR3ProL-I-vg" changeDate="2010-08-03T00:11:25.000-0700" version="7.5.0">
- <mainDescription><h3>
- Defining Method Content Elements
-</h3>
-<p>
- Method content elements are:
-</p>
-<ul>
- <li>
- <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
- guid="_x459ktnmEdmO6L4XMImrsA">task</a>s
- </li>
- <li>
- <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
- guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s
- </li>
- <li>
- <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
- guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s (<a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html"
- guid="_x7cUM9nmEdmO6L4XMImrsA">artifact</a>s, <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html"
- guid="_LNAAcB_iEdqAHrsQ7-jSbw">outcome</a>s and <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html"
- guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a>s)
- </li>
- <li>
- <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
- guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>
- </li>
-</ul>
-<p>
- Defining a method content element involves creating the plug-in that will contain the element (if&nbsp;it does not
- already exist), naming the element and briefly describing it. Any issues naming an element and briefly describing it
- may indicate that the element is not a&nbsp;good element after all.
-</p>
-<h4>
- General Guidelines
-</h4>
-<p>
- The following are some general guidelines when defining method content elements:
-</p>
-<ul>
- <li>
- <strong>Reduce the overall number of method content elements</strong> (e.g., the number of work products, tasks,
- roles).&nbsp;Combine similar elements.<br />
- &nbsp;&nbsp; &nbsp;
- </li>
- <li>
- <strong>Document process-dependent information separate from the method content element
- definition</strong>.&nbsp;Method content&nbsp;elements should&nbsp;be process independent. Any minor
- differences/tweaks to the elements based on where they occur in&nbsp;a particular process or lifecycle&nbsp;can be
- captured in the processes in which the element appears (more on this below). This maximizes the reuse of the method
- content across processes. For more information on defining processes, see <a class="elementLinkWithType"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html:.:.:"
- href="./../../../practice.bus.mdev.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html"
- guid="_E9J1kD9EEd-Xgadv74rzHA">Guideline: Defining and Customizing Processes</a>.<br />
- &nbsp;&nbsp;&nbsp;
- </li>
- <li>
- <strong>Start with the work products</strong>.&nbsp;When identifying method content elements, its always a good
- idea to start with identifying the work products. Work products are the manifestation of the solution to the
- problem the method addresses. They must be clearly understood at the very beginning of a method authoring project.
- Identifying the work products may appear to consume considerable time but unless they are clearly defined, the
- project will fail. For more information, see the "Defining work products" section below.&nbsp;&nbsp;&nbsp;<br />
- &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
- </li>
- <li>
- <strong>Use guidance to supplement</strong> the basics and capture details.&nbsp;Guidance elements can be used to
- supply various kinds of information and assets to method elements so that practitioners are better equipped to
- execute the work.<br />
- &nbsp;&nbsp;&nbsp;
- </li>
- <li>
- <strong>Capture the source of the information for the element</strong>.&nbsp;This information is important if you
- ever need to provide source information for the element for documenting ownership rights.<br />
- &nbsp;&nbsp;&nbsp;&nbsp;
- </li>
- <li>
- <strong>Maintain accurate change histories, as well as making sure your trademarks and copyrights are
- accurate</strong>.<br />
- </li>
- <li>
- <strong>Reuse existing content</strong>. When defining method content elements, it is always a good idea to reuse
- existing content, both content inside the method being developed, as well as content available externally. This is
- especially important in those cases where you are customizing or building on an existing method. Many elements
- may&nbsp;already be defined. It is usually better to start with an existing element than starting from scratch.
- When reusing an existing element, make sure that the content of the element is what you expect. For more
- information on how to leverage existing content and maximize reuse between method content elements, see
- below.<br />
- &nbsp;&nbsp;&nbsp;
- </li>
- <li>
- <strong>Use content packages to organize the defined method content elements</strong>.&nbsp;When defining method
- content elements, you may find that you want to introduce some packages in order to better organize the
- elements.&nbsp;For more information, see <a class="elementLinkWithType"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html:.:.:"
- 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>.
- </li>
-</ul>
-<p>
- The following sections provide method-element-specific guidelines.
-</p>
-<h4>
- Defining work products
-</h4>
-<p>
- There are three types of <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
- guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s that can be defined:
-</p>
-<ul>
- <li>
- Artifact – provides a description and definition for tangible, non-trivial work product
- </li>
- <li>
- Deliverable – a collection of work products, usually artifacts
- </li>
- <li>
- Outcome – an intangible work product that may be a result or state.
- </li>
-</ul>
-<p>
- Following are the guidelines for creating each of these work product types.<br />
-</p>
-<h5>
- Defining artifacts
-</h5>
-<p>
- <a class="elementLinkWithUserText"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html"
- guid="_x7cUM9nmEdmO6L4XMImrsA">Artifacts</a> are tangible, well-defined <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
- guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s consumed, produced, or modified by <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
- guid="_x459ktnmEdmO6L4XMImrsA">task</a>s.&nbsp;Artifacts may be composed of other artifacts.
-</p>
-<p>
- Artifacts are the responsibility of a single <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
- guid="_yUefQNnmEdmO6L4XMImrsA">role</a>, making responsibility easy to identify and understand, and promoting the idea
- that every piece of information produced in the method requires the appropriate set of skills. Even though one role
- might "own" a specific type of artifact, other roles can still use the artifacts, and perhaps even update them, if the
- role has been given permission to do so.
-</p>
-<h5>
- Defining deliverables
-</h5>
-<p>
- A&nbsp;<a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html"
- guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a>&nbsp;is a <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
- guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a> that provides a description and definition for packaging other work
- products, and may be delivered to an internal or external party.&nbsp;Deliverables are used to represent an output from
- a process that has value to a client, customer or other stakeholder.
-</p>
-<h5>
- Defining outcomes
-</h5>
-<p>
- An <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html"
- guid="_LNAAcB_iEdqAHrsQ7-jSbw">outcome</a>&nbsp;describes an intangible&nbsp;<a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
- guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>&nbsp;that represents a result or state, such as an installed server or
- optimized network. Outcomes may also be used to describe work products that are not formally defined.&nbsp;
-</p>
-<h4 dir="ltr" style="MARGIN-RIGHT: 0px">
- Defining roles
-</h4>
-<p>
- A <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
- guid="_yUefQNnmEdmO6L4XMImrsA">role</a>&nbsp;defines a set of related skills and competencies. Roles are used by <a
- class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
- guid="_x459ktnmEdmO6L4XMImrsA">task</a>s to specify who performs them.&nbsp; Roles&nbsp;may be given responsibilities
- for specific work products.&nbsp;
-</p>
-<p>
- The following are some criteria that affect what roles you define in your method:
-</p>
-<ul>
- <li>
- Organization (what are the roles in the organization that the method supports)
- </li>
- <li>
- Type of project (what roles participate in the projects that the method supports)
- </li>
- <li>
- Style of governance (e.g., different RACI matrices)
- </li>
-</ul>
-<p>
- The smaller the number of roles, the better. Define roles to represent distinct skill sets, things a person may choose
- to do for a living, as opposed to something that someone may do on the project at any particular point in time using
- the skills they have with some additional guidance. For example, a person may be an analyst or a designer, but may also
- serve as a reviewer in some circumstances, or may be responsible for implementing a change request. Thus, "analyst" and
- "designer" are good examples of roles, where as "reviewer" and "change request implementer" are not as they perform
- things that anyone can do using their basic skill set (plus some additional guidance like guidelines and checklists).
-</p>
-<p>
- The following are some criteria that affect how you assign roles to work products and tasks in your method:
-</p>
-<ul>
- <li>
- Work allocation in the organization and/or on the project that the method supports (who does what)
- </li>
- <li>
- Style of governance (make very precise responsibility assignments; e.g., different RACI matrices -- RACI, RACI-VS,
- VARISC, RASCI)
- </li>
-</ul>
-<p>
- <br />
-</p>
-<h4>
- Defining tasks
-</h4>
-<p>
- A <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
- guid="_x459ktnmEdmO6L4XMImrsA">task</a>&nbsp;is a description of a unit of work.&nbsp;The performing role
- typically&nbsp;transforms the input <a class="elementLink"
- id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
- guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s into output work products to achieve a well-defined goal.&nbsp;This
- description is complete and independent of when in a process lifecycle the work will actually be performed.
-</p>
-<p>
- Describe tasks in a consistent way, both in terms of naming and in terms of scope/granularity. Try to standardize on a
- key set of verbs and the way those verbs are used in the task names.
-</p>
-<p>
- Define tasks so that they are independent of any specific process/lifecycle.&nbsp;Tasks provide step-by-step
- explanations, describing how specific development goals are achieved independent of the placement of these steps within
- a specific process (e.g., development lifecycle). Processes take these method elements and relate them into
- semi-ordered sequences that are customized to specific types of projects. For example, a software development project
- that develops an application from scratch performs tasks such as "Develop Vision" or "Use Case Design" similar to a
- project that extends an existing software system. However, the two projects will perform the tasks at different points
- in time with a different emphasis, i.e., they perform the steps of these tasks at different points of time and perhaps
- apply individual variations and additions.
-</p>
-<p dir="ltr" style="MARGIN-RIGHT: 0px">
- When identifying what tasks are needed, it is important to decide on the granularity of the task.&nbsp;In doing so, the
- following should be taken into consideration:
-</p>
-<ul>
- <li>
- <strong>A task generally has only one primary output work product</strong>.&nbsp;However, there are instances where
- more than one work product is worked on simultaneously, so it is possible that you will want to define some tasks
- that do have more than one output&nbsp;work product.<br />
- &nbsp;
- </li>
- <li>
- <strong>It is recommended that you define a separate task for each state change a work product product goes
- through.</strong>&nbsp;Since different states need different checklists, have different completion criteria, and
- have different execution guidance, it makes sense to have different tasks.<br />
- &nbsp;&nbsp;
- </li>
- <li>
- <strong>When the inputs to a task are&nbsp;different</strong>, you probably have two different tasks.<br />
- &nbsp;&nbsp;
- </li>
- <li>
- <strong>When the task is assigned to different roles</strong>, you probably want two different tasks.
- </li>
-</ul>
-<p>
- You identify a task when there is a need to transform input work products into outputs through a series of steps
- performed by one or more roles independent of a breakdown structure.
-</p>
-<p>
- When defining a task, you should also define it's relationships with other method content elements.&nbsp;A
- task&nbsp;can have the following relationships with other method content elements:
-</p>
-<ul>
- <li>
- <strong>Roles:</strong>&nbsp; Two types of roles can be specified:
- </li>
- <li style="LIST-STYLE-TYPE: none">
- <ul>
- <li>
- <div>
- <strong>Primary Performer:</strong>&nbsp; Each task should have a primary performer.&nbsp;This is the
- role this is responsible for ensuring that the task is completed.&nbsp;
- </div>
- </li>
- <li>
- <div>
- <strong>Additional Performers:</strong>&nbsp; Additional performers help execute the task.&nbsp;They
- provide information and expertise.<br />
- </div>
- </li>
- </ul>
- </li>
- <li>
- <div>
- <strong>Work Products:</strong>&nbsp; This is where inputs and outputs to the task are
- identified.&nbsp;Specify:
- </div>
- </li>
- <li style="LIST-STYLE-TYPE: none">
- <ul>
- <li>
- <div>
- <strong>Mandatory Inputs:</strong>&nbsp; Mandatory inputs are the work products the task depends upon
- for its successful execution.&nbsp;These are the inputs that the task cannot do without.
- </div>
- </li>
- <li>
- <div>
- <strong>Optional Inputs:</strong>&nbsp;&nbsp;Mandatory outputs&nbsp;are the work products that provide
- additional information or context for the task when it is being executed.&nbsp;However, the task does
- not depend on them for successful execution.
- </div>
- </li>
- <li>
- <div>
- <strong>Outputs:</strong>&nbsp;&nbsp;The output work products are those that are produced directly by
- this task.&nbsp;Most tasks will have only one output work product.
- </div>
- </li>
- </ul>
- </li>
-</ul>
-<h4>
- Defining guidance
-</h4>
-<p>
- Guidance provides additional details to enhance method content.&nbsp;In fact, methods are more flexible if the content
- provided in specific method elements is kept as general as possible, with more detail provided as guidance.&nbsp;The
- method can be easily customized by simply adding or removing guidance. This section provides recommendations on how to
- define guidance and how to associate the guidance with other method elements.&nbsp;
-</p>
-<p>
- There are many different types of guidance, all designed for specific purposes.&nbsp;The guidance types are:
-</p>
-<ul>
- <li>
- <strong>Checklist</strong> – identifies a series of items that need to be completed or verified. Checklists are
- often used in reviews such as walkthroughs or inspections. Checklists may also be a series of questions or a script
- that practitioners may use to lead a discussion with the client's personnel. This might take the form of a
- questionnaire or interview outline that focuses on the information needed for the work product or deliverable. In
- UMA, a content element has at most one checklist. Checklists are useful in a number of contexts: they help in
- deciding what to do, they help doing it, they help assess the quality of the work, and they help understand how a
- particular work product relates to the rest of the process.<br />
- It is recommended that checklists only be associated with work products and not tasks.&nbsp;If a checklist is
- needed for a task, then it can be accessed via the work products associated with the task.<br />
- In general, checklists do not require a brief description.&nbsp;However, if there are multiple checklists for a
- method element, a brief description is helpful to distinguish between them.<br />
- &nbsp;&nbsp;&nbsp;
- </li>
- <li>
- <strong>Concept</strong> – outlines key ideas, basic principles and motivations underlying a topic central to the
- method. Concepts normally address more general topics than guidelines and may span several work products, tasks,
- activities, or disciplines. Examples of concepts might be In the context of risk management, performance testing,
- implementation planning.<br />
- &nbsp;&nbsp;&nbsp;
- </li>
- <li>
- <strong>Example</strong> – a sample instance of a partially or fully formed work product or deliverable. The
- instance may contain live client data (with the client's express permission to use it) or it may contain fabricated
- data that is representative of the information required for the engagement. However, this example is necessarily
- generic and is only a guide to what might be required in an actual work product or deliverable for a specific
- engagement.<br />
- &nbsp;&nbsp;
- </li>
- <li>
- <strong>Guideline</strong> – provides additional details, "how to" information, alternatives, recommendations, or
- rules about the use of a content element. For example, a work product typically has guidelines associated with it
- that provides information on how to develop, evaluate, and use it. Guidelines can provide the context in which a
- work product or other content element exists within a method. A guideline helps practitioners understand how a
- particular content element is used and how it relates to the rest of the process in which it exists. This includes
- formal technique papers for developing work products and deliverables.<br />
- &nbsp;&nbsp;&nbsp;
- </li>
- <li>
- <strong>Estimation Considerations</strong> – guidance on how to estimate the use in a project of the element with
- which it is associated. The guidance may be textual, a spreadsheet, tool, or take some other form.<br />
- &nbsp;&nbsp;
- </li>
- <li>
- <strong>Practice</strong> – a proven way or strategy of doing work to achieve a goal that has a positive impact on
- work product or process quality. Practices are defined orthogonal to methods and processes. They could summarize
- aspects that impact many different parts of a method or specific processes. Examples for practices would be
- "Managing Risks", "Continuously Verifying Quality", "Architecture-centric and Component-based Development", and so
- on.<br />
- &nbsp;&nbsp;&nbsp;&nbsp;
- </li>
- <li>
- <strong>Report</strong> – a predefined template of a result that is generated on the basis of one or more work
- products as an output from some form of tool. A report is not an artifact in itself. It is, in most cases, a
- transitory product of a process or monitoring, and a vehicle to communicate certain aspects of the evolving system;
- it is a snapshot description of artifacts that are not documents themselves.<br />
- &nbsp;&nbsp;&nbsp;&nbsp;
- </li>
- <li>
- <strong>Reusable Asset</strong> – a type of guidance that references assets that lie outside the method. These
- assets may be too large or volatile to be embedded. These assets may also be third party products or services for
- which usage permission has been granted by the owner.&nbsp;&nbsp;&nbsp;&nbsp;<br />
- &nbsp;&nbsp;
- </li>
- <li>
- <strong>Roadmap</strong> – represents important documentation for the activity or process it is related to. Often a
- complex activity such as a process can be much more easily understood by providing a walkthrough with a linear
- thread of a typical instantiation of this activity. In addition to making the process practitioner understand how
- work in the process is being performed, a roadmap provides additional information about how activities and tasks
- relate to each other over time. Road maps are also used to show how specific aspects are distributed over a whole
- process providing a kind of filter on the process for this information.<br />
- &nbsp;&nbsp; &nbsp;
- </li>
- <li>
- <strong>Supporting Material</strong> – this is a catch-all for assets that do not fit in another type.<br />
- &nbsp;&nbsp;&nbsp;&nbsp;
- </li>
- <li>
- <strong>Template</strong> – a version of a work product or deliverable instance that does not contain data so that
- the practitioner may use it to "fill in the blanks". This is usually a form or set of fields that define the data
- to be collected and may assist in analyzing the data to produce the information for the completed work product or
- deliverable. Taken together the example and the template form a powerful pair for the practitioner. In the first,
- the practitioner sees a completes or partially completed work product while the second offers a convenient means of
- producing the work product as rapidly and as accurately as possible.<br />
- &nbsp;&nbsp;&nbsp;
- </li>
- <li>
- <strong>Term Definition</strong> – a definition of a word or phrase that is not in the glossary and that
- practitioner need to understand for the method plug-in.<br />
- &nbsp;&nbsp;&nbsp;
- </li>
- <li>
- <strong>Tool Mentor</strong> – a description of how to achieve certain goals with a specific tool. Tool mentors
- link tasks with tools such as IBM&reg; Rational&reg; Method Composer. They almost completely encapsulate the dependencies
- of the content on the tool set, keeping the tasks free from tool details.<br />
- &nbsp;&nbsp;
- </li>
- <li>
- <strong>White Paper</strong> – an externally published paper that can be read and understood in isolation of other
- content elements and guidance
- </li>
-</ul>
-<p>
- Guidance should be written with a specific scope in mind.&nbsp; For example:
-</p>
-<ul>
- <li>
- Guidance can be more <em><strong>general</strong></em>, written with regards to a set of elements (e.g., workshops,
- collaboration, lifecycle families, etc.)
- </li>
- <li>
- Guidance can be <strong><em>method-element specific</em></strong> (e.g., written regarding a specific work product,
- task, role, process) , or
- </li>
-</ul>
-<p>
- The name of a guidance element should reflect that scope. Specifically, method element-specific guidance should include
- the method element name in its name.&nbsp;For example,&nbsp;Guideline: Detailing a Use Case, Template: Use-Case
- Template.
-</p>
-<p>
- Guidance may be attached to any method element and guidance should be attached to method elements, as needed. However,
- decreasing the number of relationships defined between elements in the method helps to reduce the overall perceived
- complexity of the method.&nbsp;In general, guidance should be associated with the smallest number of elements possible.
- Having "everything associated with everything" is a bad idea as it directly affects the usage of the published web
- site.<br />
- For example, avoid associating the same guidance with work products and tasks that produce the work products as this
- creates unnecessary dependencies since the same content will be linked in via one of the other relationships
- anyway.&nbsp;
-</p>
-<p>
- Guidance should be associated with the element that reflects its scope (i.e., the element where the end-user would be
- expected to look for it).&nbsp; Method element-specific guidance should be associated with the method element it
- describes:
-</p>
-<ul>
- <li>
- If the guidance is about notation or representation of a work product (e.g., template, example, checklist) then it
- should be associated with the work product
- </li>
- <li>
- If the guidance describes a specific technique about how to produce the work product then it should be associated
- with a task that produces the work product
- </li>
- <li>
- General guidance should be associated with "general" elements (e.g., slots, standard categories, reference
- workflows, etc.) or possibly just included in custom categories (aka navigation views)
- </li>
- <li>
- Roles are not a common place for associating guidance, unless that guidance is specific to the role (and not to a
- task the role performs or a work product the role is responsible for)
- </li>
-</ul>
-<p>
- Most guidance should be associated with at least one element. Of course, there are exceptions:
-</p>
-<ul>
- <li>
- Guidance that is about the method, as opposed to being part of the method (e.g.,&nbsp; Welcome pages, About pages,
- What's new pages, etc.).&nbsp;Such guidance is usually only referred to from navigation views.
- </li>
- <li>
- General guidance (e.g., concepts, white papers) sometimes need to be associated with "general"
- elements.&nbsp;<br />
- Some possible associations for general concepts are associating to them from standard categories, custom
- categories/navigation views, etc.
- </li>
-</ul>
-<p>
- When defining guidance elements, you must constantly weigh reuse concerns versus complexity:
-</p>
-<ul>
- <li>
- If you define fine-grained guidance elements, then you can assign the guidance elements to specific method
- elements, which provides just the guidance you need, but&nbsp;then you have many guidance elements, which can be
- construed as being more complex).&nbsp;
- </li>
- <li>
- If you define course-grained guidance elements, then have a smaller number of guidance elements, but then the same
- guidance elements is attached to multiple elements and you have to find what you are looking for by scrolling
- through the course-grained guidance element.
- </li>
-</ul>
-<p>
- Make the best choice based on your circumstances and let end-user feedback be your guide.&nbsp;
-</p>
-<h3>
- Roles in the UMF
-</h3>
-<p>
- The Unified Method Framework (UMF)&nbsp;defines some constraints with regards to the definition and use of <a
- class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
- guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s and <a class="elementLink"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_set_396DC9DB.html"
- guid="_Fs8HAMaIEduMlb2cQZNTYw">role set</a>s.&nbsp;
-</p>
-<p>
- The UMF implements a delayed role assignment&nbsp;approach, which means that the assignment of roles to method content
- elements is NOT done as part of the definition of the method content elements.&nbsp; In addition, in the UMF, role
- definitions are intended to be shared.&nbsp; Thus, in the UMF, the roles and role sets&nbsp;are defined separately from
- the method content elements they can be assigned to (e.g., work products and tasks), as well as from the assignments
- themselves.&nbsp; For information, see the topic Delayed assignment in the UMF below.
-</p>
-<p>
- Roles and role sets may be shared across practices or may be practice-specific and this decision affects what plug-ins
- their definitions and assignments are placed.
-</p>
-<p>
- Shared roles and role sets:
-</p>
-<ul>
- <li>
- Shared roles and role sets are <strong><em>defined</em></strong> in a Role Definition Base plug-in.&nbsp;
- </li>
- <li>
- Shared roles are assigned to shared role sets in a Role Definition Base plug-in.&nbsp;
- </li>
- <li>
- Shared roles are <strong><em>assigned</em></strong> to <a class="elementLink"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
- guid="_x459ktnmEdmO6L4XMImrsA">task</a>s and <a class="elementLink"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
- guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s in the Assign plug-in associated with the Base plug-in where the
- element to be assigned to the role (work product or task) is defined.&nbsp;
- </li>
-</ul>
-<p>
- Practice-specific roles and role sets:
-</p>
-<ul>
- <li>
- Practice-specific roles and role sets are defined in the Practice Assign plug-in.
- </li>
- <li>
- Practice-specific roles are assigned to practice-specific role sets in the Practice Assign plug-in.&nbsp;
- </li>
- <li>
- Practice-specific roles are <strong><em>assigned</em></strong> to <a class="elementLink"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
- guid="_x459ktnmEdmO6L4XMImrsA">task</a>s and <a class="elementLink"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
- guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s in the Practice Assign plug-in.&nbsp;
- </li>
-</ul>
-<p>
- The benefits to the UMF approach to roles are:
-</p>
-<ul>
- <li>
- Roles and role sets can be shared across practices (shared Role Definition plug-ins)
- </li>
- <li>
- Alternate role assignments can be defined (provide alternate Assign plug-ins)
- </li>
-</ul>
-<p>
- Note: If you are developing a method where the role assignments can NEVER change, then late role assignment is overkill
- and the role assignments can be done directly in Base plug-ins.
-</p><br />
-<h3>
- Scaling Method Elements in the UMF
-</h3>
-<p>
- When there is a need to scale, you need to define a base plug-in (or plug-ins) that have a scope&nbsp;generic enough to
- be scaled. For example, we define an open source core plug-in (or plug-ins) that may have a scope that is broader than
- OpenUp Basic in open source layer. OpenUp Basic could then be built on that open source core (as would the rest of the
- IBM methods), possibly using only a subset of the elements in the core. That way, users can have access to the OpenUp
- Basic content, as well as the broader open source core that is built to be scaled up.
-</p>
-<h4>
- Example of using packaging technique to scale
-</h4>
-<ul>
- <li>
- <h5>
- Scaling by adding techniques
- </h5>
- <p>
- Sometimes we want to offer a specialized technique or alternative technique from which the&nbsp;user can pick
- and choose. You can either package the technique in a separate technique plug-in or package the technique in
- its own content package.
- </p>
- <ul>
- <li>
- Create a Technique Plug-in
- <ul>
- <li>
- This method is nice because it captures all the work products, tasks, etc, across all disciplines
- in one place. &nbsp;Selection of the technique is simply a matter of choosing the plug-in.
- </li>
- <li>
- Alternative techniques can be offered using multiple plug-ins
- </li>
- <li>
- Document restrictions in the Plug-in description (available in the configuration editor) for which
- techniques can be used together and which cannot.
- </li>
- </ul>
- </li>
- <li>
- Create a Content Package
- <ul>
- <li>
- This method is useful for small, isolated techniques
- </li>
- <li>
- Note: avoid creating dependencies on content package selection (eg, must choose two or none).&nbsp;
- If the user will need to select multiple content packages to properly choose the technique, it
- would be better to use a technique plug-in instead.<br />
- </li>
- </ul>
- </li>
- </ul>
- </li>
- <li>
- <h5>
- Scaling by adding resource plug-ins
- </h5>
- <p>
- Isolating resources, such as examples and templates, to their own plug-in allows users to select which set of
- resources they want. For example: cmr.res.sw_dev.formal, cmr.res.sw_dev.informal.
- </p>
- <p>
- Don't worry about elaborate content packaging of templates: assume that errors in configurations caused by
- templates not having a WP home because the package containing the WP was deselected.
- </p>
- <p>
- Note:&nbsp; When you have more than one template for a particular work product:
- </p>
- </li>
- <li style="LIST-STYLE-TYPE: none">
- <ul>
- <li>
- <p>
- If the content of the templates is the same, just the format is different (eg, letter, A4, MS Word,
- HTML), then you can just add the additional template to the same template guidance element.
- </p>
- </li>
- <li>
- <p>
- If the content of the templates is different, then use another Template guidance element to attach the
- second template.
- </p>
- </li>
- </ul>
- </li>
-</ul>
-<h4>
- Common guidelines on scaling
-</h4>
-<ul>
- <li>
- Tasks, activities, and steps should be used to describe actionable elements. &nbsp;Do not add tasks, activities,
- and steps to amplify "how" a need should be satisfied. That is "guidance" not "work".
- </li>
- <li>
- Resist the temptation to artificially increase the number of actionable items. Project Managers will simply not
- entertain a work structure with 1100 elements.
- </li>
- <li>
- Use activities, tasks, and steps to define a work road map and put road signs up about the work. &nbsp;Keep the
- guidance in the guidance.
- </li>
- <li>
- Define base elements very generically, with add-on concepts that describe where more detailed elements fit in.
- Example: &nbsp;describe that DB design is part of design and is covered in design elements, even though separate
- elements are not defined.
- </li>
-</ul>
-<h4>
- Scaling guidance elements in the UMF
-</h4>
-<p>
- The following sections describe some strategies&nbsp;for scaling guidance elements.
-</p>
-<h5>
- Strategies&nbsp;for scaling guidance
-</h5>
-<ol>
- <li>
- When the content of an existing guidance method content element can be reused in a higher layer,
- c<strong><u>ontribute</u></strong> more detail to&nbsp;the existing guidance.
- </li>
- <li>
- If the content of an existing guideline cannot be reused in the higher layer, r<strong><u>eplace</u></strong> the
- guidance with more appropriate and elaborate guidance.
- </li>
-</ol>
-<h5>
- Strategy&nbsp;for scaling checklists
-</h5>
-<p>
- You can contribute additional items to the list
-</p>
-<h5>
- Strategy&nbsp;for scaling templates
-</h5>
-<p>
- You can contribute additional templates, but it's probably better to create a different template guidance altogether,
- rather than add different template formats to the same one.
-</p>
-<h4>
- Scaling roles in the UMF
-</h4>
-<p>
- This guideline describe some strategies&nbsp;for scaling roles.&nbsp;For example,&nbsp;in one context, you may have one
- role set and a few roles.&nbsp;At the next level, single roles may become role sets&nbsp;comprised of multiple
- roles.&nbsp;Scaling roles is much easier as a result of UMF's delayed role assignment approach, which supports the easy
- definition of alternate role and role set definitions and assignments.&nbsp;For more information, see the topic above
- Roles in the UMF.
-</p>
-<h4>
- Scaling tasks in the UMF
-</h4>
-<p>
- The following sections describe some strategies&nbsp;for scaling tasks.
-</p>
-<h5>
- Strategy 1: Packaging
-</h5>
-<p>
- Consider the following:
-</p>
-<ul>
- <li>
- Package generic tasks (ie, a that task includes no details) in a sub-package of the work product&nbsp;it produces
- </li>
- <li>
- Package specific tasks in your context. For tasks that are likely to need to be ‘split' later, package them in
- their own pkg.
- </li>
-</ul>
-<h5>
- Strategy 2: Add guidance
-</h5>
-<p>
- Rather than creating more tasks, consider adding more specialized guidance to explain the detail of specific tasks.
-</p>
-<h5>
- Strategy 3: Contribute steps to a task
-</h5>
-<p>
- You can add a step between steps or at the end of the base task steps.&nbsp; You cannot add to the wording of a
- particular step.&nbsp; For example, if you add a new sub-work product to the work product, you can contribute a new
- step to create the sub-work product.
-</p>
-<p>
- Tactical Workaround: When you really want to add to a particular step, indicate you are providing a specialized step by
- naming your step the same as the one you wanted to append to and&nbsp;adding a qualifier in brackets: eg, "Determine
- how elements collaborate [UML modeling]"
-</p>
-<h5>
- Strategy 4: Create new tasks
-</h5>
-<p>
- Create a new task when: a new role performs the task, it is a unit of work that should be tracked (ie, want it in the
- WBS), it has different inputs or outputs.
-</p>
-<h5>
- Strategy 5:&nbsp;Suggest a&nbsp;change to the base task&nbsp;
-</h5>
-<p>
- You could suggest a change to the tasks in the base (eg, OpenUP), so that the base task becomes something you can scale
- from.&nbsp; For example, suggest that the text be updated to only describe what is done, not how.
-</p>
-<h5>
- Strategy 6: Make a task an activity and its steps become tasks
-</h5>
-<p>
- Currently, RMC Tool cannot support this strategy.
-</p>
-<p>
- Tactical workaround:
-</p>
-<ol>
- <li>
- Deselect the package containing the task you are splitting (if it's not in a pkg, get it there...)
- </li>
- <li>
- Create the new tasks
- </li>
- <li>
- Create a Process Pattern (activity) with the same name as the base task
- </li>
- <li>
- Add the new tasks to the activity
- </li>
- <li>
- Reconstruct relationships that were to the task to the appropriate new tasks
- </li>
-</ol>
-<h4>
- Scaling work products in the UMF
-</h4>
-<p>
- The following sections describe some strategies&nbsp;for scaling work products.
-</p>
-<h5>
- Strategy&nbsp;1: Use the notion of container work products in the base.
-</h5>
-<p>
- The base layer (the open source layer) includes a generic work product that can be used as the container for several
- work products in lower levels. Scale by creating child work products of the base container. Contribute to the base work
- products when possible, to reinforce the scaling connection, you could add text to say: " For details about WPx see
- &lt;hyperlink to added WPx&gt;".
-</p>
-<p>
- Note:&nbsp; You may need to suggest a change to the base work product to make it more scalable.
-</p>
-<p align="center">
- <img
- id="A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/example%20of%20scaling%20work%20products.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/example%20of%20scaling%20work%20products.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/example%20of%20scaling%20work%20products.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/example%20of%20scaling%20work%20products.gif:.:.:"
- alt="Example of Scaling Work Products" src="resources/example of scaling work products.gif" border="0" />
-</p>
-<p align="center">
- <b>Figure 1:</b> Example of scaling "Design" Work Product using the notion of container technique
-</p>
-<p>
- Figure 1 shows example when scaling up design from the open source layer. In the open source layer, the primary work
- product is Design. Design is scaling to include conceptual design, logical design, operational design, subsystem
- design, etc... in the commercial layer. Scaling to the commercial layer, the open source Design sub-WP is reused for
- small projects (assuming some content proposals are accepted). For medium and large projects, content is contributed to
- the Design work product which becomes a container for added sub-work products. Again, the licensable layer will reuse
- commercial layer work products with some content contribution to the Design container work product.
-</p>
-<p>
- Guideline: Use the most specific work product as input and output that makes sense
-</p>
-<p>
- Note: Extension is generally not a useful feature because too many associations are kept.
-</p>
-<h5>
- Strategy 2: Split a work product into two
-</h5>
-<ol>
- <li>
- Before attempting to split a work product, consider recommending a change to the&nbsp;base layer to add
- the&nbsp;work product&nbsp;you need
- </li>
- <li>
- Define a custom category that contains the work product to remove and select that category in the do not publish
- part of the configuration.
- </li>
- <li>
- Create the new work product(s) and include them in your configuration.
- </li>
-</ol>
-<h5>
- Strategy 3: Adding new work products
-</h5>
-<p>
- If you cannot scale using strategy 1 or 2, create a new work product. However, avoid just adding work
- products.&nbsp;Where possible, try to consolidate them under a container work product or consider whether&nbsp;the open
- source layer&nbsp;should include the work product.
-</p>
-<p>
- Note:&nbsp;If you just cannot scale from a work product in&nbsp;the&nbsp;base layer, you may need to suggest a change
- to the work product in&nbsp;that base&nbsp;(eg, suggest that the description be made more generic).
-</p>
-<h3>
- Tool Information in the UMF
-</h3>
-<p>
- Tool information can come in many forms: <a class="elementLink"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/tool_D0FBC781.html"
- guid="_BangwMaJEduMlb2cQZNTYw">tool</a>s, <a class="elementLink"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/tool_mentor_264766F3.html"
- guid="_yYy-mdnmEdmO6L4XMImrsA">tool mentor</a>s, <a class="elementLink"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/example_9C7688B0.html"
- guid="_nE6fsMaFEduMlb2cQZNTYw">example</a>s, <a class="elementLink"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/template_53432085.html"
- guid="_1MLN8MaIEduMlb2cQZNTYw">template</a>s, <a class="elementLink"
- href="./../../../core.default.uma_concept.base/guidances/termdefinitions/supporting_material_F91C8C5B.html"
- guid="_SwvUgMaIEduMlb2cQZNTYw">supporting material</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/white_paper_7231747.html"
- guid="_Kc1IIMaJEduMlb2cQZNTYw">white paper</a>s, etc.
-</p>
-<p>
- In the Unified Method Framework (UMF), tool information is defined in multiple plug-ins.
-</p>
-<p>
- Tools (the standard categories) are defined in the Core in a Tool Definition&nbsp;Base plug-in where they can be shared
- between <a class="elementLink"
- href="./../../../core.default.uma_concept.base/guidances/concepts/practice_F5C8EAAB.html"
- guid="_qhCTAFRREd2CWscN8Mx6rg">Practice</a>s.
-</p>
-<p>
- Other tool information is defined according to its scope:
-</p>
-<ul>
- <li>
- <em>General</em> tool information (as opposed to practice-specific tool information) is defined in the Tool
- Definition Base plug-in.
- </li>
- <li>
- <em>Practice-specific</em> tool information is defined in the Practice Base (or Extend) plug-in.&nbsp;
- </li>
-</ul>
-<p>
- The UMF does NOT implement&nbsp;a Delayed Assignment&nbsp;approach 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;Thus:
-</p>
-<ul>
- <li>
- Tool guidance is assigned to tasks in the Practice Base (or Extend) plug-in where the task is defined.&nbsp;The
- assignment is done directly in the task definition.
- </li>
- <li>
- Tool mentors are assigned to the appropriate Tool standard categories&nbsp;in the plug-in where the tool mentors
- are defined. The assignment is done by defining a contributor to the Tool standard category (defined in a Tool
- Definition plug-in) and then assigning the tool mentor to the Tool in the contributor.&nbsp;
- </li>
-</ul>
-<h3>
- Work Product Slots in the UMF
-</h3>
-<p>
- In the Unified Method Framework (UMF),&nbsp;Work Product Slots are defined as artifacts in Slot plug-ins.&nbsp; When
- authoring work products slots, be aware that the content cannot be practice or technique specific. Work product slots
- are intended to be generic. Thus, the most important thing to document is the information the work product slot
- represents, not its specific representation or the technique use to develop it.
-</p>
-<h3>
- Using Method Content Variability
-</h3>
-<p>
- This guideline explains how to utilize method content variability to modify an existing element without directly
- changing the original element's base definition, or to create a new element based on an existing element. Changes are
- defined in a separate content package or plug-in, and the original plug-in is kept intact. Thus, it allows you to
- change method elements by simply changing a configuration (in other words, changing what plug-ins and packages are
- included in the configuration).
-</p>
-<p>
- Variability involves textual attributes and relationships.&nbsp; In other words you can use variability to add, delete
- change, or reuse&nbsp;both text and relationships.&nbsp;
-</p>
-<p>
- Variability is defined between two elements of the same type:
-</p>
-<ul>
- <li>
- Base element: The target of the variability; the element being changed (or used as a base for new element)
- </li>
- <li>
- Variability element: The element containing the changes (or new content or relationships) to be combined with the
- base
- </li>
-</ul>
-<p>
- The base element is never changed directly. All changes (or new content) is defined in the variability element. The
- variability element specifies which element is the base.
-</p>
-<p>
- As shown in Figure 1, when both the base element and the variability element are included in a configuration, the
- configuration "resolves" the variability to produce the result, where that result depends on what variability was used.
-</p>
-<p>
- <strong>Figure 1. Method content variability elements</strong>
-</p>
-<p>
- <img
- id="A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/variability.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/variability.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/variability.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/variability.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/variability.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/variability.gif:.:.:"
- alt="variability_elements" src="resources/variability.gif" border="0" />&nbsp;
-</p>
-<p>
- There are different types of variability, each with their own characteristics, rules, pros and cons. Table 1 provides a
- summary of the different types of variability and when you might want to use them.<br />
- <br />
-</p><br />
-<br />
-<table title="Method Content Variability Summary" cellspacing="0" cellpadding="2" width="85%"
-summary="summary of different types of method content variability" border="1">
- <caption>
- <strong>Table 1. Method Content Variability Summary</strong>
- </caption>
- <tbody>
- <tr>
- <td>
- <strong>Variability Type</strong>
- </td>
- <td>
- <strong>Result</strong>
- </td>
- <td>
- <strong>Possible Uses</strong>
- </td>
- </tr>
- <tr>
- <td>
- Contributes
- </td>
- <td>
- <p>
- Contributing element adds to the base element<br />
- (result = base element plus contributed characteristics)
- </p>
- <ul>
- <li>
- Contributing (variability) element adds to the base element.
- </li>
- <li>
- The base appears in the published Web site, but the contributing element does not.
- </li>
- <li>
- Incoming and outgoing relationships from the contributing element are added to the base<br />
- Exception: If the relationship is a "to one" relationship (for example, a task has at most one
- primary performing role) then the relationship in the contributor is ignored if the base already
- has one.
- </li>
- <li>
- Text from the contributing element is appended to corresponding base sections.
- </li>
- <li>
- A base element can have more then one contributor.
- </li>
- <li>
- Contributes works transitively (a contributing element contributes its own contributors).
- </li>
- </ul>
- </td>
- <td>
- <ul>
- <li>
- Add guidance to an existing element
- </li>
- <li>
- Add steps to an existing task
- </li>
- <li>
- Add responsibility for a work product to a role
- </li>
- <li>
- Add a primary performing role to a task
- </li>
- <li>
- Add a work product to a task (as an input or output work product)
- </li>
- <li>
- Add text to existing elements
- </li>
- <li>
- Adding method elements to existing categories<br />
- <br />
- </li>
- </ul>
- </td>
- </tr>
- <tr>
- <td>
- Replaces
- </td>
- <td>
- <p>
- Replacing element replaces parts of the base element (incoming relationships remain)<br />
- (result = new element, no base element)
- </p>
- <ul>
- <li>
- Replacing (variability)&nbsp;element replaces parts of the base element.
- </li>
- <li>
- The replacing element&nbsp;appears in the published Web site but the base element does not.
- </li>
- <li>
- Outgoing relationships in the replacing element are maintained, and the base's are ignored.
- </li>
- <li>
- Incoming relationships to the base are maintained and added to the replacing element.<br />
- Exception: If the replacing element has an incoming to-one relationship (for example, a replacing a
- role that includes a task performs the role relationship),&nbsp;the replacing element&nbsp;replaces
- that relationship in the&nbsp;base element.
- </li>
- <li>
- Text in the replacing element is left maintained, the base's text is ignored.
- </li>
- <li>
- A base element can only be replaced by one replacing element at a time. If two elements replace the
- same base element,&nbsp;only one can be used for interpretation (the plug-in containing one of the
- replacing elements needs to be removed from the configuration or no replacement will take place).
- </li>
- <li>
- Replacement works transitively (if a replacing element is replaced itself, then&nbsp;the final
- replacing element will prevail).
- </li>
- </ul>
- </td>
- <td>
- <ul>
- <li>
- Replace an existing method content element with another method content element
- </li>
- </ul>
- </td>
- </tr>
- <tr>
- <td>
- Extends
- </td>
- <td>
- <p>
- Extending element inherits characteristics of the base element<br />
- (result = base element + new element)
- </p>
- <ul>
- <li>
- Extending (variability) element inherits characteristics of the base element. The base element is
- unchanged.
- </li>
- <li>
- Both the extending element&nbsp;and the base appear in the published Web site.
- </li>
- <li>
- Outgoing relationships from the base are added to the extending element.
- </li>
- <li>
- Incoming relationships in the extending element&nbsp;are maintained, and the base's are ignored.
- </li>
- <li>
- Text is included in the extending element from the base element if the extending element&nbsp;did
- not include any text for the given section.
- </li>
- <li>
- Extends works transitively (if an extending element is extended itself the second extension
- inherits from its direct and indirect base elements).
- </li>
- </ul>
- </td>
- <td>
- <ul>
- <li>
- Define a new element that looks just like an existing element, with some modifications (in other
- words, define a variant or a specialization of an existing element)
- </li>
- <li>
- Extends is not used to modify an existing element
- </li>
- </ul>
- </td>
- </tr>
- <tr>
- <td>
- Extends-Replaces
- </td>
- <td>
- <p>
- Replacing element replaces only values that have been redefined in the replacer<br />
- (result = new element, no base element)
- </p>
- <ul>
- <li>
- Combines the effects of extends and replaces variability, allowing you to selectively replace
- specific attributes and relationships of the base element.
- </li>
- <li>
- Extending-replacing (variability) element replaces values in the base element that have been
- redefined in the&nbsp;extending-replacing element . All other values of the base element are
- unaffected.
- </li>
- <li>
- Both the extending-replacing element&nbsp;and the base appear in the published Web
- site.&nbsp;&nbsp;
- </li>
- </ul>
- </td>
- <td>
- <ul>
- <li>
- Rename an existing element
- </li>
- <li>
- Replace a specific textual attribute of a method element
- </li>
- <li>
- Replace the outgoing relationships of an existing method element
- </li>
- <li>
- Replace the incoming relationships of an existing method element
- </li>
- </ul>
- </td>
- </tr>
- </tbody>
-</table><br />
-<br />
-<h4>
- Order of evaluation
-</h4>
-<p>
- Contribution precedes replacement (the contributes relationship is resolved first, followed by the replaces
- relationship). The evaluation of contribution and replacement is performed top-down in the specialization hierarchy.
-</p>
-<h4>
- Handy tricks
-</h4>
-<p>
- If you ever find that you want to create an element that looks just like an existing element, but includes some
- additional content, you can use a combination of extends and contributes to achieve the desired result.&nbsp; To do
- this, perform the following steps:
-</p>
-<ol>
- <li>
- Define a method element that that extends the original base element. This results in a new element that looks just
- like the original element.
- </li>
- <li>
- Define another method element that contributes to the extending element and add the desired content. This results
- in adding the new content to the new element that already includes the original content.
- </li>
-</ol>
-<p>
- The net result:&nbsp;A new element that includes the original content plus the new content.
+<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="-isqsIiw9-4dR3ProL-I-vg" name="new_guideline,_fx7TMD3REd-realK_We5vA" guid="-isqsIiw9-4dR3ProL-I-vg" changeDate="2011-10-10T10:28:38.868-0700" version="7.5.0">
+ <mainDescription><h3>
+ Defining Method Content Elements
+</h3>
+<p>
+ Method content elements are:
+</p>
+<ul>
+ <li>
+ <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:"
+ class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+ guid="_x459ktnmEdmO6L4XMImrsA">task</a>s
+ </li>
+ <li>
+ <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:"
+ class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
+ guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s
+ </li>
+ <li>
+ <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:"
+ class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s (<a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:"
+ class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html"
+ guid="_x7cUM9nmEdmO6L4XMImrsA">artifact</a>s, <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:"
+ class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html"
+ guid="_LNAAcB_iEdqAHrsQ7-jSbw">outcome</a>s and <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:"
+ class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html"
+ guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a>s)
+ </li>
+ <li>
+ <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html:.:.:"
+ class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guidance_549AC394.html"
+ guid="_83ttAB_NEdq6CKKKq4D7YA">guidance</a>
+ </li>
+</ul>
+<p>
+ Defining a method content element involves creating the plug-in that will contain the element (if&nbsp;it does not
+ already exist), naming the element and briefly describing it. Any issues naming an element and briefly describing it
+ may indicate that the element is not a&nbsp;good element after all.
+</p>
+<h4>
+ General Guidelines
+</h4>
+<p>
+ The following are some general guidelines when defining method content elements:
+</p>
+<ul>
+ <li>
+ <strong>Reduce the overall number of method content elements</strong> (e.g., the number of work products, tasks,
+ roles).&nbsp;Combine similar elements.<br />
+ &nbsp;&nbsp; &nbsp;
+ </li>
+ <li>
+ <strong>Document process-dependent information separate from the method content element
+ definition</strong>.&nbsp;Method content&nbsp;elements should&nbsp;be process independent. Any minor
+ differences/tweaks to the elements based on where they occur in&nbsp;a particular process or lifecycle&nbsp;can be
+ captured in the processes in which the element appears (more on this below). This maximizes the reuse of the method
+ content across processes. For more information on defining processes, see <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html:.:.:"
+ class="elementLinkWithType"
+ href="./../../../practice.bus.mdev.base/guidances/guidelines/defining_customizing_processes_55E6CE53.html"
+ guid="_E9J1kD9EEd-Xgadv74rzHA">Guideline: Defining and Customizing Processes</a>.<br />
+ &nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Start with the work products</strong>.&nbsp;When identifying method content elements, its always a good
+ idea to start with identifying the work products. Work products are the manifestation of the solution to the
+ problem the method addresses. They must be clearly understood at the very beginning of a method authoring project.
+ Identifying the work products may appear to consume considerable time but unless they are clearly defined, the
+ project will fail. For more information, see the "Defining work products" section below.&nbsp;&nbsp;&nbsp;<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Use guidance to supplement</strong> the basics and capture details.&nbsp;Guidance elements can be used to
+ supply various kinds of information and assets to method elements so that practitioners are better equipped to
+ execute the work.<br />
+ &nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Capture the source of the information for the element</strong>.&nbsp;This information is important if you
+ ever need to provide source information for the element for documenting ownership rights.<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Maintain accurate change histories, as well as making sure your trademarks and copyrights are
+ accurate</strong>.<br />
+ </li>
+ <li>
+ <strong>Reuse existing content</strong>. When defining method content elements, it is always a good idea to reuse
+ existing content, both content inside the method being developed, as well as content available externally. This is
+ especially important in those cases where you are customizing or building on an existing method. Many elements
+ may&nbsp;already be defined. It is usually better to start with an existing element than starting from scratch.
+ When reusing an existing element, make sure that the content of the element is what you expect. For more
+ information on how to leverage existing content and maximize reuse between method content elements, see
+ below.<br />
+ &nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Use content packages to organize the defined method content elements</strong>.&nbsp;When defining method
+ content elements, you may find that you want to introduce some packages in order to better organize the
+ elements.&nbsp;For more information, see <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/creating_plugins_practices_configurations_4C84B4C2.html:.:.:"
+ 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>.
+ </li>
+</ul>
+<p>
+ The following sections provide method-element-specific guidelines.
+</p>
+<h4>
+ Defining work products
+</h4>
+<p>
+ There are three types of <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:"
+ class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s that can be defined:
+</p>
+<ul>
+ <li>
+ Artifact – provides a description and definition for tangible, non-trivial work product
+ </li>
+ <li>
+ Deliverable – a collection of work products, usually artifacts
+ </li>
+ <li>
+ Outcome – an intangible work product that may be a result or state.
+ </li>
+</ul>
+<p>
+ Following are the guidelines for creating each of these work product types.<br />
+</p>
+<h5>
+ Defining artifacts
+</h5>
+<p>
+ <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html:.:.:"
+ class="elementLinkWithUserText"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/artifact_F635D25.html"
+ guid="_x7cUM9nmEdmO6L4XMImrsA">Artifacts</a> are tangible, well-defined <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:"
+ class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s consumed, produced, or modified by <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:"
+ class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+ guid="_x459ktnmEdmO6L4XMImrsA">task</a>s.&nbsp;Artifacts may be composed of other artifacts.
+</p>
+<p>
+ Artifacts are the responsibility of a single <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:"
+ class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
+ guid="_yUefQNnmEdmO6L4XMImrsA">role</a>, making responsibility easy to identify and understand, and promoting the idea
+ that every piece of information produced in the method requires the appropriate set of skills. Even though one role
+ might "own" a specific type of artifact, other roles can still use the artifacts, and perhaps even update them, if the
+ role has been given permission to do so.
+</p>
+<h5>
+ Defining deliverables
+</h5>
+<p>
+ A&nbsp;<a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html:.:.:"
+ class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/deliverable_BFE1A5A9.html"
+ guid="_yFbWoNnmEdmO6L4XMImrsA">deliverable</a>&nbsp;is a <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:"
+ class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a> that provides a description and definition for packaging other work
+ products, and may be delivered to an internal or external party.&nbsp;Deliverables are used to represent an output from
+ a process that has value to a client, customer or other stakeholder.
+</p>
+<h5>
+ Defining outcomes
+</h5>
+<p>
+ An <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html:.:.:"
+ class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/outcome_797E7695.html"
+ guid="_LNAAcB_iEdqAHrsQ7-jSbw">outcome</a>&nbsp;describes an intangible&nbsp;<a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:"
+ class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>&nbsp;that represents a result or state, such as an installed server or
+ optimized network. Outcomes may also be used to describe work products that are not formally defined.&nbsp;
+</p>
+<h4 style="MARGIN-RIGHT: 0px" dir="ltr">
+ Defining roles
+</h4>
+<p>
+ A <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html:.:.:"
+ class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
+ guid="_yUefQNnmEdmO6L4XMImrsA">role</a>&nbsp;defines a set of related skills and competencies. Roles are used by <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:"
+ class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+ guid="_x459ktnmEdmO6L4XMImrsA">task</a>s to specify who performs them.&nbsp; Roles&nbsp;may be given responsibilities
+ for specific work products.&nbsp;
+</p>
+<p>
+ The following are some criteria that affect what roles you define in your method:
+</p>
+<ul>
+ <li>
+ Organization (what are the roles in the organization that the method supports)
+ </li>
+ <li>
+ Type of project (what roles participate in the projects that the method supports)
+ </li>
+ <li>
+ Style of governance (e.g., different RACI matrices)
+ </li>
+</ul>
+<p>
+ The smaller the number of roles, the better. Define roles to represent distinct skill sets, things a person may choose
+ to do for a living, as opposed to something that someone may do on the project at any particular point in time using
+ the skills they have with some additional guidance. For example, a person may be an analyst or a designer, but may also
+ serve as a reviewer in some circumstances, or may be responsible for implementing a change request. Thus, "analyst" and
+ "designer" are good examples of roles, where as "reviewer" and "change request implementer" are not as they perform
+ things that anyone can do using their basic skill set (plus some additional guidance like guidelines and checklists).
+</p>
+<p>
+ The following are some criteria that affect how you assign roles to work products and tasks in your method:
+</p>
+<ul>
+ <li>
+ Work allocation in the organization and/or on the project that the method supports (who does what)
+ </li>
+ <li>
+ Style of governance (make very precise responsibility assignments; e.g., different RACI matrices -- RACI, RACI-VS,
+ VARISC, RASCI)
+ </li>
+</ul>
+<p>
+ <br />
+</p>
+<h4>
+ Defining tasks
+</h4>
+<p>
+ A <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html:.:.:"
+ class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+ guid="_x459ktnmEdmO6L4XMImrsA">task</a>&nbsp;is a description of a unit of work.&nbsp;The performing role
+ typically&nbsp;transforms the input <a
+ id="A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:A_-_-_C:/AMasell_cc_view/umf/lib751/shared/core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html:.:.:"
+ class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s into output work products to achieve a well-defined goal.&nbsp;This
+ description is complete and independent of when in a process lifecycle the work will actually be performed.
+</p>
+<p>
+ Describe tasks in a consistent way, both in terms of naming and in terms of scope/granularity. Try to standardize on a
+ key set of verbs and the way those verbs are used in the task names.
+</p>
+<p>
+ Define tasks so that they are independent of any specific process/lifecycle.&nbsp;Tasks provide step-by-step
+ explanations, describing how specific development goals are achieved independent of the placement of these steps within
+ a specific process (e.g., development lifecycle). Processes take these method elements and relate them into
+ semi-ordered sequences that are customized to specific types of projects. For example, a software development project
+ that develops an application from scratch performs tasks such as "Develop Vision" or "Use Case Design" similar to a
+ project that extends an existing software system. However, the two projects will perform the tasks at different points
+ in time with a different emphasis, i.e., they perform the steps of these tasks at different points of time and perhaps
+ apply individual variations and additions.
+</p>
+<p style="MARGIN-RIGHT: 0px" dir="ltr">
+ When identifying what tasks are needed, it is important to decide on the granularity of the task.&nbsp;In doing so, the
+ following should be taken into consideration:
+</p>
+<ul>
+ <li>
+ <strong>A task generally has only one primary output work product</strong>.&nbsp;However, there are instances where
+ more than one work product is worked on simultaneously, so it is possible that you will want to define some tasks
+ that do have more than one output&nbsp;work product.<br />
+ &nbsp;
+ </li>
+ <li>
+ <strong>It is recommended that you define a separate task for each state change a work product product goes
+ through.</strong>&nbsp;Since different states need different checklists, have different completion criteria, and
+ have different execution guidance, it makes sense to have different tasks.<br />
+ &nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>When the inputs to a task are&nbsp;different</strong>, you probably have two different tasks.<br />
+ &nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>When the task is assigned to different roles</strong>, you probably want two different tasks.
+ </li>
+</ul>
+<p>
+ You identify a task when there is a need to transform input work products into outputs through a series of steps
+ performed by one or more roles independent of a breakdown structure.
+</p>
+<p>
+ When defining a task, you should also define it's relationships with other method content elements.&nbsp;A
+ task&nbsp;can have the following relationships with other method content elements:
+</p>
+<ul>
+ <li>
+ <strong>Roles:</strong>&nbsp; Two types of roles can be specified:
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ <div>
+ <strong>Primary Performer:</strong>&nbsp; Each task should have a primary performer.&nbsp;This is the
+ role this is responsible for ensuring that the task is completed.&nbsp;
+ </div>
+ </li>
+ <li>
+ <div>
+ <strong>Additional Performers:</strong>&nbsp; Additional performers help execute the task.&nbsp;They
+ provide information and expertise.<br />
+ </div>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <div>
+ <strong>Work Products:</strong>&nbsp; This is where inputs and outputs to the task are
+ identified.&nbsp;Specify:
+ </div>
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ <div>
+ <strong>Mandatory Inputs:</strong>&nbsp; Mandatory inputs are the work products the task depends upon
+ for its successful execution.&nbsp;These are the inputs that the task cannot do without.
+ </div>
+ </li>
+ <li>
+ <div>
+ <strong>Optional Inputs:</strong>&nbsp;&nbsp;Optional inputs&nbsp;are the work products that provide
+ additional information or context for the task when it is being executed.&nbsp;However, the task does
+ not depend on them for successful execution.
+ </div>
+ </li>
+ <li>
+ <div>
+ <strong>Outputs:</strong>&nbsp;&nbsp;The output work products are those that are produced directly by
+ this task.&nbsp;Most tasks will have only one output work product.
+ </div>
+ </li>
+ </ul>
+ </li>
+</ul>
+<h4>
+ Defining guidance
+</h4>
+<p>
+ Guidance provides additional details to enhance method content.&nbsp;In fact, methods are more flexible if the content
+ provided in specific method elements is kept as general as possible, with more detail provided as guidance.&nbsp;The
+ method can be easily customized by simply adding or removing guidance. This section provides recommendations on how to
+ define guidance and how to associate the guidance with other method elements.&nbsp;
+</p>
+<p>
+ There are many different types of guidance, all designed for specific purposes.&nbsp;The guidance types are:
+</p>
+<ul>
+ <li>
+ <strong>Checklist</strong> – identifies a series of items that need to be completed or verified. Checklists are
+ often used in reviews such as walkthroughs or inspections. Checklists may also be a series of questions or a script
+ that practitioners may use to lead a discussion with the client's personnel. This might take the form of a
+ questionnaire or interview outline that focuses on the information needed for the work product or deliverable. In
+ UMA, a content element has at most one checklist. Checklists are useful in a number of contexts: they help in
+ deciding what to do, they help doing it, they help assess the quality of the work, and they help understand how a
+ particular work product relates to the rest of the process.<br />
+ It is recommended that checklists only be associated with work products and not tasks.&nbsp;If a checklist is
+ needed for a task, then it can be accessed via the work products associated with the task.<br />
+ In general, checklists do not require a brief description.&nbsp;However, if there are multiple checklists for a
+ method element, a brief description is helpful to distinguish between them.<br />
+ &nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Concept</strong> – outlines key ideas, basic principles and motivations underlying a topic central to the
+ method. Concepts normally address more general topics than guidelines and may span several work products, tasks,
+ activities, or disciplines. Examples of concepts might be In the context of risk management, performance testing,
+ implementation planning.<br />
+ &nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Example</strong> – a sample instance of a partially or fully formed work product or deliverable. The
+ instance may contain live client data (with the client's express permission to use it) or it may contain fabricated
+ data that is representative of the information required for the engagement. However, this example is necessarily
+ generic and is only a guide to what might be required in an actual work product or deliverable for a specific
+ engagement.<br />
+ &nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Guideline</strong> – provides additional details, "how to" information, alternatives, recommendations, or
+ rules about the use of a content element. For example, a work product typically has guidelines associated with it
+ that provides information on how to develop, evaluate, and use it. Guidelines can provide the context in which a
+ work product or other content element exists within a method. A guideline helps practitioners understand how a
+ particular content element is used and how it relates to the rest of the process in which it exists. This includes
+ formal technique papers for developing work products and deliverables.<br />
+ &nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Estimation Considerations</strong> – guidance on how to estimate the use in a project of the element with
+ which it is associated. The guidance may be textual, a spreadsheet, tool, or take some other form.<br />
+ &nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Practice</strong> – a proven way or strategy of doing work to achieve a goal that has a positive impact on
+ work product or process quality. Practices are defined orthogonal to methods and processes. They could summarize
+ aspects that impact many different parts of a method or specific processes. Examples for practices would be
+ "Managing Risks", "Continuously Verifying Quality", "Architecture-centric and Component-based Development", and so
+ on.<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Report</strong> – a predefined template of a result that is generated on the basis of one or more work
+ products as an output from some form of tool. A report is not an artifact in itself. It is, in most cases, a
+ transitory product of a process or monitoring, and a vehicle to communicate certain aspects of the evolving system;
+ it is a snapshot description of artifacts that are not documents themselves.<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Reusable Asset</strong> – a type of guidance that references assets that lie outside the method. These
+ assets may be too large or volatile to be embedded. These assets may also be third party products or services for
+ which usage permission has been granted by the owner.&nbsp;&nbsp;&nbsp;&nbsp;<br />
+ &nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Roadmap</strong> – represents important documentation for the activity or process it is related to. Often a
+ complex activity such as a process can be much more easily understood by providing a walkthrough with a linear
+ thread of a typical instantiation of this activity. In addition to making the process practitioner understand how
+ work in the process is being performed, a roadmap provides additional information about how activities and tasks
+ relate to each other over time. Road maps are also used to show how specific aspects are distributed over a whole
+ process providing a kind of filter on the process for this information.<br />
+ &nbsp;&nbsp; &nbsp;
+ </li>
+ <li>
+ <strong>Supporting Material</strong> – this is a catch-all for assets that do not fit in another type.<br />
+ &nbsp;&nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Template</strong> – a version of a work product or deliverable instance that does not contain data so that
+ the practitioner may use it to "fill in the blanks". This is usually a form or set of fields that define the data
+ to be collected and may assist in analyzing the data to produce the information for the completed work product or
+ deliverable. Taken together the example and the template form a powerful pair for the practitioner. In the first,
+ the practitioner sees a completes or partially completed work product while the second offers a convenient means of
+ producing the work product as rapidly and as accurately as possible.<br />
+ &nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Term Definition</strong> – a definition of a word or phrase that is not in the glossary and that
+ practitioner need to understand for the method plug-in.<br />
+ &nbsp;&nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>Tool Mentor</strong> – a description of how to achieve certain goals with a specific tool. Tool mentors
+ link tasks with tools such as IBM&reg; Rational&reg; Method Composer. They almost completely encapsulate the dependencies
+ of the content on the tool set, keeping the tasks free from tool details.<br />
+ &nbsp;&nbsp;
+ </li>
+ <li>
+ <strong>White Paper</strong> – an externally published paper that can be read and understood in isolation of other
+ content elements and guidance
+ </li>
+</ul>
+<p>
+ Guidance should be written with a specific scope in mind.&nbsp; For example:
+</p>
+<ul>
+ <li>
+ Guidance can be more <em><strong>general</strong></em>, written with regards to a set of elements (e.g., workshops,
+ collaboration, lifecycle families, etc.)
+ </li>
+ <li>
+ Guidance can be <strong><em>method-element specific</em></strong> (e.g., written regarding a specific work product,
+ task, role, process) , or
+ </li>
+</ul>
+<p>
+ The name of a guidance element should reflect that scope. Specifically, method element-specific guidance should include
+ the method element name in its name.&nbsp;For example,&nbsp;Guideline: Detailing a Use Case, Template: Use-Case
+ Template.
+</p>
+<p>
+ Guidance may be attached to any method element and guidance should be attached to method elements, as needed. However,
+ decreasing the number of relationships defined between elements in the method helps to reduce the overall perceived
+ complexity of the method.&nbsp;In general, guidance should be associated with the smallest number of elements possible.
+ Having "everything associated with everything" is a bad idea as it directly affects the usage of the published web
+ site.<br />
+ For example, avoid associating the same guidance with work products and tasks that produce the work products as this
+ creates unnecessary dependencies since the same content will be linked in via one of the other relationships
+ anyway.&nbsp;
+</p>
+<p>
+ Guidance should be associated with the element that reflects its scope (i.e., the element where the end-user would be
+ expected to look for it).&nbsp; Method element-specific guidance should be associated with the method element it
+ describes:
+</p>
+<ul>
+ <li>
+ If the guidance is about notation or representation of a work product (e.g., template, example, checklist) then it
+ should be associated with the work product
+ </li>
+ <li>
+ If the guidance describes a specific technique about how to produce the work product then it should be associated
+ with a task that produces the work product
+ </li>
+ <li>
+ General guidance should be associated with "general" elements (e.g., slots, standard categories, reference
+ workflows, etc.) or possibly just included in custom categories (aka navigation views)
+ </li>
+ <li>
+ Roles are not a common place for associating guidance, unless that guidance is specific to the role (and not to a
+ task the role performs or a work product the role is responsible for)
+ </li>
+</ul>
+<p>
+ Most guidance should be associated with at least one element. Of course, there are exceptions:
+</p>
+<ul>
+ <li>
+ Guidance that is about the method, as opposed to being part of the method (e.g.,&nbsp; Welcome pages, About pages,
+ What's new pages, etc.).&nbsp;Such guidance is usually only referred to from navigation views.
+ </li>
+ <li>
+ General guidance (e.g., concepts, white papers) sometimes need to be associated with "general"
+ elements.&nbsp;<br />
+ Some possible associations for general concepts are associating to them from standard categories, custom
+ categories/navigation views, etc.
+ </li>
+</ul>
+<p>
+ When defining guidance elements, you must constantly weigh reuse concerns versus complexity:
+</p>
+<ul>
+ <li>
+ If you define fine-grained guidance elements, then you can assign the guidance elements to specific method
+ elements, which provides just the guidance you need, but&nbsp;then you have many guidance elements, which can be
+ construed as being more complex).&nbsp;
+ </li>
+ <li>
+ If you define course-grained guidance elements, then have a smaller number of guidance elements, but then the same
+ guidance elements is attached to multiple elements and you have to find what you are looking for by scrolling
+ through the course-grained guidance element.
+ </li>
+</ul>
+<p>
+ Make the best choice based on your circumstances and let end-user feedback be your guide.&nbsp;
+</p>
+<h3>
+ Roles in the UMF
+</h3>
+<p>
+ The Unified Method Framework (UMF)&nbsp;defines some constraints with regards to the definition and use of <a
+ class="elementLink" href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_37A0C602.html"
+ guid="_yUefQNnmEdmO6L4XMImrsA">role</a>s and <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/role_set_396DC9DB.html"
+ guid="_Fs8HAMaIEduMlb2cQZNTYw">role set</a>s.&nbsp;
+</p>
+<p>
+ The UMF implements a delayed role assignment&nbsp;approach, which means that the assignment of roles to method content
+ elements is NOT done as part of the definition of the method content elements.&nbsp; In addition, in the UMF, role
+ definitions are intended to be shared.&nbsp; Thus, in the UMF, the roles and role sets&nbsp;are defined separately from
+ the method content elements they can be assigned to (e.g., work products and tasks), as well as from the assignments
+ themselves.&nbsp; For information, see the topic Delayed assignment in the UMF below.
+</p>
+<p>
+ Roles and role sets may be shared across practices or may be practice-specific and this decision affects what plug-ins
+ their definitions and assignments are placed.
+</p>
+<p>
+ Shared roles and role sets:
+</p>
+<ul>
+ <li>
+ Shared roles and role sets are <strong><em>defined</em></strong> in a Role Definition Base plug-in.&nbsp;
+ </li>
+ <li>
+ Shared roles are assigned to shared role sets in a Role Definition Base plug-in.&nbsp;
+ </li>
+ <li>
+ Shared roles are <strong><em>assigned</em></strong> to <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+ guid="_x459ktnmEdmO6L4XMImrsA">task</a>s and <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s in the Assign plug-in associated with the Base plug-in where the
+ element to be assigned to the role (work product or task) is defined.&nbsp;
+ </li>
+</ul>
+<p>
+ Practice-specific roles and role sets:
+</p>
+<ul>
+ <li>
+ Practice-specific roles and role sets are defined in the Practice Assign plug-in.
+ </li>
+ <li>
+ Practice-specific roles are assigned to practice-specific role sets in the Practice Assign plug-in.&nbsp;
+ </li>
+ <li>
+ Practice-specific roles are <strong><em>assigned</em></strong> to <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/task_6C1FF051.html"
+ guid="_x459ktnmEdmO6L4XMImrsA">task</a>s and <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/work_product_826E4C22.html"
+ guid="_H4JXwB_SEdq6CKKKq4D7YA">work product</a>s in the Practice Assign plug-in.&nbsp;
+ </li>
+</ul>
+<p>
+ The benefits to the UMF approach to roles are:
+</p>
+<ul>
+ <li>
+ Roles and role sets can be shared across practices (shared Role Definition plug-ins)
+ </li>
+ <li>
+ Alternate role assignments can be defined (provide alternate Assign plug-ins)
+ </li>
+</ul>
+<p>
+ Note: If you are developing a method where the role assignments can NEVER change, then late role assignment is overkill
+ and the role assignments can be done directly in Base plug-ins.
+</p><br />
+<h3>
+ Scaling Method Elements in the UMF
+</h3>
+<p>
+ When there is a need to scale, you need to define a base plug-in (or plug-ins) that have a scope&nbsp;generic enough to
+ be scaled. For example, we define an open source core plug-in (or plug-ins) that may have a scope that is broader than
+ OpenUp Basic in open source layer. OpenUp Basic could then be built on that open source core (as would the rest of the
+ IBM methods), possibly using only a subset of the elements in the core. That way, users can have access to the OpenUp
+ Basic content, as well as the broader open source core that is built to be scaled up.
+</p>
+<h4>
+ Example of using packaging technique to scale
+</h4>
+<ul>
+ <li>
+ <h5>
+ Scaling by adding techniques
+ </h5>
+ <p>
+ Sometimes we want to offer a specialized technique or alternative technique from which the&nbsp;user can pick
+ and choose. You can either package the technique in a separate technique plug-in or package the technique in
+ its own content package.
+ </p>
+ <ul>
+ <li>
+ Create a Technique Plug-in 
+ <ul>
+ <li>
+ This method is nice because it captures all the work products, tasks, etc, across all disciplines
+ in one place. &nbsp;Selection of the technique is simply a matter of choosing the plug-in.
+ </li>
+ <li>
+ Alternative techniques can be offered using multiple plug-ins
+ </li>
+ <li>
+ Document restrictions in the Plug-in description (available in the configuration editor) for which
+ techniques can be used together and which cannot.
+ </li>
+ </ul>
+ </li>
+ <li>
+ Create a Content Package 
+ <ul>
+ <li>
+ This method is useful for small, isolated techniques
+ </li>
+ <li>
+ Note: avoid creating dependencies on content package selection (eg, must choose two or none).&nbsp;
+ If the user will need to select multiple content packages to properly choose the technique, it
+ would be better to use a technique plug-in instead.<br />
+ </li>
+ </ul>
+ </li>
+ </ul>
+ </li>
+ <li>
+ <h5>
+ Scaling by adding resource plug-ins
+ </h5>
+ <p>
+ Isolating resources, such as examples and templates, to their own plug-in allows users to select which set of
+ resources they want. For example: cmr.res.sw_dev.formal, cmr.res.sw_dev.informal.
+ </p>
+ <p>
+ Don't worry about elaborate content packaging of templates: assume that errors in configurations caused by
+ templates not having a WP home because the package containing the WP was deselected.
+ </p>
+ <p>
+ Note:&nbsp; When you have more than one template for a particular work product:
+ </p>
+ </li>
+ <li style="LIST-STYLE-TYPE: none">
+ <ul>
+ <li>
+ <p>
+ If the content of the templates is the same, just the format is different (eg, letter, A4, MS Word,
+ HTML), then you can just add the additional template to the same template guidance element.
+ </p>
+ </li>
+ <li>
+ <p>
+ If the content of the templates is different, then use another Template guidance element to attach the
+ second template.
+ </p>
+ </li>
+ </ul>
+ </li>
+</ul>
+<h4>
+ Common guidelines on scaling
+</h4>
+<ul>
+ <li>
+ Tasks, activities, and steps should be used to describe actionable elements. &nbsp;Do not add tasks, activities,
+ and steps to amplify "how" a need should be satisfied. That is "guidance" not "work".
+ </li>
+ <li>
+ Resist the temptation to artificially increase the number of actionable items. Project Managers will simply not
+ entertain a work structure with 1100 elements.
+ </li>
+ <li>
+ Use activities, tasks, and steps to define a work road map and put road signs up about the work. &nbsp;Keep the
+ guidance in the guidance.
+ </li>
+ <li>
+ Define base elements very generically, with add-on concepts that describe where more detailed elements fit in.
+ Example: &nbsp;describe that DB design is part of design and is covered in design elements, even though separate
+ elements are not defined.
+ </li>
+</ul>
+<h4>
+ Scaling guidance elements in the UMF
+</h4>
+<p>
+ The following sections describe some strategies&nbsp;for scaling guidance elements.
+</p>
+<h5>
+ Strategies&nbsp;for scaling guidance
+</h5>
+<ol>
+ <li>
+ When the content of an existing guidance method content element can be reused in a higher layer,
+ <strong><u>contribute</u></strong> more detail to&nbsp;the existing guidance.
+ </li>
+ <li>
+ If the content of an existing guidance element cannot be reused in the higher layer,
+ <strong><u>replace</u></strong> the guidance with more appropriate and elaborate guidance.
+ </li>
+</ol>
+<h5>
+ Strategy&nbsp;for scaling checklists
+</h5>
+<p>
+ You can contribute additional items to the list
+</p>
+<h5>
+ Strategy&nbsp;for scaling templates
+</h5>
+<p>
+ You can contribute additional templates, but it's probably better to create a different template guidance altogether,
+ rather than add different template formats to the same one.
+</p>
+<h4>
+ Scaling roles in the UMF
+</h4>
+<p>
+ This guideline describe some strategies&nbsp;for scaling roles.&nbsp;For example,&nbsp;in one context, you may have one
+ role set and a few roles.&nbsp;At the next level, single roles may become role sets&nbsp;comprised of multiple
+ roles.&nbsp;Scaling roles is much easier as a result of UMF's delayed role assignment approach, which supports the easy
+ definition of alternate role and role set definitions and assignments.&nbsp;For more information, see the topic above
+ Roles in the UMF.
+</p>
+<h4>
+ Scaling tasks in the UMF
+</h4>
+<p>
+ The following sections describe some strategies&nbsp;for scaling tasks.
+</p>
+<h5>
+ Strategy 1: Packaging
+</h5>
+<p>
+ Consider the following:
+</p>
+<ul>
+ <li>
+ Package generic tasks (ie, a that task includes no details) in a sub-package of the work product&nbsp;it produces
+ </li>
+ <li>
+ Package specific tasks in your context. For tasks that are likely to need to be ‘split' later, package them in
+ their own pkg.
+ </li>
+</ul>
+<h5>
+ Strategy 2: Add guidance
+</h5>
+<p>
+ Rather than creating more tasks, consider adding more specialized guidance to explain the detail of specific tasks.
+</p>
+<h5>
+ Strategy 3: Contribute steps to a task
+</h5>
+<p>
+ You can add a step between steps or at the end of the base task steps.&nbsp; You cannot add to the wording of a
+ particular step.&nbsp; For example, if you add a new sub-work product to the work product, you can contribute a new
+ step to create the sub-work product.
+</p>
+<p>
+ Tactical Workaround: When you really want to add to a particular step, indicate you are providing a specialized step by
+ naming your step the same as the one you wanted to append to and&nbsp;adding a qualifier in brackets: eg, "Determine
+ how elements collaborate [UML modeling]"
+</p>
+<h5>
+ Strategy 4: Create new tasks
+</h5>
+<p>
+ Create a new task when: a new role performs the task, it is a unit of work that should be tracked (ie, want it in the
+ WBS), it has different inputs or outputs.
+</p>
+<h5>
+ Strategy 5:&nbsp;Suggest a&nbsp;change to the base task&nbsp;
+</h5>
+<p>
+ You could suggest a change to the tasks in the base (eg, OpenUP), so that the base task becomes something you can scale
+ from.&nbsp; For example, suggest that the text be updated to only describe what is done, not how.
+</p>
+<h5>
+ Strategy 6: Make a task an activity and its steps become tasks
+</h5>
+<p>
+ Currently, RMC Tool cannot support this strategy.
+</p>
+<p>
+ Tactical workaround:
+</p>
+<ol>
+ <li>
+ Deselect the package containing the task you are splitting (if it's not in a separate package, put it in a separate
+ package)
+ </li>
+ <li>
+ Create the new tasks
+ </li>
+ <li>
+ Create a Process Pattern (activity) with the same name as the base task
+ </li>
+ <li>
+ Add the new tasks to the activity
+ </li>
+ <li>
+ Reconstruct relationships that were to the task to the appropriate new tasks
+ </li>
+</ol>
+<h4>
+ Scaling work products in the UMF
+</h4>
+<p>
+ The following sections describe some strategies&nbsp;for scaling work products.
+</p>
+<h5>
+ Strategy&nbsp;1: Use the notion of container work products in the base.
+</h5>
+<p>
+ The base layer (the open source layer) includes a generic work product that can be used as the container for several
+ work products in lower levels. Scale by creating child work products of the base container. Contribute to the base work
+ products when possible, to reinforce the scaling connection, you could add text to say: " For details about WPx see
+ &lt;hyperlink to added WPx&gt;".
+</p>
+<p>
+ Note:&nbsp; You may need to suggest a change to the base work product to make it more scalable.
+</p>
+<p align="center">
+ <img
+ id="A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/example%20of%20scaling%20work%20products.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/example%20of%20scaling%20work%20products.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/example%20of%20scaling%20work%20products.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/example%20of%20scaling%20work%20products.gif:.:.:"
+ border="0" alt="Example of Scaling Work Products" src="resources/example%20of%20scaling%20work%20products.gif" />
+</p>
+<p align="center">
+ <b>Figure 1:</b> Example of scaling "Design" Work Product using the notion of container technique
+</p>
+<p>
+ Figure 1 shows example when scaling up design from the open source layer. In the open source layer, the primary work
+ product is Design. Design is scaling to include conceptual design, logical design, operational design, subsystem
+ design, etc... in the commercial layer. Scaling to the commercial layer, the open source Design sub-WP is reused for
+ small projects (assuming some content proposals are accepted). For medium and large projects, content is contributed to
+ the Design work product which becomes a container for added sub-work products. Again, the licensable layer will reuse
+ commercial layer work products with some content contribution to the Design container work product.
+</p>
+<p>
+ Guideline: Use the most specific work product as input and output that makes sense
+</p>
+<p>
+ Note: Extension is generally not a useful feature because too many associations are kept.
+</p>
+<h5>
+ Strategy 2: Split a work product into two
+</h5>
+<ol>
+ <li>
+ Before attempting to split a work product, consider recommending a change to the&nbsp;base layer to add
+ the&nbsp;work product&nbsp;you need
+ </li>
+ <li>
+ Define a custom category that contains the work product to remove and select that category in the do not publish
+ part of the configuration.
+ </li>
+ <li>
+ Create the new work product(s) and include them in your configuration.
+ </li>
+</ol>
+<h5>
+ Strategy 3: Adding new work products
+</h5>
+<p>
+ If you cannot scale using strategy 1 or 2, create a new work product. However, avoid just adding work
+ products.&nbsp;Where possible, try to consolidate them under a container work product or consider whether&nbsp;the open
+ source layer&nbsp;should include the work product.
+</p>
+<p>
+ Note:&nbsp;If you just cannot scale from a work product in&nbsp;the&nbsp;base layer, you may need to suggest a change
+ to the work product in&nbsp;that base&nbsp;(eg, suggest that the description be made more generic).
+</p>
+<h3>
+ Tool Information in the UMF
+</h3>
+<p>
+ Tool information can come in many forms: <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/tool_D0FBC781.html"
+ guid="_BangwMaJEduMlb2cQZNTYw">tool</a>s, <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/tool_mentor_264766F3.html"
+ guid="_yYy-mdnmEdmO6L4XMImrsA">tool mentor</a>s, <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/example_9C7688B0.html"
+ guid="_nE6fsMaFEduMlb2cQZNTYw">example</a>s, <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/template_53432085.html"
+ guid="_1MLN8MaIEduMlb2cQZNTYw">template</a>s, <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/termdefinitions/supporting_material_F91C8C5B.html"
+ guid="_SwvUgMaIEduMlb2cQZNTYw">supporting material</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/white_paper_7231747.html"
+ guid="_Kc1IIMaJEduMlb2cQZNTYw">white paper</a>s, etc.
+</p>
+<p>
+ In the Unified Method Framework (UMF), tool information is defined in multiple plug-ins.
+</p>
+<p>
+ Tools (the standard categories) are defined in the Core in a Tool Definition&nbsp;Base plug-in where they can be shared
+ between <a class="elementLink"
+ href="./../../../core.default.uma_concept.base/guidances/concepts/practice_F5C8EAAB.html"
+ guid="_qhCTAFRREd2CWscN8Mx6rg">Practice</a>s.
+</p>
+<p>
+ Other tool information is defined according to its scope:
+</p>
+<ul>
+ <li>
+ <em>General</em> tool information (as opposed to practice-specific tool information) is defined in the Tool
+ Definition Base plug-in.
+ </li>
+ <li>
+ <em>Practice-specific</em> tool information is defined in the Practice Base (or Extend) plug-in.&nbsp;
+ </li>
+</ul>
+<p>
+ The UMF does NOT implement&nbsp;a Delayed Assignment&nbsp;approach 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;Thus:
+</p>
+<ul>
+ <li>
+ Tool guidance is assigned to tasks in the Practice Base (or Extend) plug-in where the task is defined.&nbsp;The
+ assignment is done directly in the task definition.
+ </li>
+ <li>
+ Tool mentors are assigned to the appropriate Tool standard categories&nbsp;in the plug-in where the tool mentors
+ are defined. The assignment is done by defining a contributor to the Tool standard category (defined in a Tool
+ Definition plug-in) and then assigning the tool mentor to the Tool in the contributor.&nbsp;
+ </li>
+</ul>
+<h3>
+ Work Product Slots in the UMF
+</h3>
+<p>
+ In the Unified Method Framework (UMF),&nbsp;Work Product Slots are defined as artifacts in Slot plug-ins.&nbsp; When
+ authoring work products slots, be aware that the content cannot be practice or technique specific. Work product slots
+ are intended to be generic. Thus, the most important thing to document is the information the work product slot
+ represents, not its specific representation or the technique use to develop it.
+</p>
+<h3>
+ Using Method Content Variability
+</h3>
+<p>
+ This guideline explains how to utilize method content variability to modify an existing element without directly
+ changing the original element's base definition, or to create a new element based on an existing element. Changes are
+ defined in a separate content package or plug-in, and the original plug-in is kept intact. Thus, it allows you to
+ change method elements by simply changing a configuration (in other words, changing what plug-ins and packages are
+ included in the configuration).
+</p>
+<p>
+ Variability involves textual attributes and relationships.&nbsp; In other words you can use variability to add, delete
+ change, or reuse&nbsp;both text and relationships.&nbsp;
+</p>
+<p>
+ Variability is defined between two elements of the same type:
+</p>
+<ul>
+ <li>
+ Base element: The target of the variability; the element being changed (or used as a base for new element)
+ </li>
+ <li>
+ Variability element: The element containing the changes (or new content or relationships) to be combined with the
+ base
+ </li>
+</ul>
+<p>
+ The base element is never changed directly. All changes (or new content) is defined in the variability element. The
+ variability element specifies which element is the base.
+</p>
+<p>
+ As shown in Figure 1, when both the base element and the variability element are included in a configuration, the
+ configuration "resolves" the variability to produce the result, where that result depends on what variability was used.
+</p>
+<p>
+ <strong>Figure 1. Method content variability elements</strong>
+</p>
+<p>
+ <img
+ id="A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/variability.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/variability.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/variability.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/variability.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/variability.gif:.:.:A_-_-_file:///C:/AMasell_cc_view/umf/lib751/shared/practice.mgmt.spi.base/guidances/guidelines/resources/variability.gif:.:.:"
+ border="0" alt="variability_elements" src="resources/variability.gif" />&nbsp;
+</p>
+<p>
+ There are different types of variability, each with their own characteristics, rules, pros and cons. Table 1 provides a
+ summary of the different types of variability and when you might want to use them.<br />
+ <br />
+</p><br />
+<br />
+<table title="Method Content Variability Summary" border="1" cellspacing="0"
+summary="summary of different types of method content variability" cellpadding="2" width="85%">
+ <caption>
+ <strong>Table 1. Method Content Variability Summary</strong>
+ </caption>
+ <tbody>
+ <tr>
+ <td>
+ <strong>Variability Type</strong>
+ </td>
+ <td>
+ <strong>Result</strong>
+ </td>
+ <td>
+ <strong>Possible Uses</strong>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Contributes
+ </td>
+ <td>
+ <p>
+ Contributing element adds to the base element<br />
+ (result = base element plus contributed characteristics)
+ </p>
+ <ul>
+ <li>
+ Contributing (variability) element adds to the base element.
+ </li>
+ <li>
+ The base appears in the published Web site, but the contributing element does not.
+ </li>
+ <li>
+ Incoming and outgoing relationships from the contributing element are added to the base<br />
+ Exception: If the relationship is a "to one" relationship (for example, a task has at most one
+ primary performing role) then the relationship in the contributor is ignored if the base already
+ has one.
+ </li>
+ <li>
+ Text from the contributing element is appended to corresponding base sections.
+ </li>
+ <li>
+ A base element can have more then one contributor.
+ </li>
+ <li>
+ Contributes works transitively (a contributing element contributes its own contributors).
+ </li>
+ </ul>
+ </td>
+ <td>
+ <ul>
+ <li>
+ Add guidance to an existing element
+ </li>
+ <li>
+ Add steps to an existing task
+ </li>
+ <li>
+ Add responsibility for a work product to a role
+ </li>
+ <li>
+ Add a primary performing role to a task
+ </li>
+ <li>
+ Add a work product to a task (as an input or output work product)
+ </li>
+ <li>
+ Add text to existing elements
+ </li>
+ <li>
+ Adding method elements to existing categories<br />
+ <br />
+ </li>
+ </ul>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Replaces
+ </td>
+ <td>
+ <p>
+ Replacing element replaces parts of the base element (incoming relationships remain)<br />
+ (result = new element, no base element)
+ </p>
+ <ul>
+ <li>
+ Replacing (variability)&nbsp;element replaces parts of the base element.
+ </li>
+ <li>
+ The replacing element&nbsp;appears in the published Web site but the base element does not.
+ </li>
+ <li>
+ Outgoing relationships in the replacing element are maintained, and the base's are ignored.
+ </li>
+ <li>
+ Incoming relationships to the base are maintained and added to the replacing element.<br />
+ Exception: If the replacing element has an incoming to-one relationship (for example, a replacing a
+ role that includes a task performs the role relationship),&nbsp;the replacing element&nbsp;replaces
+ that relationship in the&nbsp;base element.
+ </li>
+ <li>
+ Text in the replacing element is left maintained, the base's text is ignored.
+ </li>
+ <li>
+ A base element can only be replaced by one replacing element at a time. If two elements replace the
+ same base element,&nbsp;only one can be used for interpretation (the plug-in containing one of the
+ replacing elements needs to be removed from the configuration or no replacement will take place).
+ </li>
+ <li>
+ Replacement works transitively (if a replacing element is replaced itself, then&nbsp;the final
+ replacing element will prevail).
+ </li>
+ </ul>
+ </td>
+ <td>
+ <ul>
+ <li>
+ Replace an existing method content element with another method content element
+ </li>
+ </ul>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Extends
+ </td>
+ <td>
+ <p>
+ Extending element inherits characteristics of the base element<br />
+ (result = base element + new element)
+ </p>
+ <ul>
+ <li>
+ Extending (variability) element inherits characteristics of the base element. The base element is
+ unchanged.
+ </li>
+ <li>
+ Both the extending element&nbsp;and the base appear in the published Web site.
+ </li>
+ <li>
+ Outgoing relationships from the base are added to the extending element.
+ </li>
+ <li>
+ Incoming relationships in the extending element&nbsp;are maintained, and the base's are ignored.
+ </li>
+ <li>
+ Text is included in the extending element from the base element if the extending element&nbsp;did
+ not include any text for the given section.
+ </li>
+ <li>
+ Extends works transitively (if an extending element is extended itself the second extension
+ inherits from its direct and indirect base elements).
+ </li>
+ </ul>
+ </td>
+ <td>
+ <ul>
+ <li>
+ Define a new element that looks just like an existing element, with some modifications (in other
+ words, define a variant or a specialization of an existing element)
+ </li>
+ <li>
+ Extends is not used to modify an existing element
+ </li>
+ </ul>
+ </td>
+ </tr>
+ <tr>
+ <td>
+ Extends-Replaces
+ </td>
+ <td>
+ <p>
+ Replacing element replaces only values that have been redefined in the replacer<br />
+ (result = new element, no base element)
+ </p>
+ <ul>
+ <li>
+ Combines the effects of extends and replaces variability, allowing you to selectively replace
+ specific attributes and relationships of the base element.
+ </li>
+ <li>
+ Extending-replacing (variability) element replaces values in the base element that have been
+ redefined in the&nbsp;extending-replacing element . All other values of the base element are
+ unaffected.
+ </li>
+ <li>
+ Both the extending-replacing element&nbsp;and the base appear in the published Web
+ site.&nbsp;&nbsp;
+ </li>
+ </ul>
+ </td>
+ <td>
+ <ul>
+ <li>
+ Rename an existing element
+ </li>
+ <li>
+ Replace a specific textual attribute of a method element
+ </li>
+ <li>
+ Replace the outgoing relationships of an existing method element
+ </li>
+ <li>
+ Replace the incoming relationships of an existing method element
+ </li>
+ </ul>
+ </td>
+ </tr>
+ </tbody>
+</table><br />
+<br />
+<h4>
+ Order of evaluation
+</h4>
+<p>
+ Contribution precedes replacement (the contributes relationship is resolved first, followed by the replaces
+ relationship). The evaluation of contribution and replacement is performed top-down in the specialization hierarchy.
+</p>
+<h4>
+ Handy tricks
+</h4>
+<p>
+ If you ever find that you want to create an element that looks just like an existing element, but includes some
+ additional content, you can use a combination of extends and contributes to achieve the desired result.&nbsp; To do
+ this, perform the following steps:
+</p>
+<ol>
+ <li>
+ Define a method element that that extends the original base element. This results in a new element that looks just
+ like the original element.
+ </li>
+ <li>
+ Define another method element that contributes to the extending element and add the desired content. This results
+ in adding the new content to the new element that already includes the original content.
+ </li>
+</ol>
+<p>
+ The net result:&nbsp;A new element that includes the original content plus the new content.
</p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
diff --git a/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/general_naming_conventions.xmi b/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/general_naming_conventions.xmi
index 65f932f..24eed6d 100644
--- a/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/general_naming_conventions.xmi
+++ b/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/general_naming_conventions.xmi
@@ -1,5 +1,5 @@
<?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="-UMwO0Odv_iQVxPV40lG2kA" name="new_guideline,__I8S0D2kEd-lU6YVR9_PJQ" guid="-UMwO0Odv_iQVxPV40lG2kA" changeDate="2011-07-05T15:55:53.599-0700" version="7.5.0">
+<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="-UMwO0Odv_iQVxPV40lG2kA" name="new_guideline,__I8S0D2kEd-lU6YVR9_PJQ" guid="-UMwO0Odv_iQVxPV40lG2kA" changeDate="2011-10-10T10:16:03.667-0700" version="7.5.0">
<mainDescription><h3>
General Naming Conventions
</h3>
@@ -555,6 +555,17 @@
</tr>
<tr>
<td>
+ Define
+ </td>
+ <td>
+ To determine the essential qualities
+ </td>
+ <td>
+ &nbsp;
+ </td>
+ </tr>
+ <tr>
+ <td>
Detail
</td>
<td>
diff --git a/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/implementing_method_asset.xmi b/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/implementing_method_asset.xmi
index 0826cdd..22647bb 100644
--- a/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/implementing_method_asset.xmi
+++ b/epf_prac_151/practice.bus.mdev.base/guidances/guidelines/implementing_method_asset.xmi
@@ -1,5 +1,5 @@
<?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" xmi:id="-gP2w-Jyw1kWV4Rdu3rW75w" name="new_guideline,_PTzXQE8REd-xRf1mYeAI9w" guid="-gP2w-Jyw1kWV4Rdu3rW75w" changeDate="2010-09-09T11:28:44.117-0700" version="7.5.0">
+<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="-gP2w-Jyw1kWV4Rdu3rW75w" name="new_guideline,_PTzXQE8REd-xRf1mYeAI9w" guid="-gP2w-Jyw1kWV4Rdu3rW75w" changeDate="2011-10-10T11:44:52.493-0700" version="7.5.0">
<mainDescription><h3>
Detailing Method Elements
</h3>
@@ -167,11 +167,10 @@
</h4>
<p>
When detailing the elements in a practice&nbsp;that exists within the Unified Method Framework (UMF), you must take
- into consider the UMF practice conventions.&nbsp;When detailing the elements in a practice, you may find that you need
- to make changes to an element in a&nbsp;Core plug-in. Specifically, you may find that you have content that&nbsp;would
- be better shared between practices (for example, a common work product, some shared guidance, or a new role) and thus
- you may need to add a new or refine an existing core element.&nbsp;Alternatively, you may find that if you were
- to&nbsp;refine an existing Core element that would be able to use it.&nbsp;
+ into consideration the UMF practice conventions.&nbsp;When detailing the elements in a practice, you may find that you
+ need to make changes to an element in a&nbsp;Core plug-in. Specifically, you may find that you have content
+ that&nbsp;would be better shared between practices (for example, a common work product, some shared guidance, or a new
+ role) and thus you may need to add a new core element or refine an existing core element.
</p>
<h3>
Detailing Work Products
@@ -201,7 +200,7 @@
</ul>
</li>
</ul>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+<blockquote style="MARGIN-RIGHT: 0px" dir="ltr">
<p>
Do not repeat text already stated in other fields, such as the brief description or the main description.
</p>
@@ -288,10 +287,10 @@
<li>
<strong>External Description</strong>: This field is intended to be a description of the deliverable that the
client will read. It is usually copied into a Statement of Work or other agreement, or into sales and marketing
- material with a client. The content of this field may require legal approval of some sort. Seek guidance from the
- method authoring consultant. Keep to a description (what the deliverable is) rather than its use in an engagement.
- Build on the purpose but differentiate between the what and the why of the deliverable. The description is about
- what the deliverable is. The description must be understood by potential clients.
+ material. The content of this field may require legal approval of some sort. Seek guidance from the method
+ authoring consultant. Keep to a description (what the deliverable is) rather than its use in an engagement. Build
+ on the purpose but differentiate between the what and the why of the deliverable. The description is about what the
+ deliverable is. The description must be understood by potential clients.
</li>
<li>
<strong>Packaging Guidance</strong>: This field is intended to give an overview of the notation for the
@@ -301,16 +300,16 @@
more focused. The packaging guidance must account for the availability (or not) of a complete set of input work
products. Depending on the configuration tailoring on a particular engagement, all input work product may not be
available. Be aware of the purpose and governance level of the deliverable being defined when outlining notation.
- [*** Describing how the inputs are assembled into a deliverable including what particular sections may be relevant
- and what the expected state of those inputs should be along. Explicit guidelines on the formatting may be better
- included via a customization for that project of standard guidelines for a project that applies to all deliverables
- as defined in the agreement. ***]
+ Describe how the inputs are assembled into a deliverable, including what particular sections may be relevant and
+ what the expected state of those inputs should be.<br />
+ It is often best to define formatting guidelines that apply to all deliverables on the project, and then provide
+ additional specific guidelines as needed.&nbsp; It is also best to define formatting guidelines by customizing
+ standard formatting guidelines that already exist.
</li>
<li>
<strong>Deliverable Parts:</strong>&nbsp;Identify the work products that will be used to construct the deliverable.
</li>
-</ul>
-<br />
+</ul><br />
<h3>
Detailing Tasks
</h3>
@@ -352,13 +351,13 @@
<li>
<div style="MARGIN-RIGHT: 0px">
<strong>Main description:</strong> This <span
- style="FONT-SIZE: 10pt; FONT-FAMILY: Arial; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA">
- <span style="mso-spacerun: yes">field is optional for tasks&nbsp;if individual steps are being
- used.&nbsp;I</span>f individual steps are not being used, the Main description should explain the execution of
- the task and</span> mention the input and output work products. Do not repeat text already stated in other
- fields, such as the Brief description or the Purpose.&nbsp;The task details can&nbsp;be described&nbsp;using
- the Main description or&nbsp;by including specific Steps.&nbsp;Guidance can be attached to provide further
- details about how to perform the task.<br />
+ style="FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-fareast-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><span
+ style="mso-spacerun: yes">field is optional for tasks&nbsp;if individual steps are being used.&nbsp;I</span>f
+ individual steps are not being used, the Main description should explain the execution of the task and</span>
+ mention the input and output work products. Do not repeat text already stated in other fields, such as the
+ Brief description or the Purpose.&nbsp;The task details can&nbsp;be described&nbsp;using the Main description
+ or&nbsp;by including specific Steps.&nbsp;Guidance can be attached to provide further details about how to
+ perform the task.<br />
&nbsp;&nbsp;&nbsp;
</div>
</li>
@@ -401,11 +400,11 @@
</ul>
</li>
</ul>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+<blockquote style="MARGIN-RIGHT: 0px" dir="ltr">
<p>
A Step is described using:
</p>
- <div dir="ltr" style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px">
+ <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px" dir="ltr">
<ul>
<li>
<strong>Name:</strong>&nbsp;&nbsp; This is the brief description of the step.
@@ -573,7 +572,7 @@
<p dir="ltr">
For guidance-type-specific guidelines, see the following sections.&nbsp;&nbsp;&nbsp;
</p>
-<h4 dir="ltr" style="MARGIN-RIGHT: 0px">
+<h4 style="MARGIN-RIGHT: 0px" dir="ltr">
Detailing checklists
</h4>
<p>
@@ -584,8 +583,8 @@
<p>
The following fields are specific to checklists:
</p>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
- <p dir="ltr" style="MARGIN-RIGHT: 0px">
+<blockquote style="MARGIN-RIGHT: 0px" dir="ltr">
+ <p style="MARGIN-RIGHT: 0px" dir="ltr">
<strong>Check Items:</strong>&nbsp; These fields make up the items in the checklist.&nbsp; Each check item has:
</p>
<ul dir="ltr">
@@ -610,10 +609,10 @@
the main description adequately covers what is to be reviewed</em>&nbsp;&nbsp;&nbsp;
</p>
</blockquote>
-<h4 dir="ltr" style="MARGIN-RIGHT: 0px">
+<h4 style="MARGIN-RIGHT: 0px" dir="ltr">
Detailing examples
</h4>
-<p dir="ltr" style="MARGIN-RIGHT: 0px">
+<p style="MARGIN-RIGHT: 0px" dir="ltr">
When detailing an <a class="elementLink"
href="./../../../core.default.uma_concept.base/guidances/termdefinitions/example_9C7688B0.html"
guid="_nE6fsMaFEduMlb2cQZNTYw">example</a>:
@@ -638,20 +637,20 @@
</div>
</li>
</ul>
-<h4 dir="ltr" style="MARGIN-RIGHT: 0px">
+<h4 style="MARGIN-RIGHT: 0px" dir="ltr">
Detailing guidelines
</h4>
-<p dir="ltr" style="MARGIN-RIGHT: 0px">
+<p style="MARGIN-RIGHT: 0px" dir="ltr">
When entering text in the Main description if <a class="elementLink"
href="./../../../core.default.uma_concept.base/guidances/termdefinitions/guideline_1D590B95.html"
guid="_uK8HMMaFEduMlb2cQZNTYw">guideline</a>&nbsp;elements, exceptionally lengthy guidance should either be broken down
into multiple guidance elements, or attached as a word document. Note that word documents are difficult to translate,
and so should be avoided in commercial content.
</p>
-<h4 dir="ltr" style="MARGIN-RIGHT: 0px">
+<h4 style="MARGIN-RIGHT: 0px" dir="ltr">
Detailing reusable assets
</h4>
-<p dir="ltr" style="MARGIN-RIGHT: 0px">
+<p style="MARGIN-RIGHT: 0px" dir="ltr">
When detailing a <a class="elementLink"
href="./../../../core.default.uma_concept.base/guidances/termdefinitions/reusable_asset_C02B1B80.html"
guid="_kSKZUMaHEduMlb2cQZNTYw">reusable asset</a>:
@@ -674,10 +673,10 @@
</div>
</li>
</ul>
-<h4 dir="ltr" style="MARGIN-RIGHT: 0px">
+<h4 style="MARGIN-RIGHT: 0px" dir="ltr">
Detailing templates
</h4>
-<p dir="ltr" style="MARGIN-RIGHT: 0px">
+<p style="MARGIN-RIGHT: 0px" dir="ltr">
When detailing a <a class="elementLink"
href="./../../../core.default.uma_concept.base/guidances/termdefinitions/template_53432085.html"
guid="_1MLN8MaIEduMlb2cQZNTYw">template</a>:
@@ -702,19 +701,19 @@
</div>
</li>
</ul>
-<h4 dir="ltr" style="MARGIN-RIGHT: 0px">
+<h4 style="MARGIN-RIGHT: 0px" dir="ltr">
Detailing tool mentors
</h4>
-<p dir="ltr" style="MARGIN-RIGHT: 0px">
+<p style="MARGIN-RIGHT: 0px" dir="ltr">
When detailing a <a class="elementLink"
href="./../../../core.default.uma_concept.base/guidances/termdefinitions/tool_mentor_264766F3.html"
guid="_yYy-mdnmEdmO6L4XMImrsA">tool mentor</a>, explain how to apply a specific tool to accomplish a task, performs a
set of steps or instantiates a particular work product.
</p>
-<h4 dir="ltr" style="MARGIN-RIGHT: 0px">
+<h4 style="MARGIN-RIGHT: 0px" dir="ltr">
Detailing white papers
</h4>
-<p dir="ltr" style="MARGIN-RIGHT: 0px">
+<p style="MARGIN-RIGHT: 0px" dir="ltr">
When detailing a <a class="elementLink"
href="./../../../core.default.uma_concept.base/guidances/termdefinitions/white_paper_7231747.html"
guid="_Kc1IIMaJEduMlb2cQZNTYw">white paper</a>:
@@ -805,7 +804,7 @@
read this practice:
</li>
</ul>
-<blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
+<blockquote style="MARGIN-RIGHT: 0px" dir="ltr">
<p>
For example: "The best way to read this practice is to first familiarize yourself with its overall structure --
what it is in it and how it is organized. The best place to start is with the Key Concepts for the practice --
