| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmi:id="-isqsIiw9-4dR3ProL-I-vg" name="new_guideline,_fx7TMD3REd-realK_We5vA" guid="-isqsIiw9-4dR3ProL-I-vg" changeDate="2011-10-13T15:47:19.687-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;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 package.
 |
| </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> |
