plugins/org.eclipse.epf.help.doc/html/differencesbetweenexistingandmigratedcontent.html - gerrit/epf/org.eclipse.epf.archive - Git at Google

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