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