org.eclipse.epf.help.doc/html/differencesbetweenexistingandmigratedcontent.html

<?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>