<?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="_972lYO8LEdmKSqa_gSYthg" name="introduction_to_uma,_94_eoO8LEdmKSqa_gSYthg" guid="_972lYO8LEdmKSqa_gSYthg" changeDate="2005-10-26T15:38:58.896-0700" version="7.1.0">
  <mainDescription>&lt;p>&#xD;
    The Unified Method Architecture (UMA) meta-model has been developed as&amp;nbsp;a unification of different method and&#xD;
    process engineering languages such as the SPEM extension to the UML for software process engineering, the languages&#xD;
    used for RUP v2003, Unified Process, IBM Global Services Method, as well as IBM Rational Summit Ascendant. As such it&#xD;
    provides concepts and capabilities from all of these source models unifying them in a consistent way, but still&#xD;
    allowing to express each of these source methods with their specific characteristics.&amp;nbsp; This concept provides you&#xD;
    with a general overview to UMA capabilities.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Separation of Method Content and Process&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    UMA provides a clear separation of Method Content definitions from its application in Processes. This is accomplished&#xD;
    by separately defining&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        reusable core Method Content, in the form of general content descriptions such as Roles, Task, Work Products and&#xD;
        Guidance&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        project-type&amp;nbsp;specific applications of Method Content in context in the form of process descriptions that&#xD;
        reference Method Content&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    Method Content provides step-by-step explanations of how specific development goals are achieved independent of the&#xD;
    placement of these steps within a development lifecycle. Processes take these Method Content elements and organize them&#xD;
    into a sequence that can be customized to specific types of projects. For example, a software development project that&#xD;
    develops an application from scratch performs development steps similar to a project that extends an existing software&#xD;
    system. However, the two projects will perform similar steps at different points in time with a different emphasis and&#xD;
    perhaps individual variations.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Content Reuse&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    UMA allows each Process to reference common Method Content from a common Method Content pool. Because of these&#xD;
    references, changes in the Method Contents will automatically be reflected in all Processes using it. However, UMA&#xD;
    still allows overwriting certain method-related content within a Process as well as defining individual&#xD;
    process-specific relationships for each Process Element (such as adding an additional input Work Product to a Task,&#xD;
    renaming a Role, or removing Steps that should not be performed from a Task).&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Process Families&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    UMA's goal is to not only support the representation of one specific development process or the maintenance of several&#xD;
    unrelated processes, but to provide process engineers with a tool set to consistently and effectively manage whole&#xD;
    families of related Processes. UMA realizes this by defining the concepts of Capability&amp;nbsp;Patterns and Delivery&#xD;
    Processes as well as specific reuse relationships between these type of processes.&amp;nbsp; These concepts allow a process&#xD;
    engineer to maintain consistent families of Delivery Processes that are project type specific and are variations of the&#xD;
    same base Method Content and Capability Patterns. The result is different variants of specific processes built up by&#xD;
    dynamically reusing the same Method Content and Patterns, but applied with different levels of detail and scale; for&#xD;
    example, Process variants for small versus large scale development projects.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Multiple Lifecycles&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    A general method architecture must support different varieties and even combinations of lifecycle models for process&#xD;
    definitions. These include Waterfall, Iterative, Incremental, Evolutionary, and so on. The UMA meta-model is designed&#xD;
    to accommodate multiple approaches. It provides a rich set of concepts and customization attributes for specifying&#xD;
    temporal semantics for Process Elements such as phases, iterations, dependencies, ongoing or event-driven work, etc.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Flexible Extensibility and Plug-in Mechanisms&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    UMA's Method Plug-Ins provide a unique way of customizing Method Content and Processes without directly modifying the&#xD;
    original content. Instead, they just described the differences (additions referred to as contributions&#xD;
    and&amp;nbsp;replacements) relative to the original. This Plug-in concept allows users to easily upgrade to newer versions&#xD;
    of Method Content without losing their customizations.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Multiple Process 'Views'&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    UMA defines multiple and consistently maintained views on processes. These views allow process engineers to approach&#xD;
    process authoring based on their personal preferences. A process engineer can choose to define their Processes with a&#xD;
    focus on any of the following:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        Work Breakdown - this is a work-centric view which defines Tasks associated with a particular high-level Activity&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Work Product Usage - this is a results-based view which defines the state of certain Deliverables and Artifacts at&#xD;
        various points in the process&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        Team Allocation - this is a responsibility-based view which defines needed Roles and their work product&#xD;
        responsibilities&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p>&#xD;
    UMA provides consistency between all these views, because they are all based on one integrated object structure.&#xD;
    Changes in one view will immediately be reflected in the other views.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Reusable process patterns&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    UMA's Capability Patterns are reusable building blocks for creating new development Processes. Selecting and applying a&#xD;
    Capability Pattern can be done in one of two flexible ways:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        A pattern can be applied in a sophisticated copy and modify operation, which allows the process engineer to&#xD;
        individually customize the pattern's content to his needs during the pattern application.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        A pattern can be applied via dynamic binding. This unique new way of reusing process knowledge allows commonly&#xD;
        reoccurring Activities to be factored out into patterns which can then be applied over and over again in a Process.&#xD;
        When the pattern is being revised or updated, all changes will automatically be reflected in all Processes that&#xD;
        applied that pattern.&#xD;
    &lt;/li>&#xD;
&lt;/ul></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
