| <?xml version="1.0" encoding="UTF-8"?> |
| <!DOCTYPE html |
| PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
| <html lang="en-us" xml:lang="en-us"> |
| <head> |
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |
| <meta name="copyright" content="(C) Copyright Eclipse contributors 2005, 2006" /> |
| <meta name="DC.rights.owner" content="(C) Copyright Eclipse contributors 2005, 2006" /> |
| <meta name="security" content="public" /> |
| <meta name="Robots" content="index,follow" /> |
| <meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' /> |
| <meta name="DC.Type" content="concept" /> |
| <meta name="DC.Title" content="Differences Between IBM RUP 2003 and Migrated Content" /> |
| <meta name="DC.Relation" scheme="URI" content="migrationoverview.html#migrationoverview" /> |
| <meta name="DC.Relation" scheme="URI" content="migrateanrpw2003plugin.html#migrateanrpw2003plugin" /> |
| <meta name="DC.Format" content="XHTML" /> |
| <meta name="DC.Identifier" content="differencesbetweenexistingandmigratedcontent" /> |
| <meta name="DC.Language" content="en-us" /> |
| <!-- |
| Copyright (c) 2005, 2006 IBM Corporation and others. |
| All rights reserved. This program and the accompanying materials |
| are made available under the terms of the Eclipse Public License v1.0 |
| which accompanies this distribution, and is available at |
| http://www.eclipse.org/legal/epl-v10.html |
| Contributors: |
| IBM Corporation - initial implementation |
| --> |
| <link rel="stylesheet" type="text/css" href="./ibmdita.css" /> |
| <title>Differences Between IBM RUP 2003 and Migrated Content</title> |
| </head> |
| <body id="differencesbetweenexistingandmigratedcontent"><a name="differencesbetweenexistingandmigratedcontent"><!-- --></a> |
| |
| <h1 class="topictitle1">Differences Between IBM RUP 2003 and Migrated Content</h1> |
| <div><p>Eclipse Process Framework Composer content is based on IBM Unified |
| Method Architecture.</p> |
| <ul><li><strong>Activities have been renamed to task</strong>: To provide a tighter link |
| to process enactment and project management we renamed the lowest assignable |
| units of work to Task, because this is the term most commonly used.</li> |
| <li><strong>Workflow details renamed to activity</strong>: Workflows are commonly expressed |
| in hierarchies of activity diagrams (e.g. activity diagrams defined in the |
| UML 2.0). Although RUP only provided one level of workflow breakdown, UMA |
| is designed to provide multiple levels of such a breakdown. Because the word |
| Activity was more commonly used to express the elements of activity diagrams |
| as well as the activity diagram itself, we decided to replace the name Workflow |
| Detail used in RUP with the name Activity. We realize that the shift in the |
| usage of the word Activity might cause confusion with existing RUP users. |
| However, one important goal of the UMA work was to use terms in the way they |
| are most commonly used in standards and industry. </li> |
| <li><strong>Tasks (former RUP Activities) can be performed by many roles</strong>: |
| In RUP 2003 an activity was modeled as an operation of a role. Customer feedback, |
| a look at other process modeling approaches, as well as changes introduced |
| in UML 2.0 indicated that this was a too restrictive way of modeling human |
| behavior. This approach did not allow expressing that some work was performed |
| as a collaboration of different roles. UMA addresses this issue by making |
| Task an independent model element to which performing roles can be assigned |
| as resources. UMA therefore now allows several roles to be assigned to a |
| task. For backward compatibility, it still allows a primary performing role |
| to be identified (being responsible for the task) as well as several additional |
| performers.</li> |
| <li><strong>Refinement of the artifact concept</strong>: RUP only used the concept of |
| artifact to define things that are used and produced in a development project. |
| UMA defines an extended taxonomy for these concepts. It defines the general |
| concept of work product, which has three different specializations (specific |
| work product types): Artifacts (managed work products), Deliverables (packaged |
| work products that will be delivered to a stakeholder for review), and Outcome |
| (unmanaged, intangible work products).</li> |
| <li><strong>Different categorizations for work products and roles</strong>: In RUP, |
| artifacts and roles were all categorized by discipline. However, sometimes |
| artifacts were used across disciplines and a categorization to only one discipline |
| caused confusion. In UMA different categories have been defined for work |
| definitions (discipline for tasks and activities), work products (domain and |
| work product kind), and roles (role sets).</li> |
| <li><strong>Process Components renamed to Method Package</strong>: The concept of component |
| is commonly used in many standards and technologies. Most applications of |
| component link it to the abstraction of encapsulation defining a component |
| as a black box which can be used via well-defined interfaces. RUP component |
| did not fulfill this black box criterion. Also the SPEM standard defined |
| packages as well as components. To be compliant to SPEM and the industry usage |
| of the word component, we renamed Process Component to Method Package ('method' |
| because it can contain method elements or process elements)</li> |
| <li><strong>Separation of method content elements from process elements</strong>: In |
| RUP 2003 you created a new process by defining a new configuration and documenting |
| manually in a development case artifact changes to standard RUP. UMA provides |
| extended concepts in addition to the configuration concept for tailoring processes. |
| It allows you to model concretely for a process what work defined in the |
| method content you want to actually do in each phase, because you can easily |
| add, remove, and reorder elements in the process structure, reusing or not |
| reusing whatever you want from the method content. It achieves these features |
| by a more clear separation of method content (e.g. tasks defined for disciplines) |
| and the application of method content in process (expressed with activity |
| diagrams and/or work breakdown structures) as well as the modeling of processes |
| (i.e. creating new or adapted activity diagrams or new or adapted work breakdown |
| structures). It introduces a few new concepts such as descriptor that support |
| this separation and achieve new capabilities for maintaining and reusing many |
| different families of alternative processes and process parts all within the |
| same configuration.</li> |
| </ul> |
| </div> |
| <div><div class="relconcepts"><strong>Related concepts</strong><br /> |
| <div><a href="migrationoverview.html#migrationoverview">Migration Overview</a></div> |
| </div> |
| <div class="reltasks"><strong>Related tasks</strong><br /> |
| <div><a href="migrateanrpw2003plugin.html#migrateanrpw2003plugin">Migrate an IBM RUP 2003.06 Plugin</a></div> |
| </div> |
| </div> |
| </body> |
| </html> |