| <?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><p> |
| The Unified Method Architecture (UMA) meta-model has been developed as&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.&nbsp; This concept provides |
| you with a general overview to UMA capabilities. |
| </p> |
| <h4> |
| Separation of Method Content and Process |
| </h4> |
| <p> |
| UMA provides a clear separation of Method Content definitions from its application in Processes. This is accomplished |
| by separately defining |
| </p> |
| <ul> |
| <li> |
| reusable core Method Content, in the form of general content descriptions such as Roles, Task, Work Products and |
| Guidance |
| </li> |
| <li> |
| project-type&nbsp;specific applications of Method Content in context in the form of process descriptions that |
| reference Method Content |
| </li> |
| </ul> |
| <p> |
| 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. |
| </p> |
| <h4> |
| Content Reuse |
| </h4> |
| <p> |
| 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). |
| </p> |
| <h4> |
| Process Families |
| </h4> |
| <p> |
| 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&nbsp;Patterns and Delivery |
| Processes as well as specific reuse relationships between these type of processes.&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. |
| </p> |
| <h4> |
| Multiple Lifecycles |
| </h4> |
| <p> |
| 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. |
| </p> |
| <h4> |
| Flexible Extensibility and Plug-in Mechanisms |
| </h4> |
| <p> |
| 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&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. |
| </p> |
| <h4> |
| Multiple Process 'Views' |
| </h4> |
| <p> |
| 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: |
| </p> |
| <ul> |
| <li> |
| Work Breakdown - this is a work-centric view which defines Tasks associated with a particular high-level Activity |
| </li> |
| <li> |
| Work Product Usage - this is a results-based view which defines the state of certain Deliverables and Artifacts at |
| various points in the process |
| </li> |
| <li> |
| Team Allocation - this is a responsibility-based view which defines needed Roles and their work product |
| responsibilities |
| </li> |
| </ul> |
| <p> |
| 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. |
| </p> |
| <h4> |
| Reusable process patterns |
| </h4> |
| <p> |
| 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: |
| </p> |
| <ul> |
| <li> |
| 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. |
| </li> |
| <li> |
| 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. |
| </li> |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |